Bitcoin.py is the current host to the bip32 generator and the Electrum generator (when it was still present). Check back to the 1.8.1 tag for the last release with the Electrum sequence generator.
git grep is your friend - when you have a rough idea of how it all works.
If you're interested in the generators/etc - I have a public blog about the different generators:
http://e4a-ne.blogspot.com/2013/07/bitcoin-deterministic-key-generation.html
It contains a Java version of the public key derivation algorithm using master public key for Electrum sequences.
Also - once my Electroid: Electrum for Android - Native Edition project is released publicly, everybody will have access to the ElectrumJ (tentative name) library which will expose BIP32 and Electrum sequence generation logic.
Topic: Restore-from-seed: diff results lower/uppercase hex! (Read 4190 times)
At last! I was beginning to worry noone gave a f 
ck.
In all those bazillion files on GitHub, which one is the sequence generator? I want to study it myself. Christ, I've never even learned Python. And everything object-oriented gives me a headache.
ck.In all those bazillion files on GitHub, which one is the sequence generator? I want to study it myself. Christ, I've never even learned Python. And everything object-oriented gives me a headache.
Looking at the source code for the Electrum sequence generator - it is indeed vulnerable to raw data entry being broken: the seed is taken in as raw data and passed to a hash - perhaps it is validated that it is hex (didn't look that far) but it doesn't hex-decode it so you have the problem of multiple representations for what looks to be the same data.
Ran into this myself when trying to make a consistent Electrum key generator for Java.
Did a quick check and the 1.9 wallet series (which uses BIP 0032) does not have this silent problem, it hex decodes seed input.
Ran into this myself when trying to make a consistent Electrum key generator for Java.
Did a quick check and the 1.9 wallet series (which uses BIP 0032) does not have this silent problem, it hex decodes seed input.
Maybe I should check first if my understanding of the mapping between hex strings and 12 word phrases is correct. I've examined mnemonic.py and made an Excel spreadsheet which I *think* does the conversion correctly, both ways.
The first twelve words in the dictionary: "like just love know never want time out there make look eye" (awwwwww... I think, poetry was never really my thing) should become the hex string: 00285DFE00285E0100285E0400285E07, right?
ETA again: which piece of all that stuff in github generates the private keys from the seed? I'd like to take a look at it.
The first twelve words in the dictionary: "like just love know never want time out there make look eye" (awwwwww... I think, poetry was never really my thing) should become the hex string: 00285DFE00285E0100285E0400285E07, right?
ETA again: which piece of all that stuff in github generates the private keys from the seed? I'd like to take a look at it.
UPDATE: found out the real culprit, ignore the struckout blather below.
You get a different set of private key/address pairs, depending on whether or not you specify the hex digits a-f as 'a-f' or 'A-F'!
It would appear that electrum uses the lowercase version internally. If you type the lowercase hex key, or the 12-word passphrase, electrum converts flawlessly between the two and generates the 'correct' set of keys. But if you use the uppercase-hex version, it generates a different set of keys. (but converts to the SAME 12-word passphrase)
I don't really understand why this should be. Surely the wallet generation algorithm takes as its seed, the 128 bits that the hex string is supposed to symbolise to humans, NOT the 256 bit string that would be the literal conversion of the ascii hex string?
In any case I think you should either put a warning on to tell people the hex string must be lowercase, or better still, handle the conversion properly with electrum. By the way, you ARE using the 'real' 128 bits, and not the 'fake' 256 bits of the ascii hex string as a seed, yes?
Subject says it all really. I get one bunch of keys if I type the 12 word phrase in, but a completely different bunch if I type the hex digits. And when I check what electrum thinks the wallet seed is supposed to be, it gives me the same 12 word bunch in both cases!
(Electrum does not tell me the hex version. y u no do this?)
I get the 'correct' wallet (i.e. the one with ALL MY MONEY in it) from typing in the 12 word phrase. Could this be something to do with the 'master public key'? What the hell is that anyway? Is it written up somewhere?
You get a different set of private key/address pairs, depending on whether or not you specify the hex digits a-f as 'a-f' or 'A-F'!
It would appear that electrum uses the lowercase version internally. If you type the lowercase hex key, or the 12-word passphrase, electrum converts flawlessly between the two and generates the 'correct' set of keys. But if you use the uppercase-hex version, it generates a different set of keys. (but converts to the SAME 12-word passphrase)
I don't really understand why this should be. Surely the wallet generation algorithm takes as its seed, the 128 bits that the hex string is supposed to symbolise to humans, NOT the 256 bit string that would be the literal conversion of the ascii hex string?
In any case I think you should either put a warning on to tell people the hex string must be lowercase, or better still, handle the conversion properly with electrum. By the way, you ARE using the 'real' 128 bits, and not the 'fake' 256 bits of the ascii hex string as a seed, yes?
(Electrum does not tell me the hex version. y u no do this?)
I get the 'correct' wallet (i.e. the one with ALL MY MONEY in it) from typing in the 12 word phrase. Could this be something to do with the 'master public key'? What the hell is that anyway? Is it written up somewhere?
Jump to: