BIP-85: Add language code & dice app, TPRV guidance, warn on BIP-32 divergence, grammar & clarity #1679

pull akarve wants to merge 16 commits into bitcoin:master from akarve:bip85-fixes changing 2 files +106 −21
  1. akarve commented at 0:09 am on October 7, 2024: contributor

    Reloading this PR with minimal, backward-compatible changes.

    • I believe there is consensus on the need to add a new champion here.
    • The reason for adding a new reference implementation is to support Python 3.x with a thoroughly unit-tested implementation. I was unable to get the original Python 2.x reference implementation to run.
    • If desired I can email bitcoin dev for more thoughts on these changes
  2. akarve commented at 0:17 am on October 7, 2024: contributor
    @jonatack @scgbckbone Please have look.
  3. in bip-0085.mediawiki:264 in 68644f21dc outdated
    260@@ -248,7 +261,7 @@ INPUT:
    261 * PATH: m/83696968'/128169'/64'/0'
    262 
    263 OUTPUT
    264-* DERIVED ENTROPY=492db4698cf3b73a5a24998aa3e9d7fa96275d85724a91e71aa2d645442f878555d078fd1f1f67e368976f04137b1f7a0d19232136ca50c44614af72b5582a5c
    265+* DERIVED ENTROPY=74a2e87a9ba0cdd549bdd2f9ea880d554c6c355b08ed25088cfa88f3f1c4f74632b652fd4a8f5fda43074c6f6964a3753b08bb5210c8f5e75c07a4c2a20bf6e9
    


    scgbckbone commented at 1:37 am on October 7, 2024:

    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)


    akarve commented at 2:31 am on October 7, 2024:

    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
    
  4. scgbckbone changes_requested
  5. scgbckbone commented at 1:39 am on October 7, 2024: contributor

    wrong entropy is in base64 pwd application, currently: d7ad61d4a76575c5bad773feeb40299490b224e8e5df6c8ad8fe3d0a6eed7b85ead9fef7bcca8160f0ee48dc6e92b311fc71f2146623cc6952c03ce82c7b63fe

    correct: 74a2e87a9ba0cdd549bdd2f9ea880d554c6c355b08ed25088cfa88f3f1c4f74632b652fd4a8f5fda43074c6f6964a3753b08bb5210c8f5e75c07a4c2a20bf6e9

  6. akarve requested review from scgbckbone on Oct 7, 2024
  7. scgbckbone commented at 5:54 pm on October 7, 2024: contributor
    could you possibly split this into “b64 entropy fix only PR” and “the rest” ?
  8. akarve commented at 7:23 pm on October 7, 2024: contributor

    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.

  9. in bip-0085.mediawiki:100 in 3406d43a84 outdated
     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]
    


    jonatack commented at 7:45 pm on October 7, 2024:
    I may be confused here: did you update this implementation to be fully compatible with the current BIP for the xprv format?

    akarve commented at 9:34 pm on October 7, 2024:
    It will be, as in I will revert the 3.x implementation to use the spec-compliant key/chain code ordering. https://github.com/akarve/bipsea/pull/66

    jonatack commented at 5:12 pm on October 15, 2024:
    Looks like this change should be gated on https://github.com/akarve/bipsea/pull/66?

    akarve commented at 6:11 pm on October 15, 2024:
    Merged and release to PyPI.
  10. jonatack commented at 7:57 pm on October 7, 2024: member

    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

  11. scgbckbone commented at 1:54 pm on October 8, 2024: contributor

    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…

  12. jonatack added the label PR Author action required on Oct 9, 2024
  13. BIP-85: Add language code, add dice app, warn on BIP-32 divergence, grammar clarity 274d9b9867
  14. akarve force-pushed on Oct 13, 2024
  15. akarve renamed this:
    BIP-85: Correct test vector, add language code, add dice app
    BIP-85: Add language code, add dice app, warn on BIP-32 divergence, grammar clarity
    on Oct 13, 2024
  16. akarve requested review from jonatack on Oct 13, 2024
  17. akarve commented at 0:03 am on October 14, 2024: contributor

    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

  18. akarve commented at 0:05 am on October 14, 2024: contributor

    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.

  19. akarve renamed this:
    BIP-85: Add language code, add dice app, warn on BIP-32 divergence, grammar clarity
    BIP-85: Add language code, add dice app, warn on BIP-32 divergence, grammar & clarity
    on Oct 14, 2024
  20. jonatack commented at 5:14 pm on October 15, 2024: member
    Might be good to add a changelog in this pull, as previously in #1600.
  21. in bip-0085.mediawiki:273 in 274d9b9867 outdated
    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.
    


    jonatack commented at 5:16 pm on October 15, 2024:
    Also here? “Base85 encode the all 64 bytes of entropy.”
  22. in bip-0085.mediawiki:236 in 274d9b9867 outdated
    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.
    


    jonatack commented at 5:42 pm on October 15, 2024:

    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.
    
  23. BIP-85: Add definite article
    Co-authored-by: Jon Atack <jon@atack.com>
    503d936033
  24. BIP-85: PR suggestions on grammar, clarity c29be8958f
  25. BIP-85: Add change log c5a74ffd5e
  26. in bip-0085.mediawiki:234 in 274d9b9867 outdated
    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.
    


    jonatack commented at 5:42 pm on October 15, 2024:
    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.
    
  27. akarve requested review from jonatack on Oct 15, 2024
  28. akarve renamed this:
    BIP-85: Add language code, add dice app, warn on BIP-32 divergence, grammar & clarity
    BIP-85: Add language code & dice app, TPRV guidance, warn on BIP-32 divergence, grammar & clarity
    on Oct 15, 2024
  29. jodyyates approved
  30. in bip-0085.mediawiki:236 in c5a74ffd5e outdated
    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.}}
    


    jonatack commented at 2:56 pm on October 17, 2024:
    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.}}
    
    • Would be clearer to use the same sentence construction as the spec one line above
    • “BIP32” could optionally link to BIP32
    • (Why add the {{Warning|text}} in the latest push? I’m unsure how this renders and am probably missing something)

    akarve commented at 10:33 pm on October 20, 2024:

    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.

  31. in bip-0085.mediawiki:234 in c5a74ffd5e outdated
    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.
    


    jonatack commented at 3:01 pm on October 17, 2024:
    Could optionally fix the footnote link 32 bytes[1] here as well while touching this line.
  32. in bip-0085.mediawiki:421 in c5a74ffd5e outdated
    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===
    


    jonatack commented at 3:08 pm on October 17, 2024:

    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.


    akarve commented at 10:32 pm on October 20, 2024:
    What I’d like to do for now is date 1.1.0 and leave the rest to backfill.
  33. jonatack commented at 3:17 pm on October 17, 2024: member
    Ok, I see that https://github.com/akarve/bipsea has been updated.
  34. akarve requested review from jonatack on Oct 20, 2024
  35. BIP-85: Proper <references />, semver reference implementations, date on changelog, clarify warning language 8afbdf5712
  36. akarve force-pushed on Oct 20, 2024
  37. akarve commented at 11:05 pm on October 20, 2024: contributor
    In retrospect this basically nets out to a revert of the backwards incompatible part of #1600, reverted in #1674. These lines.
  38. in bip-0085.mediawiki:227 in 8afbdf5712 outdated
    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>.)
    


    jonatack commented at 4:54 pm on October 21, 2024:

    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>.)
    
  39. in bip-0085.mediawiki:105 in 8afbdf5712 outdated
     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]
    


    jonatack commented at 5:09 pm on October 21, 2024:
    Why the version prefixes, aren’t all of the implementations now equally compatible here?

    akarve commented at 8:02 pm on October 21, 2024:
    Well all are backwards compatible but for instance you don’t have dice (or Czech for 39’ but I didn’t check) on any of the 1.0 implementations.

    jonatack commented at 9:30 pm on October 22, 2024:
    I’m not sure if it’s clear enough or matters enough to be worth adding. The changelog has one semver of 1.1.0, while here 1.1 and 1.0 are used. Unsure if readers will make connection, or register that 1.1 signifies the additional dice feature.
  40. in bip-0085.mediawiki:210 in 8afbdf5712 outdated
    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.
    


    jonatack commented at 5:59 pm on October 21, 2024:
    Why remove this sentence (isn’t it still correct)?

    akarve commented at 8:10 pm on October 21, 2024:

    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.

  41. in bip-0085.mediawiki:37 in 8afbdf5712 outdated
    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
    


    jonatack commented at 6:09 pm on October 21, 2024:
    nit, can probably drop the bold formatting here
  42. in bip-0085.mediawiki:59 in 8afbdf5712 outdated
    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.
    


    jonatack commented at 6:27 pm on October 21, 2024:
    Is this needed, and if so, is it added too early? “Application codes” hasn’t been defined or referenced yet in the document.

    akarve commented at 8:06 pm on October 21, 2024:
    It’s needed (common question from readers, “where did xyz app code come from?”). I will move it down to the Application section.
  43. in bip-0085.mediawiki:248 in 8afbdf5712 outdated
    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.}}
    


    jonatack commented at 6:28 pm on October 21, 2024:
    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.}}
    
  44. jonatack commented at 6:31 pm on October 21, 2024: member

    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].
    
  45. BIP-85: PR suggestion on range formatting
    Co-authored-by: Jon Atack <jon@atack.com>
    17a5279acd
  46. BIP-85: wordsmith BIP-32 warning
    Co-authored-by: Jon Atack <jon@atack.com>
    f9b3736232
  47. BIP-85: PR feedback on format, language, order of text 5206a352ce
  48. akarve requested review from jonatack on Oct 21, 2024
  49. akarve commented at 8:16 pm on October 21, 2024: contributor
    @jonatack thanks for the careful reviews. i think we’re g2g. 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?
  50. BIP-85: PR grammar improvements a645d94f80
  51. in bip-0085.mediawiki:392 in 5206a352ce outdated
    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.
    


    akarve commented at 8:18 pm on October 21, 2024:
    I wonder if it’s worth adding a note on the fact that users could use a 36-sided die to generate, say, an alphanumeric password as Base64 and Base85 have more characters than are supported by conservative systems like legacy databases?

    jonatack commented at 9:33 pm on October 22, 2024:
    Happy to review if you attempt it.

    akarve commented at 10:54 pm on October 22, 2024:
    Added.
  52. BIP-85: Add dice app code to changelog 819f7b7ded
  53. in bip-0085.mediawiki:436 in a645d94f80 outdated
    431+
    432+===1.1.0 (2024-10-20)===
    433+
    434+====Added====
    435+
    436+* Dice application
    


    akarve commented at 8:52 pm on October 21, 2024:
    0* Dice application 89101'
    
  54. in bip-0085.mediawiki:54 in 819f7b7ded outdated
    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.
    


    jonatack commented at 9:19 pm on October 22, 2024:
    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.
    
  55. in bip-0085.mediawiki:230 in 819f7b7ded outdated
    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.
    


    jonatack commented at 9:21 pm on October 22, 2024:
    0WIF that will be used as the hdseed for Bitcoin Core wallets.
    

    (should be either “, which” or “that”

  56. in bip-0085.mediawiki:108 in 819f7b7ded outdated
    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.
    


    jonatack commented at 9:31 pm on October 22, 2024:
    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.
    
  57. in bip-0085.mediawiki:44 in 819f7b7ded outdated
    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.
    


    jonatack commented at 9:33 pm on October 22, 2024:
    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.
    
  58. jonatack commented at 9:37 pm on October 22, 2024: member

    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.

  59. BIP-85: Grammar and clarity from PR review
    Co-authored-by: Jon Atack <jon@atack.com>
    34b74779c0
  60. BIP-85: Improve changelog and bump semvers accordingly; add alphanum password example to dice 3221abe13b
  61. BIP-85: Rectify changelog dates and contents f9df9a7efd
  62. BIP-85: Correct 1.3.0 semver in changelog f763695ad9
  63. in bip-0085.mediawiki:432 in f763695ad9 outdated
    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==
    


    akarve commented at 10:58 pm on October 22, 2024:
    @jonatack i’ve added a real changelog so that the semvers are more… semantic. i could go deeper in terms of detail (fixes, etc.) but this seems complete enough to be useful and importantly puts this commit at semver 1.3.0.

    jonatack commented at 9:41 pm on October 24, 2024:
    Suggest “Changelog” (no space), with entries ordered by most recent first (see https://keepachangelog.com/en/1.1.0/).
  64. akarve requested review from jonatack on Oct 22, 2024
  65. BIP-85: Remove fancy warning syntax b/c GH doesn't render it, wordsmith BIP32 warning 294db30b5c
  66. BIP-85: Add and correct semvers in Reference Implementation section 0e5f2da687
  67. in bip-0085.mediawiki:247 in f763695ad9 outdated
    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.}}
    


    akarve commented at 11:06 pm on October 22, 2024:
    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

  68. in bip-0085.mediawiki:102 in 0e5f2da687
     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]
    


    jonatack commented at 9:35 pm on October 24, 2024:
    Perhaps it would be easier for readers to reference these versions by moving this Reference Implementation section to just above the Changelog (and move the Acknowledgements section further down toward the end).
  69. jonatack commented at 9:45 pm on October 24, 2024: member

    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.

  70. jonatack removed the label PR Author action required on Oct 25, 2024
  71. jonatack added the label Proposed BIP modification on Oct 25, 2024
  72. scgbckbone approved
  73. scgbckbone commented at 1:12 pm on October 25, 2024: contributor
    ACK (but expect #1676 to follow)
  74. jonatack commented at 3:08 pm on October 25, 2024: member

    Thanks for looking @scgbckbone.

    ACK 0e5f2da68791662bee368eecf8fbc9b4939c5ac2

  75. jonatack merged this on Oct 25, 2024
  76. jonatack closed this on Oct 25, 2024

  77. akarve deleted the branch on Oct 25, 2024
  78. Mahdiporroshan commented at 2:42 am on November 9, 2024: none
    M
  79. Mahdiporroshan commented at 2:48 am on November 9, 2024: none
    [``]
  80. bitcoin deleted a comment on Nov 9, 2024
  81. bitcoin deleted a comment on Nov 9, 2024
  82. bitcoin deleted a comment on Nov 9, 2024
  83. bitcoin deleted a comment on Nov 9, 2024
  84. jodyyates approved

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bips. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-12-03 20:10 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me