public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* Re: [Bitcoin-development] Electrum 2.0 has been tagged
@ 2015-03-12  5:12 Thy Shizzle
  2015-03-12  5:25 ` Aaron Voisine
  0 siblings, 1 reply; 42+ messages in thread
From: Thy Shizzle @ 2015-03-12  5:12 UTC (permalink / raw)
  To: slush; +Cc: bitcoin-development

[-- Attachment #1: Type: text/plain, Size: 3424 bytes --]

Yes I agree with this sentiment.
As for the version, don't forget we can kinda "brute force" our way to determine a version, because lets say there is 10 versions, we can generate the seed for all 10 versions and then check to see which seed was in use (has transacted) and then use that seed. If no transactions are found, we could restore the wallet with the seed of the latest and greatest version. Not really any need to store the version, sure it may save some time but as Marek rightly says, this is for restoration of a wallet from cold storage not an everyday thing so the extra time to brute force the version etc is acceptable as a trade off for not forcing the remembering of a version.
BIP39 is beautiful.
On Wed, Mar 11, 2015 at 6:14 PM, Mike Hearn <mike@plan99.net> wrote:

   
   - Electrum v2 with a version number but no date
   - myTREZOR with no version and no date and BIP44 key derivation. Some seeds I believe are now being generated with 24 words instead of 12.
   - MultiBit HD with no version and a date in a custom form that creates non-date-like codes you are expected to write down. I think BIP32 and BIP44 are both supported (sorta).
   - GreenAddress with no version, no date and BIP32
   - Other bitcoinj based wallets, with no version and a date written down in normal human form, BIP32 only.

To my knowledge, myTREZOR, Multibit HD and GreenAddress uses BIP39, just different scheme for key derivation (myTREZOR uses full BIP44, Multibit HD uses BIP44 with first account only and GreenAddress uses another scheme because it's multisig only wallet).
I disagree with the need of some version "magic flags" or creation date stored in the mnemnonic, for those reasons:
a) If we fail in the way how mnemonic algo is defined, then some magic, extra version flag won't save our asses, because we'll fail in meaning of its meaning. Then it will be completely useless, as implementations cannot rely on it. I know Thomas was sound proponent of this solution, but he was unable to give any reasonable rules about who/how define meaning of version flag.
b) "Creation date" is just a short-term hack. Considering that mnemonic words are kind of cold storage (longterm storage), it *really* does not make much difference in 2020, if your wallet has been created in 02/2014 or 10/2016. If there's performance issue with scanning of the blockchain, creation date don't save our asses. We need to find another solution, and as a bonus, we don't need users to know some weird numbers on top of mnemonic itself.
> From my interpretation of BIP39, wordlists DO NOT REQUIRE to be fixed between wallet providers. There is some recommendations regarding the wordlists to help with things such as predictive text, so mobile apps can easily predict the word being typed in after a few chars etc.
Exactly! After some community feedback, we changed BIP39 algo to be one-way only, which means you can use *any* wordlist to create the mnemonic, and any other implementation can derive BIP32 root node even without knowing that particular wordlist. Namely this has been changed because of constructive criticism of ThomasV, and from discussion on the mailing list I had a feeling that we've found a consensus. I was *very* surprised that Electrum 2.0 started to use yet another algo "just because".
Shortly said, I think BIP39 does perfect job and there's no need to use anything else.
Cheers,Marek

[-- Attachment #2: Type: text/html, Size: 5971 bytes --]

^ permalink raw reply	[flat|nested] 42+ messages in thread
* Re: [Bitcoin-development] Electrum 2.0 has been tagged
@ 2015-03-12  5:58 Thy Shizzle
  0 siblings, 0 replies; 42+ messages in thread
From: Thy Shizzle @ 2015-03-12  5:58 UTC (permalink / raw)
  To: voisine; +Cc: bitcoin-development

[-- Attachment #1: Type: text/plain, Size: 1573 bytes --]

  Why on earth would you want to derive the mnemonic from the wallet seed? Ever?
Remembering that as an attacker doesn't actually have to do any key stretching, they can just keep trying (what is it 64 bytes from memory?) at a time without any PBKDF2 to attack a seed, it seems that the PBKDF2 is just to slow down anyone attempting to attack through an interface such as a web service or to a TREZOR or whatever, in a real world attack you would not even be performing PBKDF2 you would just brute force the raw bytes and force them into the BIP32 wallet as there is no Authentication scheme that hashes and compares against the result. It purely limits abuse through an online wallet provider or something like that by slowing down seed generation attempts THROUGH that API, it doesn't really add any security to the seed in a real world brute force attack! So yea I think the 2048 iteration count is sufficient for it's purpose because even if it only forces an extra 1ms per seed generation through the API, it is still slower than just brute forcing the 64 bytes straight up, and so they would have no reason to abuse your API that is all :)
"meh... the fact that you can't derive the seed phrase from the wallet seed, and that the password key stretching is so weak as to be ineffectual security theater bugs me. Feels like a pretty big compromise to work on current generation low power embedded devices when the next generation will be more than capable. But I understand the motivation for the compromise.

Aaron Voisine
co-founder and CEO
breadwallet.com"

[-- Attachment #2: Type: text/html, Size: 2855 bytes --]

^ permalink raw reply	[flat|nested] 42+ messages in thread
* Re: [Bitcoin-development] Electrum 2.0 has been tagged
@ 2015-03-12  4:21 Thy Shizzle
  2015-03-12 11:51 ` Neill Miller
  0 siblings, 1 reply; 42+ messages in thread
From: Thy Shizzle @ 2015-03-12  4:21 UTC (permalink / raw)
  To: neillm; +Cc: Bitcoin-development

[-- Attachment #1: Type: text/plain, Size: 10528 bytes --]

 "I agree that it's true that a static wordlist is
 required once people have started using BIP39 for anything real and
 changing the word lists will invalidate any existing mnemonics"
^ This is incorrect I think Neill, the reason is that the only thing that happens when you change the wordlist is that entropy points to different words. But remember, entropy is disposed. Yes in my code I allow for the keeping of entropy etc, it also lets me "hot swap" between different language wordlists etc but in real world implementation the entropy is forgotten and not stored. So changing the wordlist merely allows new mnemonic phrases to be generated but it has a nil impact on previously generated mnemonics UNLESS you are trying to rebuild from entropy but you wouldn't do that. You would be rebuilding from the Mnemonic in real world scenario. You really can have a word list of total rubbish in BIP39 as long as it is 2048 words long that is all! If you input the mnemonic made out of rubbish words so for e.g "uyuy jkjasd sdsd sdsdd yuuyu sdsds iooioi sdasds uyuyuy sdsdsd tyyty rwetrtr" and no matter what BIP39 implementation you put it in, it will always generate the same seed bytes thus allowing for complete and universal seed derivation without any reliance on word list. The word list is merely to generate a mnemonic, after that it has no role in seed generation so you can change it at anytime and it will never effect future mnemonics.

On Thu, Mar 12, 2015 at 02:16:38AM +0000, Thy Shizzle wrote:
> That's disappointing the Electrum 2.0 doesn't use BIP39.

Agreed, but I don't know the full background on this.

> Changing the wordlist in the future has ZERO effect on derived seed, whatever mnemonic you provide will always generate the same seed, BIP39 is not mapping the words back to numbers etc to derive seed.

That's true for generating new mnemonics (i.e. same entropy can
generate any combinations of words), but not for converting a mnemonic
to a seed (i.e. a specific wordlist/passphrase should always generate
the same seed).  I agree that it's true that a static wordlist is
required once people have started using BIP39 for anything real and
changing the word lists will invalidate any existing mnemonics (unless
your 'new' wordlist simply substitutes one word for another and the
index mapping is made public ... which means it's not really an
arbitrary word list).

> Version is something that can be dealt with after the fact, hopefully standardised (curious why didn't you work with the BIP39 to insert version instead of do something different to BIP39?)
> So most of what you are suggesting as problems are not.

I don't see how this can work given the BIP39 spec as it is today
(there's simply no room for a version in the bits).  I do think
versioning would be nice, but as of now, I'm in the camp that thinks
complete wallet interoperability is a bit of a myth -- so long as you
can fundamentally move into/out of wallets at will.

-Neill.

> As for the common words between languages, I have discussed this with the provider of the Chinese wordlists as they shared some words between simplified and traditional, but I found it easy to look for a word in the mnemonic that is unique to that language/wordlist and so straight away you can determine the language, remembering you get minimum 12 goes at doing that :)
> Also then I asked myself, do we really care about detecting the language? Probably not because we don't need to use the wordlist ever again after creation, we literally accept the mnemonic, normalise it then hash it into a seed. From what I'm reading, Electrum 2.0 really should have BIP39, it would take almost no effort to put it in and I think you should do that :) I don't have any interest in BIP39 other than it being a standard. I think TREZOR may have an interest in it?
> Thomas V:
> "Thanks Mike, and sorry to answer a bit late; it has been a busy couple
> of weeks.
> 
> You are correct, a BIP39 seed phrase will not work in Electrum, and vice
> versa. It is indeed unfortunate. However, I believe BIP39 should not be
> followed, because it reproduces two mistakes I did when I designed the
> older Electrum seed system. Let me explain.
> 
> The first problem I have with BIP39 is that the seed phrase does not
> include a version number.
> 
> Wallet development is still in an exploratory phase, and we should
> expect even more innovation in this domain. In this context, it is
> unwise to make decisions that prevent future innovation.
> 
> However, when we give a seed phrase to users, we have a moral obligation
> to keep supporting this seed phrase in future versions. We cannot simply
> announce to Electrum users that their old seed phrase is not supported
> anymore, because we created a new version of the software that uses a
> different derivation. This could lead to financial losses for users who
> are unaware of these technicalities. Well, at least, that is how I feel
> about it.
> 
> BIP39 and Electrum v2 have a very different ways of handling future
> innovation. Electrum v2 seed phrases include an explicit version number,
> that indicates how the wallet addresses should be derived. In contrast,
> BIP39 seed phrases do not include a version number at all. BIP39 is
> meant to be combined with BIP43, which stipulates that the wallet
> structure should depend on the BIP32 derivation path used for the wallet
> (although BIP43 is not followed by all BIP39 compatible wallets). Thus,
> innovation in BIP43 is allowed only within the framework of BIP32. In
> addition, having to explore the branches of the BIP32 tree in order to
> determine the type of wallet attached to a seed might be somewhat
> inefficient.
> 
> The second problem I see with BIP39 is that it requires a fixed
> wordlist. Of course, this forbids innovation in the wordlist itself, but
> that's not the main problem. When you write a new standard, it is
> important to keep this standard minimal, given the goal you want to
> achieve. I believe BIP39 could (and should) have been written without
> including the wordlist in the standard.
> 
> There are two ways to derive a master key from a mnemonic phrase:
>  1. A bidirectional mapping between words and numbers, as in old
> Electrum versions. Pros: bidirectional means that you can do Shamir
> secret sharing of your seed. Cons: It requires a fixed wordlist.
>  2. Use a hash of the seed phrase (pbkdf). Pros: a fixed wordlist is not
> required. Cons: the mapping isn't bidirectional.
> 
> Electrum v1 uses (1). Electrum v2 uses (2).
> 
> Early versions of BIP39 used (1), and later they switched to (2).
> However, BIP39 uses (2) only in order to derive the wallet keys, not for
> its checksum. The BIP39 checksum uses (1), and it does requires a fixed
> wordlist. This is just plainly inconsistent. As a result, you have
> neither wordlist flexibility, nor Shamir secret sharing.
> 
> Having a fixed wordlist is very unfortunate. First, it means that BIP39
> will probably never leave the 'draft' stage, until all languages of the
> world have been added. Second, once you add a wordlist for a new
> language, you cannot change it anymore, because it will break existing
> seed phrases; therefore you have to be extremely careful in the way you
> design these wordlists. Third, languages often have words in common.
> When you add a new language to the list, you should not use words
> already used by existing wordlists, in order to ensure that the language
> can be detected. It leads to a first come first served situation, that
> might not be sustainable in the future.
> 
> In order to support the old Electrum v1 seeds, all future versions of
> Electrum will have to include the old wordlist. In addition, when
> generating new seed phrases, Electrum now has to avoid collisions with
> old seed phrases, because the old ones did not have a version number.
> This is painful enough, I will not repeat the same errors twice.
> 
> Electrum v2 derives both its private keys and its checksum/version
> number using a hash of the seed phrase. This means that wordlists can be
> added and modified in the future, without breaking existing seed
> phrases. It also means that it will be very easy for other wallets to
> support Electrum seedphrases: it requires about 20 lines of code, and no
> wordlist is required."
> 
> 
> Thomas
> 
> 
> Le 02/03/2015 16:37, Mike Hearn a écrit :
> > Congrats Thomas! Glad to see Electrum 2 finally launch.
> > 
> > 
> >> * New seed derivation method (not compatible with BIP39).
> > 
> > 
> > Does this mean a "12 words" wallet created by Electrum won't work if
> > imported into some other wallet that supports BIP39? Vice versa? This seems
> > unfortunate. I guess if seeds are being represented with 12 words
> > consistently, people will expect them to work everywhere.
> > 
> 
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the 
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> Bitcoin-development --
> |   |
> |   |   |   |   |   |
> | Bitcoin-development --To see the collection of prior postings to the list, visit the Bitcoin-development Archives. |
> |  |
> | View on lists.sourceforge.net | Preview by Yahoo |
> |  |
> |   |
> 
>   
> 
>  
>    

> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the 
> conversation now. http://goparallel.sourceforge.net/

> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[-- Attachment #2: Type: text/html, Size: 12599 bytes --]

^ permalink raw reply	[flat|nested] 42+ messages in thread
* Re: [Bitcoin-development] Electrum 2.0 has been tagged
@ 2015-03-12  2:38 Thy Shizzle
  2015-03-12 10:43 ` Andreas Schildbach
  0 siblings, 1 reply; 42+ messages in thread
From: Thy Shizzle @ 2015-03-12  2:38 UTC (permalink / raw)
  To: c1.sf-bitcoin; +Cc: bitcoin-development

[-- Attachment #1: Type: text/plain, Size: 2943 bytes --]

Right you are!
I saw Thomas's email about Electrum 2.0 not supporting BIP39.
It seems he had the idea that the wordlist was a strict requirement yet it is not, it is unfortunate that Electrum did not go the route of BIP39. The wordlist is irrelevant and merely used to help build mnemonics.
Also as I've shown, you can work a version into it, I was going to actually propose it to the BIP39 authors but didn't think it was an issue.
I think BIP39 is fantastic.
I think Electrum 2.0 (And everyone) should use BIP39  On 2015-03-11 06:21 PM, Thy Shizzle wrote:
> Hmmmm I don't think it's fair to say that there has been a failure to
> standardise. From what I read earlier among the wallets, mostly it came
> down to if a version was noted and the date. Assuming no date is
> provided, it just means you are scanning the block chain from day 0 for
> transactions right? Hardly a big deal as you will still recover funds right?

Unfortunately there's more incompatibility than just the date issue:

* seed: some follow BIP39, and some roll their own
* HD structure: some follow BIP44, some BIP32 derivation, and some roll
their own

So actually very few wallets are seed-compatible, even ignoring the date
question.

> 
> Version right now is irrelevant as there is only one version of BIP39
> currently, probably this will change as 2048 iterations of HMACSHA512
> will likely need to be up scaled in the future, I thought about adding
> one extra word into the mnemonic to signify version, so if you have a 12
> word mnemonic then you have 12 words + 1 word version. Version 1 has no
> extra word, version 2 uses the first word on the list, version 3 uses
> the second word on the wordlist, so on and so forth. Least that's what I
> was thinking of doing if I ever had to record a version, won't effect
> anything because entropy increases in blocks of 3 words so one extra
> word can simply be thrown on the end.

That's a reasonable solution.

> 
> So in summary I feel that date can be handled by assuming day 0, and
> version is not an issue yet but may become one and probably it is a good
> idea to think about standardising a version into BIP39, I have
> provided a seed idea for discussion.
> 
> I don't think it is quite the doom and gloom I'm reading :)
> 
> 
> devrandom:
> "I'd like to offer that the best practice for the shared wallet use case
> should be multi-device multi-sig.  The mobile has a key, the desktop has
> a key and a third-party security oracle has a third key.  The oracle
> would have different security thresholds for countersigning the mobile.
> 
> This way you can have the same overall wallet on all devices, but
> different security profiles on different keys.
> 
> That said, I do agree that mnemonic phrases should be portable, and find
> it unfortunate that the ecosystem is failing to standardize on phrase
> handling."

-- 
devrandom / Miron

[-- Attachment #2: Type: text/html, Size: 4250 bytes --]

^ permalink raw reply	[flat|nested] 42+ messages in thread
[parent not found: <372541993.4372759.1426123313134.JavaMail.yahoo@mail.yahoo.com>]
[parent not found: <1353069350.4360497.1426126034565.JavaMail.yahoo@mail.yahoo.com>]
* [Bitcoin-development] Electrum 2.0 has been tagged
@ 2015-03-01 15:23 Thomas Voegtlin
  2015-03-02  7:09 ` Andreas Schildbach
  2015-03-02 15:37 ` Mike Hearn
  0 siblings, 2 replies; 42+ messages in thread
From: Thomas Voegtlin @ 2015-03-01 15:23 UTC (permalink / raw)
  To: Bitcoin Development

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dear Bitcoin devs,

I just tagged version 2.0 of Electrum:
https://github.com/spesmilo/electrum/tree/2.0

The electrum.org website will be updated later today. The release
notes are a bit dense, due to the large amount of changes and new
features in this release. In the coming weeks we will be adding more
detailed documentation to the wiki and to the website.

There has been a very long hiatus in Electrum releases, because it
took me a lot of time to decide about the new seed derivation method
and wallet structure. Now that this part is done, I hope that we will
resume to a faster release pace.

I would like to thank all the people who contributed to this release,
developers, beta testers, but also people from this list who provided
useful feedback.

Cheers,

Thomas

_____________________________

RELEASE-NOTES

# Release 2.0

* Before you upgrade, make sure you have saved your wallet seed on
paper.

* Documentation is now hosted on a wiki: http://electrum.orain.org

* New seed derivation method (not compatible with BIP39). The seed
phrase includes a version number, that refers to the wallet
structure. The version number also serves as a checksum, and it
will prevent the import of seeds from incompatible wallets. Old
Electrum seeds are still supported.

* New address derivation (BIP32). Standard wallets are single account
and use a gap limit of 20.

* Support for Multisig wallets using parallel BIP32 derivations and
P2SH addresses ("2 of 2", "2 of 3").

* Compact serialization format for unsigned or partially signed
transactions, that includes the BIP32 master public key and
derivation needed to sign inputs. Serialized transactions can be
sent to cosigners or to cold storage using QR codes (using Andreas
Schildbach's base 43 idea).

* Support for BIP70 payment requests:
- - Verification of the chain of signatures uses tlslite.
- - In the GUI, payment requests are shown in the 'Invoices' tab.

* Support for hardware wallets: Trezor (Satoshilabs) and Btchip (Ledger).

* Two-factor authentication service by TrustedCoin. This service uses
"2 of 3" multisig wallets and Google Authenticator. Note that
wallets protected by this service can be deterministically restored
from seed, without Trustedcoin's server.

* Cosigner Pool plugin: encrypted communication channel for multisig
wallets, to send and receive partially signed transactions.

* Audio Modem plugin: send and receive transactions by sound.

* OpenAlias plugin: send bitcoins to aliases verified using DNSSEC.

* New 'Receive' tab in the GUI:
- - create and manage payment requests, with QR Codes
- - the former 'Receive' tab was renamed to 'Addresses'
- - the former Point of Sale plugin is replaced by a resizeable
window that pops up if you click on the QR code

* The 'Send' tab in the Qt GUI supports transactions with multiple
outputs, and raw hexadecimal scripts.

* The GUI can connect to the Electrum daemon: "electrum -d" will
start the daemon if it is not already running, and the GUI will
connect to it. The daemon can serve several clients. It times out
if no client uses if for more than 5 minutes.

* The install wizard can be used to import addresses or private
keys. A watching-only wallet is created by entering a list of
addresses in the wizard dialog.

* New file format: Wallets files are saved as JSON. Note that new
wallet files cannot be read by older versions of Electrum. Old
wallet files will be converted to the new format; this operation
may take some time, because public keys will be derived for each
address of your wallet.

* The client accepts servers with a CA-signed SSL certificate.

* ECIES encrypt/decrypt methods, availabe in the GUI and using
the command line:
encrypt <pubkey> <message>
decrypt <pubkey> <message>

* The Android GUI has received various updates and it is much more
stable. Another script was added to Android, called Authenticator,
that works completely offline: it reads an unsigned transaction
shown as QR code, signs it and shows the result as a QR code.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJU8y7fAAoJECvVgkt/lHDm78oP/2uIqCyOwLsAJGkAI3CPFxtw
WssFJlnCnFiA4tPv5pd7HdOgxQkTaPbUHftexfdd/lpfmFvxZVoHcA/32IIKFH63
BU2bnEyYOaW1A4XfNDQH6VG7eT2er1HOlHCtIgzRl0KJNmVggU6DnXnHkUs1PVvg
pyEIR7Xv3GiK7rcS4qCS/9COroqQGFOXJAiLnOaQP5KszT1bMUdoL7mBPTfavnla
LM+2MgKJOWv+JpHQCDp3XwAXX62LLsS2BjdK1Jt6OpGA6IuVQGBSaTIn5K81S+Yh
M6RDKbP3kObYQ+bzLvtWrzgUD3sdht/V8L5ZPS3+Jibvmhae2zRrm/YpJZ77Yjd4
7QliCFGH0+Gwle72yOempFGWULwq7p6yo4dVZXpj1G3XmbZXuvFg4jYeC/usCx+T
kQgMBPWME2m80fCzhJew1pRChSs/lzVreB0Lh6Tm/5Pibmy721J4oUr6oLkaR9Uy
NMrYqnSy0+tCEOXHrpCYhqogyzzdjOlv0gWKqB2uSkO5TkEHv2eyHeiZttAn11qO
sb85q/k0kYQBZZEvKJ9022eyKHjejDhQjKsCVIHhb81BJ1QYnZFIxBiKkVMxf0u5
sT2TTi18eOrYCUGD2WJ+ALyI1zN1sHO0/sn5+XzlC0jg+1KUXoo0j8NYnzmHb0Yx
5lbdlcaw0Uo7iWkFdMYT
=IGGP
-----END PGP SIGNATURE-----



^ permalink raw reply	[flat|nested] 42+ messages in thread

end of thread, other threads:[~2015-03-18  2:06 UTC | newest]

Thread overview: 42+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-03-12  5:12 [Bitcoin-development] Electrum 2.0 has been tagged Thy Shizzle
2015-03-12  5:25 ` Aaron Voisine
  -- strict thread matches above, loose matches on Subject: below --
2015-03-12  5:58 Thy Shizzle
2015-03-12  4:21 Thy Shizzle
2015-03-12 11:51 ` Neill Miller
2015-03-12 12:59   ` Thy Shizzle
2015-03-12 16:39   ` devrandom
2015-03-12  2:38 Thy Shizzle
2015-03-12 10:43 ` Andreas Schildbach
     [not found] <372541993.4372759.1426123313134.JavaMail.yahoo@mail.yahoo.com>
2015-03-12  2:26 ` devrandom
     [not found] <1353069350.4360497.1426126034565.JavaMail.yahoo@mail.yahoo.com>
2015-03-12  2:16 ` Thy Shizzle
2015-03-12  3:59   ` Neill Miller
2015-03-01 15:23 Thomas Voegtlin
2015-03-02  7:09 ` Andreas Schildbach
2015-03-02 15:37 ` Mike Hearn
2015-03-02 17:11   ` Jim
2015-03-11 14:58   ` Thomas Voegtlin
2015-03-11 15:31     ` Andreas Schildbach
2015-03-12  8:56       ` Thomas Voegtlin
2015-03-11 17:14     ` Mike Hearn
2015-03-11 19:04       ` Jim
2015-03-11 19:24         ` Ricardo Filipe
2015-03-11 19:46           ` Gregory Maxwell
2015-03-11 22:57             ` Aaron Voisine
2015-03-11 23:22               ` Mike Hearn
2015-03-11 23:50                 ` devrandom
2015-03-11 23:54                   ` Mike Hearn
2015-03-12  0:11                   ` Gregory Maxwell
2015-03-12  2:41                     ` devrandom
2015-03-12  4:09                       ` Gregory Maxwell
2015-03-12 19:08                         ` Bryan Bishop
2015-03-12 10:30                     ` Andreas Schildbach
2015-03-12 10:28                   ` Andreas Schildbach
2015-03-18  2:06                     ` devrandom
2015-03-12 10:41         ` Andreas Schildbach
2015-03-12  3:43       ` slush
2015-03-12 16:47         ` Mike Hearn
2015-03-12 17:20           ` Gary Rowe
2015-03-12 17:42           ` Gary Rowe
2015-03-12 18:27           ` Natanael
2015-03-12 18:51             ` Andreas Schildbach
2015-03-12 19:14               ` Natanael

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox