Moved to bitcoin/bips#910
Last active
June 11, 2020 12:15
-
-
Save ethankosakovsky/268c52f018b94bea29a6e809381c05d6 to your computer and use it in GitHub Desktop.
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Can you explain this use-case a bit more detail?