Reloading this PR with minimal, backward-compatible changes.
260@@ -248,7 +261,7 @@ INPUT:
261 * PATH: m/83696968'/128169'/64'/0'
262
263 OUTPUT
264-* DERIVED ENTROPY=492db4698cf3b73a5a24998aa3e9d7fa96275d85724a91e71aa2d645442f878555d078fd1f1f67e368976f04137b1f7a0d19232136ca50c44614af72b5582a5c
265+* DERIVED ENTROPY=74a2e87a9ba0cdd549bdd2f9ea880d554c6c355b08ed25088cfa88f3f1c4f74632b652fd4a8f5fda43074c6f6964a3753b08bb5210c8f5e75c07a4c2a20bf6e9
this is wrong, how did you calculate it ?
In your previous PR https://github.com/bitcoin/bips/pull/1600/files you have correctly fixed bug (incorrect entropy) in Base64 pwd application
here you’re fixing hex app that is not broken and correct value MUST be 492db4698cf3b73a5a24998aa3e9d7fa96275d85724a91e71aa2d645442f878555d078fd1f1f67e368976f04137b1f7a0d19232136ca50c44614af72b5582a5c (no change here)
Thank you for catching that. I didn’t read the diff properly. This is for Base64:
0bipsea derive -x xprv9s21ZrQH143K2LBWUUQRFXhucrQqBpKdRRxNVq2zBqsx8HVqFk2uYo8kmbaLLHRdqtQpUm98uKfu3vca1LqdGhUtyoFnCNkfmXRyPXLjbKb -a base64 -n 21 -d
1dKLoepugzdVJvdL56ogNV
2entropy: 74a2e87a9ba0cdd549bdd2f9ea880d554c6c355b08ed25088cfa88f3f1c4f74632b652fd4a8f5fda43074c6f6964a3753b08bb5210c8f5e75c07a4c2a20bf6e9
wrong entropy is in base64 pwd application, currently:
d7ad61d4a76575c5bad773feeb40299490b224e8e5df6c8ad8fe3d0a6eed7b85ead9fef7bcca8160f0ee48dc6e92b311fc71f2146623cc6952c03ce82c7b63fe
correct:
74a2e87a9ba0cdd549bdd2f9ea880d554c6c355b08ed25088cfa88f3f1c4f74632b652fd4a8f5fda43074c6f6964a3753b08bb5210c8f5e75c07a4c2a20bf6e9
could you possibly split this into “b64 entropy fix only PR” and “the rest” ?
Yeahbut I’d also include the BIP32 comment because it’s a fact.
96@@ -93,7 +97,8 @@ OUTPUT
97
98 ==Reference Implementation==
99
100-* Python library implementation: [https://github.com/ethankosakovsky/bip85]
101+* Python 3.x library implementation: [https://github.com/akarve/bipsea]
Thank you for opening this, was going to ask. If this is to be done, seems best to do it before updating the BIP status to Final in #1676.
Can you prefix each commit message with BIP85: or refer to it in the commit title?
Consider doing the test vector correction in a separate commit with a full explanation of what was incorrect and the fix.
Can you also provide an explanation of the Base64 entropy fix in the commit message.
Please provide a better commit message for the “add warning” commit.
Did you want to make the changes in the abstract and definitions sections that you did in #1600?
cc @nvk for review
Can you also provide an explanation of the Base64 entropy fix in the commit message. @jonatack this is my bug when I was adding base64 app to the BIP, seems it went unnoticed for long time…
Can you also provide an explanation of the Base64 entropy fix in the commit message.
@jonatack this is my bug when I was adding base64 app to the BIP, seems it went unnoticed for long time…
Here’s the standalone fix: https://github.com/bitcoin/bips/pull/1683
Did you want to make the changes in the abstract and definitions sections that you did in #1600?
I want to but not in this changeset. Let’s get through the hard parts then we can optimize on top of that. I’m tryna keep the changesets as small as possible for now.
269@@ -257,7 +270,7 @@ The derivation path format is: <code>m/83696968'/707764'/{pwd_len}'/{index}'</co
270
271 `20 <= pwd_len <= 86`
272
273-[https://datatracker.ietf.org/doc/html/rfc4648 Base64] encode the all 64 bytes of entropy.
274+[https://datatracker.ietf.org/doc/html/rfc4648 Base64] encode all 64 bytes of entropy.
232@@ -224,6 +233,10 @@ Application number: 32'
233
234 Taking 64 bytes of the HMAC digest, the first 32 bytes are the chain code, and second 32 bytes[1] are the private key for BIP32 XPRV value. Child number, depth, and parent fingerprint are forced to zero.
235
236+WARNING: The above is inconsistent with BIP32 which uses the first 32 bytes for the private key.
s/ which/, which/
0WARNING: The above is inconsistent with BIP32, which inverses this order, i.e., uses the first 32 bytes for the private key.
Co-authored-by: Jon Atack <jon@atack.com>
232@@ -224,6 +233,10 @@ Application number: 32'
233
234 Taking 64 bytes of the HMAC digest, the first 32 bytes are the chain code, and second 32 bytes[1] are the private key for BIP32 XPRV value. Child number, depth, and parent fingerprint are forced to zero.
0Taking 64 bytes of the HMAC digest, the first 32 bytes are the chain code, and the second 32 bytes[1] are the private key for the BIP32 XPRV value. Child number, depth, and parent fingerprint are forced to zero.
230@@ -222,7 +231,11 @@ OUTPUT
231 ===XPRV===
232 Application number: 32'
233
234-Taking 64 bytes of the HMAC digest, the first 32 bytes are the chain code, and second 32 bytes[1] are the private key for BIP32 XPRV value. Child number, depth, and parent fingerprint are forced to zero.
235+Taking 64 bytes of the HMAC digest, the first 32 bytes are the chain code, and the second 32 bytes[1] are the private key for the BIP32 XPRV value. Child number, depth, and parent fingerprint are forced to zero.
236+
237+{{Warning|The above ordering reverses BIP32, wherein the private key is the first 32 bytes and the chain code is the last 32 bytes.}}
0{{Warning|The above ordering is the inverse of BIP32, where the first 32 bytes are the private key, and the second 32 bytes are the chain code.}}
{{Warning|text}} in the latest push? I’m unsure how this renders and am probably missing something)
Why add the {{Warning|text}} in the latest push?
That’s the mediawiki standard for warnings. It renders the text in a box with a symbol.
230@@ -222,7 +231,11 @@ OUTPUT
231 ===XPRV===
232 Application number: 32'
233
234-Taking 64 bytes of the HMAC digest, the first 32 bytes are the chain code, and second 32 bytes[1] are the private key for BIP32 XPRV value. Child number, depth, and parent fingerprint are forced to zero.
235+Taking 64 bytes of the HMAC digest, the first 32 bytes are the chain code, and the second 32 bytes[1] are the private key for the BIP32 XPRV value. Child number, depth, and parent fingerprint are forced to zero.
32 bytes[1] here as well while touching this line.
415@@ -370,6 +416,17 @@ The reason for running the derived key through HMAC-SHA512 and truncating the re
416
417 Many thanks to Peter Gray and Christopher Allen for their input, and to Peter for suggesting extra application use cases.
418
419+==Change Log==
420+
421+===1.1.0===
I think this would need a date, for instance, like in BIP352:
0== Changelog ==
1
2* '''1.0.1''' (2024-06-22):
3** Add steps to fail if private key sum is zero (for sender) or public key sum is point at infinity (for receiver), add corresponding test vectors.
4* '''1.0.0''' (2024-05-08):
5** Initial version, merged as BIP-352.
However, having looked at all the changes in https://github.com/bitcoin/bips/commits/master/bip-0085.mediawiki, I think it’s also fine to defer that to a separate PR that adds a fuller history.
223+Uses the most significant 32 bytes<ref name="curve-order">
224+There is a very small chance that you'll make an invalid
225+key that is zero or larger than the order of the curve. If this occurs, software
226+should hard fail (forcing users to iterate to the next index). From BIP32:
227+<blockquote>
228+In case parse<sub>256</sub>(I<sub>L</sub>) is 0 or ≥ n, the resulting key is invalid, and one should proceed with the next value for i. (Note: this has probability lower than 1 in 2<sup>127</sup>.)
Since this quotes BIP32, note that since 2014 in #12, BIP32 states “In case parse256(IL) ≥ n or ki = 0” (and before that change, BIP32 stated “In case IL ≥ n or ki = 0”).
0In case parse<sub>256</sub>(I<sub>L</sub>) ≥ n or k<sub>i</sub> = 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<sup>127</sup>.)
99@@ -93,8 +100,9 @@ OUTPUT
100
101 ==Reference Implementation==
102
103-* Python library implementation: [https://github.com/ethankosakovsky/bip85]
104-* JavaScript library implementation: [https://github.com/hoganri/bip85-js]
105+* 1.1 Python 3.x library implementation: [https://github.com/akarve/bipsea]
106+* 1.0 Python 2.x library implementation: [https://github.com/ethankosakovsky/bip85]
107+* 1.0 JavaScript library implementation: [https://github.com/hoganri/bip85-js]
218@@ -207,7 +219,16 @@ OUTPUT:
219 ===HD-Seed WIF===
220 Application number: 2'
221
222-Uses 256 bits[1] of entropy as the secret exponent to derive a private key and encode as a compressed WIF which will be used as the hdseed for Bitcoin Core wallets.
We’ve kept most of this sentence intact below, I’ll restore the 256 bits part.
of entropy as the secret exponent to derive a private key and encode as a compressed WIF which will be used as the hdseed for Bitcoin Core wallets.
33@@ -33,6 +34,9 @@ The terminology related to keychains used in the wild varies widely, for example
34 # '''BIP39 mnemonic''' is the mnemonic phrase that is calculated from the entropy used before hashing of the mnemonic in BIP39.
35 # '''BIP39 seed''' is the result of hashing the BIP39 mnemonic seed.
36
37+When in doubt, assume '''big endian''' byte serialization, such that the leftmost
54@@ -51,6 +55,9 @@ For each application that requires its own wallet, a unique private key is deriv
55
56 The HMAC-SHA512 function is specified in [http://tools.ietf.org/html/rfc4231 RFC 4231].
57
58+Application codes may be arbitrary but are preferably semantic in some way, such as a BIP number or
59+ASCII character code sequence.
242@@ -222,7 +243,11 @@ OUTPUT
243 ===XPRV===
244 Application number: 32'
245
246-Taking 64 bytes of the HMAC digest, the first 32 bytes are the chain code, and second 32 bytes[1] are the private key for BIP32 XPRV value. Child number, depth, and parent fingerprint are forced to zero.
247+Taking 64 bytes of the HMAC digest, the first 32 bytes are the chain code, and the second 32 bytes<ref name="curve-order" /> are the private key for the BIP32 XPRV value. Child number, depth, and parent fingerprint are forced to zero.
248+
249+{{Warning|BIP32 reverses the above by taking the first 32 bytes as the private key, and the second 32 bytes as the chain code.}}
0{{Warning|The above is the inverse of BIP32, which takes the first 32 bytes as the private key, and the second 32 bytes as the chain code.}}
Review comments follow.
0--- a/bip-0085.mediawiki
1+++ b/bip-0085.mediawiki
2@@ -35,11 +35,11 @@ The terminology related to keychains used in the wild varies widely, for example
3
4 ==Motivation==
5
6-Most wallets implement BIP32 which defines how a BIP32 root key can be used to derive keychains. As a consequence, a backup of just the BIP32 root key is sufficient to include all keys derived from it. BIP32 does not have a human friendly serialization of the BIP32 root key (or BIP32 extended keys in general) which makes paper backups or manually restoring the key more error-prone. BIP39 was designed to solve this problem but rather than serialize the BIP32 root key, it takes some entropy, encoded to a "seed mnemonic", which is then hashed to derive the BIP39 seed which can be turned into the BIP32 root key. Saving the BIP39 mnemonic is enough to reconstruct the entire BIP32 keychain, but a BIP32 root key cannot be reversed back to the BIP39 mnemonic.
7+Most wallets implement BIP32 which defines how a BIP32 root key can be used to derive keychains. As a consequence, a backup of just the BIP32 root key is sufficient to include all keys derived from it. BIP32 does not have a human-friendly serialization of the BIP32 root key (or BIP32 extended keys in general), which makes paper backups or manually restoring the key more error-prone. BIP39 was designed to solve this problem, but rather than serialize the BIP32 root key, it takes some entropy, encoded to a "seed mnemonic", which is then hashed to derive the BIP39 seed, which can be turned into the BIP32 root key. Saving the BIP39 mnemonic is enough to reconstruct the entire BIP32 keychain, but a BIP32 root key cannot be reversed back to the BIP39 mnemonic.
8
9-Most wallets implement BIP39, so on initialization or restoration, the user must interact with a BIP39 mnemonic. Most wallets do not support BIP32 extended private keys, so each wallet must either share the same BIP39 mnemonic, or have a separate BIP39 mnemonic entirely. Neither scenarios are particularly satisfactory for security reasons. For example, some wallets may be inherently less secure like hot wallets on smartphones, Join Market servers, or Lightning Network nodes. Having multiple seeds is far from desirable, especially for those who rely on split key or redundancy backups in different geological locations. Adding is necessarily difficult and may result in users being more lazy with subsequent keys, resulting in compromised security or loss of keys.
10+Most wallets implement BIP39, so on initialization or restoration, the user must interact with a BIP39 mnemonic. Most wallets do not support BIP32 extended private keys, so each wallet must either share the same BIP39 mnemonic, or have a separate BIP39 mnemonic entirely. Neither scenario is particularly satisfactory for security reasons. For example, some wallets may be inherently less secure, like hot wallets on smartphones, Join Market servers, or Lightning Network nodes. Having multiple seeds is far from desirable, especially for those who rely on split key or redundancy backups in different geological locations. Adding keys is necessarily difficult and may result in users being more lazy with subsequent keys, resulting in compromised security or loss of keys.
11
12-There is added complication with wallets that implement other standards, or no standards at all. Bitcoin Core wallet uses a WIF as the ''hdseed'', and yet other wallets like Electrum use different mnemonic schemes to derive the BIP32 root key. Other cryptocurrencies like Monero also use an entirely different mnemonic scheme.
13+There is an added complication with wallets that implement other standards, or no standards at all. The Bitcoin Core wallet uses a WIF as the ''hdseed'', and yet other wallets, like Electrum, use different mnemonic schemes to derive the BIP32 root key. Other cryptocurrencies, like Monero, use an entirely different mnemonic scheme.
14
15 Ultimately, all of the mnemonic/seed schemes start with some "initial entropy" to derive a mnemonic/seed, and then process the mnemonic into a BIP32 key, or private key. We can use BIP32 itself to derive the "initial entropy" to then recreate the same mnemonic or seed according to the specific application standard of the target wallet. We can use a BIP44-like categorization to ensure uniform derivation according to the target application type.
16
17@@ -47,9 +47,9 @@ Ultimately, all of the mnemonic/seed schemes start with some "initial entropy" t
18
19 We assume a single BIP32 master root key. This specification is not concerned with how this was derived (e.g. directly or via a mnemonic scheme such as BIP39).
20
21-For each application that requires its own wallet, a unique private key is derived from the BIP32 master root key using a fully hardened derivation path. The resulting private key (k) is then processed with HMAC-SHA512, where the key is "bip-entropy-from-k", and the message payload is the private key k: <code>HMAC-SHA512(key="bip-entropy-from-k", msg=k)</code>. The result produces 512 bits of entropy. Each application SHOULD use up to the required number of bits necessary for their operation truncating the rest.
22+For each application that requires its own wallet, a unique private key is derived from the BIP32 master root key using a fully hardened derivation path. The resulting private key (k) is then processed with HMAC-SHA512, where the key is "bip-entropy-from-k", and the message payload is the private key k: <code>HMAC-SHA512(key="bip-entropy-from-k", msg=k)</code>. The result produces 512 bits of entropy. Each application SHOULD use up to the required number of bits necessary for their operation, and truncating the rest.
23
24-The HMAC-SHA512 function is specified in [http://tools.ietf.org/html/rfc4231 RFC 4231].
25+The HMAC-SHA512 function is specified in [https://tools.ietf.org/html/rfc4231 RFC 4231].
Co-authored-by: Jon Atack <jon@atack.com>
Co-authored-by: Jon Atack <jon@atack.com>
master, agree?
387+The derivation path format is: <code>m/83696968'/89101'/{sides}'/{rolls}'/{index}'</code>
388+
389+ 2 <= sides <= 2^32 - 1
390+ 1 <= rolls <= 2^32 - 1
391+
392+Use this application to generate PIN numbers or any other numeric secret.
431+
432+===1.1.0 (2024-10-20)===
433+
434+====Added====
435+
436+* Dice application
0* Dice application 89101'
53 ==Specification==
54
55 We assume a single BIP32 master root key. This specification is not concerned with how this was derived (e.g. directly or via a mnemonic scheme such as BIP39).
56
57-For each application that requires its own wallet, a unique private key is derived from the BIP32 master root key using a fully hardened derivation path. The resulting private key (k) is then processed with HMAC-SHA512, where the key is "bip-entropy-from-k", and the message payload is the private key k: <code>HMAC-SHA512(key="bip-entropy-from-k", msg=k)</code>. The result produces 512 bits of entropy. Each application SHOULD use up to the required number of bits necessary for their operation truncating the rest.
58+For each application that requires its own wallet, a unique private key is derived from the BIP32 master root key using a fully hardened derivation path. The resulting private key (k) is then processed with HMAC-SHA512, where the key is "bip-entropy-from-k", and the message payload is the private key k: <code>HMAC-SHA512(key="bip-entropy-from-k", msg=k)</code>. The result produces 512 bits of entropy. Each application SHOULD use up to the required number of bits necessary for their operation, and truncating the rest.
0For each application that requires its own wallet, a unique private key is derived from the BIP32 master root key using a fully hardened derivation path. The resulting private key (k) is then processed with HMAC-SHA512, where the key is "bip-entropy-from-k", and the message payload is the private key k: <code>HMAC-SHA512(key="bip-entropy-from-k", msg=k)</code>. The result produces 512 bits of entropy. Each application SHOULD use up to the required number of bits necessary for their operation, and truncate the rest.
226+<blockquote>
227+In case parse<sub>256</sub>(I<sub>L</sub>) ≥ n or k<sub>i</sub> = 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<sup>127</sup>.)
228+</blockquote>
229+</ref>
230+of entropy as the secret exponent to derive a private key and encode as a compressed
231+WIF which will be used as the hdseed for Bitcoin Core wallets.
0WIF that will be used as the hdseed for Bitcoin Core wallets.
(should be either “, which” or “that”
105
106 ==Applications==
107
108 The Application number defines how entropy will be used post processing. Some basic examples follow:
109
110 Derivation path uses the format <code>m/83696968'/{app_no}'/{index}'</code> where ''{app_no}'' is the path for the application, and ''{index}'' is the index.
0Derivation paths follow the format <code>m/83696968'/{app_no}'/{index}'</code>, where ''{app_no}'' is the path for the application, and ''{index}'' is the index.
41
42-Most wallets implement BIP32 which defines how a BIP32 root key can be used to derive keychains. As a consequence, a backup of just the BIP32 root key is sufficient to include all keys derived from it. BIP32 does not have a human friendly serialization of the BIP32 root key (or BIP32 extended keys in general) which makes paper backups or manually restoring the key more error-prone. BIP39 was designed to solve this problem but rather than serialize the BIP32 root key, it takes some entropy, encoded to a "seed mnemonic", which is then hashed to derive the BIP39 seed which can be turned into the BIP32 root key. Saving the BIP39 mnemonic is enough to reconstruct the entire BIP32 keychain, but a BIP32 root key cannot be reversed back to the BIP39 mnemonic.
43+Most wallets implement BIP32 which defines how a BIP32 root key can be used to derive keychains. As a consequence, a backup of just the BIP32 root key is sufficient to include all keys derived from it. BIP32 does not have a human-friendly serialization of the BIP32 root key (or BIP32 extended keys in general), which makes paper backups or manually restoring the key more error-prone. BIP39 was designed to solve this problem, but rather than serialize the BIP32 root key, it takes some entropy, encoded to a "seed mnemonic", which is then hashed to derive the BIP39 seed, which can be turned into the BIP32 root key. Saving the BIP39 mnemonic is enough to reconstruct the entire BIP32 keychain, but a BIP32 root key cannot be reversed back to the BIP39 mnemonic.
44
45-Most wallets implement BIP39, so on initialization or restoration, the user must interact with a BIP39 mnemonic. Most wallets do not support BIP32 extended private keys, so each wallet must either share the same BIP39 mnemonic, or have a separate BIP39 mnemonic entirely. Neither scenarios are particularly satisfactory for security reasons. For example, some wallets may be inherently less secure like hot wallets on smartphones, Join Market servers, or Lightning Network nodes. Having multiple seeds is far from desirable, especially for those who rely on split key or redundancy backups in different geological locations. Adding is necessarily difficult and may result in users being more lazy with subsequent keys, resulting in compromised security or loss of keys.
46+Most wallets implement BIP39, so on initialization or restoration, the user must interact with a BIP39 mnemonic. Most wallets do not support BIP32 extended private keys, so each wallet must either share the same BIP39 mnemonic, or have a separate BIP39 mnemonic entirely. Neither scenario is particularly satisfactory for security reasons. For example, some wallets may be inherently less secure, like hot wallets on smartphones, Join Market servers, or Lightning Network nodes. Having multiple seeds is far from desirable, especially for those who rely on split key or redundancy backups in different geological locations. Adding keys is necessarily difficult and may result in users being more lazy with subsequent keys, resulting in compromised security or loss of keys.
0Most wallets implement BIP39, so on initialization or restoration, the user must interact with a BIP39 mnemonic. Most wallets do not support BIP32 extended private keys, so each wallet must either share the same BIP39 mnemonic, or have a separate BIP39 mnemonic entirely. Neither scenario is particularly satisfactory for security reasons. For example, some wallets may be inherently less secure, like hot wallets on smartphones, JoinMarket servers, or Lightning Network nodes. Having multiple seeds is far from desirable, especially for those who rely on split key or redundancy backups in different geological locations. Adding keys is necessarily difficult and may result in users being more lazy with subsequent keys, resulting in compromised security or loss of keys.
do committers squash and merge? if not should i rebase this? I was asked to preface all commits with BIP-85, and these commits are all orthogonal and semantic, but I personally would prefer a rebase because a lot of this is TMI for master, agree?
People have different preferences. I prefer when the PR author organizes the commits in a logical, hygienic manner; and otherwise, I might squash in the merge to one commit.
Co-authored-by: Jon Atack <jon@atack.com>
428@@ -370,16 +429,42 @@ The reason for running the derived key through HMAC-SHA512 and truncating the re
429
430 Many thanks to Peter Gray and Christopher Allen for their input, and to Peter for suggesting extra application use cases.
431
432+==Change Log==
241@@ -222,7 +242,11 @@ OUTPUT
242 ===XPRV===
243 Application number: 32'
244
245-Taking 64 bytes of the HMAC digest, the first 32 bytes are the chain code, and second 32 bytes[1] are the private key for BIP32 XPRV value. Child number, depth, and parent fingerprint are forced to zero.
246+Taking 64 bytes of the HMAC digest, the first 32 bytes are the chain code, and the second 32 bytes<ref name="curve-order" /> are the private key for the BIP32 XPRV value. Child number, depth, and parent fingerprint are forced to zero.
247+
248+{{Warning|The above is the inverse of BIP32, which takes the first 32 bytes as the private key, and the second 32 bytes as the chain code.}}
0{{Warning|The above is the reverse of BIP32, which takes the first 32 bytes as the private key, and the second 32 bytes as the chain code.}}
inverse != reverse
96@@ -93,14 +97,17 @@ OUTPUT
97
98 ==Reference Implementation==
99
100-* Python library implementation: [https://github.com/ethankosakovsky/bip85]
101-* JavaScript library implementation: [https://github.com/hoganri/bip85-js]
102+* 1.3.0 Python 3.x library implementation: [https://github.com/akarve/bipsea]
103+* 1.1.0 Python 2.x library implementation: [https://github.com/ethankosakovsky/bip85]
104+* 1.0.0 JavaScript library implementation: [https://github.com/hoganri/bip85-js]
Reference Implementation section to just above the Changelog (and move the Acknowledgements section further down toward the end).
Seems close, modulo a couple suggestions.
Pinging @scgbckbone @nvk @Rob1Ham @luisschwab for review/comments.
Reviewers: suggest looking at the whole change, not commit-by-commit.
Thanks for looking @scgbckbone.
ACK 0e5f2da68791662bee368eecf8fbc9b4939c5ac2
