The old code hashes the hex representation, which is a pretty harmless bug (no loss of entropy), but cannot be changed for compatibility reasons.
The new code will hash the string directly.
It is an arbitrary string, not an hex number representation.
so, no, it's not a bug, it is intentional.
Topic: hashing the seed or hashing the hex-string representation of the seed? (Read 1222 times)
December 18, 2013, 12:29:58 AM
November 09, 2013, 04:20:25 PM
I'm playing around with electrum 1.9.2
It seems that with seed_version=4 if I do
./electrum --offline --wallet=testwallet restore
and enter "ffff" as seed I will get different results than when entering "FFFF". Looking into the code it seems you are indeed hashing the string representation of that hex number:
account.py, class OldAccount
and seed is the hex string representation of the seed. I guess that cannot be chaned anymore without making it incompatible.
Now I looked into the new seed_version = 6 stuff with bip-32, I simply patched wallet.py to set self.seed_version=6 to trigger the new code paths and it still is hashing the string representation:
shouldn't this line be
I changed it to see what happens and also inserted a few prints here and there to see whether its handling binary data or hex-strings and now it seems to work correctly and will produce the same keys for "ffff" and "FFFF".
with above patch and bip32 enabled I get the following addresses from "FFFF" or "ffff"
1JFGdf7FsmNZEsPWUZeCRqcKUZF4iTLKjk
1BbHtbsX4ajyb6vVrTtatrUiGMGUtZaVMX
1HjFdepBf9qg8BKmLtRf9iYBWa1YFRV2hp
1QHErKePKQurWELiJD2pTwaxEwZZPjMogX
16p6r7vyj8B2t6SbugYgoHQJhX8XkBpX4G
1Bhqh25w998MsxJjnEfAxPLvrjCi4zB7xF
13k5Zivs8Zw9QUfYcVbG3w8rHV3KjTR2Xk
19hVwRqH57FtFYKyZf2SsEsoEeFJ3aj2NH
and the argument to bip32_seed() is now 974e4be2c4f570e64ec86819bf8d14a66584481993b5e82d6400c78288025c5c40cd6e1d1218107 ee778174af562ceae7e4c31ff206f7cfe5708fb65ba4853f5
Please tell me that this is indeed a bug and not intentional
It seems that with seed_version=4 if I do
./electrum --offline --wallet=testwallet restore
and enter "ffff" as seed I will get different results than when entering "FFFF". Looking into the code it seems you are indeed hashing the string representation of that hex number:
account.py, class OldAccount
Code:
def stretch_key(self,seed):
oldseed = seed
for i in range(100000):
seed = hashlib.sha256(seed + oldseed).digest()
return string_to_number( seed )
Now I looked into the new seed_version = 6 stuff with bip-32, I simply patched wallet.py to set self.seed_version=6 to trigger the new code paths and it still is hashing the string representation:
Code:
def create_master_keys(self, account_type):
master_k, master_c, master_K, master_cK = bip32_init(self.get_seed(None))
[...]
def get_seed(self, password):
s = pw_decode(self.seed, password)
if self.seed_version == 4:
seed = s
else:
seed = mnemonic_hash(s)
#todo: #self.sequences[0].check_seed(seed)
return seed
shouldn't this line be
Code:
else:
seed = mnemonic_hash(s.decode('hex'))
I changed it to see what happens and also inserted a few prints here and there to see whether its handling binary data or hex-strings and now it seems to work correctly and will produce the same keys for "ffff" and "FFFF".
with above patch and bip32 enabled I get the following addresses from "FFFF" or "ffff"
1JFGdf7FsmNZEsPWUZeCRqcKUZF4iTLKjk
1BbHtbsX4ajyb6vVrTtatrUiGMGUtZaVMX
1HjFdepBf9qg8BKmLtRf9iYBWa1YFRV2hp
1QHErKePKQurWELiJD2pTwaxEwZZPjMogX
16p6r7vyj8B2t6SbugYgoHQJhX8XkBpX4G
1Bhqh25w998MsxJjnEfAxPLvrjCi4zB7xF
13k5Zivs8Zw9QUfYcVbG3w8rHV3KjTR2Xk
19hVwRqH57FtFYKyZf2SsEsoEeFJ3aj2NH
and the argument to bip32_seed() is now 974e4be2c4f570e64ec86819bf8d14a66584481993b5e82d6400c78288025c5c40cd6e1d1218107 ee778174af562ceae7e4c31ff206f7cfe5708fb65ba4853f5
Please tell me that this is indeed a bug and not intentional
Jump to: