HD/BIP 32 implementation mistake?

Question

HD/BIP 32 implementation mistake?

Ayms opened this issue 8 years ago · comments

Are you sure of your BIP 32 implementation? Or am I missing something particular?

My test wallet.dat file shows:

extended private masterkey: xprv9s21ZrQH143K4Wv2JLdfN8td2qVm8qTU7c7hD36gSfsnfNp7AjjgcaGiem5v7KvJnmpee8JeciN8dGvK5r2KZtEt8N4hgnQ3kRP6mQp2JVL

KyruVb9pCVBtxHvof6VrxB7GNk7fmqeSh1wFNwjubyuo4BJLfywz 2016-09-05T11:11:48Z hdmaster=1 # addr=1Dk8v9pw3eAC1uXrQd2PhSwAq7pQr3VUs9 hdkeypath=m

So master seed private key should be: 0bfe13930513cf7ad70bb34161f758417df200d6393e2301d49aa92a9cb6f777

But KyruVb9pCVBtxHvof6VrxB7GNk7fmqeSh1wFNwjubyuo4BJLfywz corresponds to 4ecf2e71d567072fe2f9cda40873afcaae4224e3f249018621a90dd43e88f8de (+01)

Even if hdmaster was finally m/0 (because I don't really see the point of including the master private key in the file and twice) then it should be c9065bdee993a97d148f36ccba46644f67e4572a25a149b02d59bc73a3a1b543

Jonas Schnelli · Answer 1 · Thu Sep 08 2016 21:51:24 GMT+0800 (China Standard Time)

@Ayms:
The hdmaster=1 key is the entropy/seed for the BIP32 chain and not the private key at path m.
Internally, the seed is stored as a (standard) key, this is why it is also included in the dump. IMO dumping the seed (hdmaster=1) can be useful.

But the question is, if the term hdmaster=1 is confusing... maybe hdseed=1 would be better.

Daniel Cousens · Answer 2 · Thu Sep 08 2016 22:31:49 GMT+0800 (China Standard Time)

@jonasschnelli IMHO, hdseed is more appropriate.

Aymeric Vitte · Answer 3 · Fri Sep 09 2016 00:21:05 GMT+0800 (China Standard Time)

@jonasschnelli @dcousens

Ah, OK, not self explainatory indeed (and hdseed looks better), and why then do you include the xprv stuff?

I would have expected the seed only, but another question is: should you include any of them? Why not let the user chose the seed (ie how can you trust a sw doing this for you, even open source))? Or let the user chose a non bip 32 wallet... or a bip 32 wallet where the tree cannot be parsed... etc...

Probably a lot of past discussions about it, currently writing something to try to simplify all this for the users (ie create their own wallet the way they like, btw if there is a link somewhere of the final .dat format I would be glad to get it, did read a lot of your (good) docs but did not find it and this would spare some time compared to finding it in the code) and will comment the choices they have, will let you know if you find an interest.

That's not a counter productive statement but knowing the theory I find it a kind of amazing to dig into it for real...

And now 4 days passed and the complete blockchain is still not there, these are part of the issues that Convergence intends to address (sorry not very detailed but the concepts are not vague at all)

Jonas Schnelli · Answer 4 · Fri Sep 09 2016 14:42:08 GMT+0800 (China Standard Time)

I would have expected the seed only, but another question is: should you include any of them?

The xpriv (extended master private key) was included to provide a flexible and common way how to export your master key and – maybe once – import in into a different Core on non-core wallet.
The hdmaster=1 key is there for legacy reasons.

[...] Or let the user chose a non bip 32 wallet...

Users can disable the HD feature by pass in -usehd=0.

Why not let the user chose the seed (ie how can you trust a sw doing this for you, even open source))?

This would be another question. Providing user based entropy can be dangerous and should only be exposed to experts.
Starting a HD wallet with a given xpriv should be possible (PR is on the way).

You need to understand that there where serval tries (search after BIP32 in the closed pull requests) to add HDness to Cores wallet (much more flexible and complex ones).

The current implementation mainly solves one fundamental issue: the need of repeating create backups.

With the current BIP32, the "only features" is that users can backup right after creation and can be sure every key they will create in future will be reconstructable.

Aymeric Vitte · Answer 5 · Sat Sep 10 2016 00:42:47 GMT+0800 (China Standard Time)

The hdmaster=1 key is there for legacy reasons.

For legacy reasons??

Providing user based entropy can be dangerous and should only be exposed to experts.

Yes, working on this, but like importing keys the possibility should exist

Starting a HD wallet with a given xpriv should be possible (PR is on the way).

When do you think it could be available? Why based on xpriv and not the seed? Is it foreseen to have an option to importwallet and override the existing one?

The current implementation mainly solves one fundamental issue: the need of repeating create backups.

Yes

With the current BIP32, the "only features" is that users can backup right after creation and can be sure every key they will create in future will be reconstructable.

Yes, is BIP32 trustable remains questionable, but that's what we have, probably it would not be bad to be able to import BIP32 generated keys without any reference to it + the master key/seed + the tree (cf my importwallet suggestion above)

Aymeric Vitte · Answer 6 · Tue Sep 13 2016 20:52:53 GMT+0800 (China Standard Time)

Please see bitcoin-wallets

maflcko · Answer 7 · Wed Sep 14 2016 03:56:33 GMT+0800 (China Standard Time)

So what about renaming to hdseed? Is anyone working on this?

Jonas Schnelli · Answer 8 · Wed Sep 14 2016 20:33:44 GMT+0800 (China Standard Time)

@MarcoFalke we could change it, though, we would have to be careful.

We are using a similar term in our RPC API (hdmasterkeyid).
The internal function to set a extended keys seed is named setMaster(seed).
Maybe there are implementations in the wild (until the rename to hdseed gets deployed) who rely on the hdmaster=1 string

I think hdmaster is not entirely wrong. Its not an extended master key (xpriv...), but someone could argue that it's still a master key (a.k.a. seed).