bip-entropy-from-bip32.mediawiki

Moved to bitcoin/bips#910

__hmac_sha512() the "key" is our constant bip-entropy-from-k. I am unclear about what you mean for the last part of your message, as the message is our input and is the correct order for the function hmac.new(key, message, digestmod).

Python reference: https://docs.python.org/3/library/hmac.html#hmac.new

Other usage in the wild for example and in Bitcoin Core

@peter-conalgo

Yeah, running it thru HMAC512 isn't adding much, but does create another barrier. I suppose for the XPRV case, we could just clear the child num / depth / master fingerprint and such. Your call, but I think it's appropriate for the purposes of the BIP to be able to output XPRV for those tools that need it as a master key.

I think you are right, in the context of this BIP it should use the HMAC. While it makes no difference, in the context of this BIP's applications, it seems like an odd-ball to not use the entropy right?

1. I'll switch msg vs. key to HMAC512 to match your usage. I think the text of the BIP could be improved to make this clear to other implementors. Probably just a few more words here, or maybe whatever they say in other BIPs when they do the same thing.

The resulting private key (k) is then processed with HMAC-SHA512(k, "bip-entropy-from-bip32") to produce 512 bits of entropy.

2. At this point, I'm against using HMAC512 step for XPRV to XPRV case. One reason: the parent wallet can make a PSBT operating on the derived XPRV's funds. That's a positive, IMHO. There are probably other cases where keeping the normal bip32 derivation working is helpful.

1. Welp, I have updated the wording. My bad.

2. Oh, I had quite warmed to the idea and pushed some code 🤦 but no worries: what would the PSBT usecase be specifically in this case and why would it be considered part of the entropy applications? I think others may have similar questions and we should probably make a note of the rationale. In another thought, there is nothing precluding the use of standard BIP32 derivation regardless of this proposal.

What I found interesting on second thought since I mentioned it was that this is different than BIP32 derivation mainly because we're also resetting the extended key child number etc., so I regard it as a different application entirely than BIP32 child derivation.

• Coldcard and your library are now in sync again. Coldcard supports WIF case properly now.
• Only remaining question is XPRV design issue. I'm for leveraging BIP32 unchanged.
• Minor concern: this BIP creates Bitcoin keys from random entropy. There is a very small chance that you'll make an invalid key that is zero or bigger than the order of the curve. I suggest a comment that this be reported to the user, with recommendation to move to next index value and to buy a lottery ticket immediately. BIP32 says:

• In case parse₂₅₆(I_L) ≥ n or k_i = 0, the resulting key is invalid, and one should proceed with the next value for i. (Note: this has probability lower than 1 in 2¹²⁷.)

One reason: the parent wallet can make a PSBT operating on the derived XPRV's funds.

Can you explain this use-case a bit more detail?

Use case: I generate XPRV for a new mobile wallet, derived from my master secret held in a Coldcard. I play around a bit, and then the wallet vendor goes evil, and/or Apple removes it from my device without my consent. To recover my funds, I can construct a PSBT file, containing full paths (ie. m/83696968'/32'/0'/whatever/...) and use my Coldcard to sign that. No help needed from extinct wallet, although I might have to search a little for derived key paths.

If the HMAC512 step was included, I'd have to import the XPRV into a Coldcard or other signing device, and then search for UTXO from that, and make PSBT based on that as a the master key.

* Coldcard and your library are now in sync again. Coldcard supports WIF case properly now.

* Only remaining question is XPRV design issue. I'm for leveraging BIP32 unchanged.

* Minor concern: this BIP creates Bitcoin keys from random entropy. There is a very small chance that you'll make an invalid key that is zero or bigger than the order of the curve. I suggest a comment that this be reported to the user, with recommendation to move to next index value and to buy a lottery ticket immediately. BIP32 says:

• In case parse256(IL) ≥ n or ki = 0, the resulting key is invalid, and one should proceed with the next value for i. (Note: this has probability lower than 1 in 2127.)

right from https://en.bitcoin.it/wiki/Secp256k1, n = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141 so the probability of exceeding n-1 is very low and as you say < 2^-127. close to 0 probability, but you could test for it then hash again.

Use case: I generate XPRV for a new mobile wallet, derived from my master secret held in a Coldcard. I play around a bit, and then the wallet vendor goes evil, and/or Apple removes it from my device without my consent. To recover my funds, I can construct a PSBT file, containing full paths (ie. m/83696968'/32'/0'/whatever/...) and use my Coldcard to sign that. No help needed from extinct wallet, although I might have to search a little for derived key paths.

If the HMAC512 step was included, I'd have to import the XPRV into a Coldcard or other signing device, and then search for UTXO from that, and make PSBT based on that as a the master key.

few comments:

• I don't think any current wallets support importing XPRV?

• If I understand you propose to special case new export/import type XPRV to not use HMAC unlike other seed types

• that trick would only work for this new XPRV type if other types are going through HMAC, if you wanted to handle on single coldcard both seed derivation and wallet derived from those seeds, maybe be better to work generically across key types?

• eg you could type the seed into the same coldcard, and the wallet path and proceed as usual

• or add user interface to select seed from the same cold card seed manager

however I think it may be undesirable for security reasons: you don't want to run other code on the seed manager because it's very high value, eg if there was a bug in the wallet code. For this reason ideally I think the seed manager device should be a single function coldcard, other HWW re-purposed, or an always offline computer with no network card, say locked in a physical safe.

Even worse would be people extracting full paths and putting the master seed manager seed into a standard wallet, so the HMAC there is almost a feature in making that unsupported/incompatible with BIP32 derivation paths below the derived seed.

Even worse would be people extracting full paths and putting the master seed manager seed into a standard wallet, so the HMAC there is almost a feature in making that unsupported/incompatible with BIP32 derivation paths below the derived seed.

Very true. No-one needs this standard to in order to export a BIP32 XPRV into another wallet that's looking for it. We'd just be suggesting a subpath to use, which isn't very interesting. Applying HMAC512 as a "firewall" or operational "barrier" is consistent with the rest of this standard and how it works.

So I'll change Coldcard (back) to making XPRV from the HMAC entropy, unless someone gives a reason otherwise.

Even worse would be people extracting full paths and putting the master seed manager seed into a standard wallet, so the HMAC there is almost a feature in making that unsupported/incompatible with BIP32 derivation paths below the derived seed.

Very true. No-one needs this standard to in order to export a BIP32 XPRV into another wallet that's looking for it. We'd just be suggesting a subpath to use, which isn't very interesting. Applying HMAC512 as a "firewall" or operational "barrier" is consistent with the rest of this standard and how it works.

So I'll change Coldcard (back) to making XPRV from the HMAC entropy, unless someone gives a reason otherwise.

out of interest which application do you have in mind for the XPRV? is there a coldcard mode for importing them?

Yes, Coldcard supports XPRV as a master secret (held in secure element). That's why it came up when I implemented this.

I have added the reference to Coldcard implementation Coldcard/firmware#39, to the BIP pull request. Everything looks good from my side. Just awaiting the BIP number assignment.

This proposal has become BIP85