From 274d9b9867b3aa06d78b2bd5a1c07af969140680 Mon Sep 17 00:00:00 2001 From: Aneesh Karve Date: Sun, 6 Oct 2024 17:05:26 -0700 Subject: [PATCH 01/16] BIP-85: Add language code, add dice app, warn on BIP-32 divergence, grammar clarity --- README.mediawiki | 2 +- bip-0085.mediawiki | 52 +++++++++++++++++++++++++++++++++++++++++++--- 2 files changed, 50 insertions(+), 4 deletions(-) diff --git a/README.mediawiki b/README.mediawiki index 170b05314c..d92cb78669 100644 --- a/README.mediawiki +++ b/README.mediawiki @@ -452,7 +452,7 @@ Those proposing changes should consider that ultimately consent may rest with th | [[bip-0085.mediawiki|85]] | Applications | Deterministic Entropy From BIP32 Keychains -| Ethan Kosakovsky +| Ethan Kosakovsky, Aneesh Karve | Informational | Draft |- style="background-color: #cfffcf" diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki index 633210c6c6..3a41b91b6e 100644 --- a/bip-0085.mediawiki +++ b/bip-0085.mediawiki @@ -3,6 +3,7 @@ Layer: Applications Title: Deterministic Entropy From BIP32 Keychains Author: Ethan Kosakovsky + Aneesh Karve Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0085 Status: Draft @@ -51,6 +52,9 @@ For each application that requires its own wallet, a unique private key is deriv The HMAC-SHA512 function is specified in [http://tools.ietf.org/html/rfc4231 RFC 4231]. +Application codes may be arbitrary but are preferably semantic in some way, such as a BIP number or +ASCII character code sequence. + ===Test vectors=== ====Test case 1==== @@ -78,7 +82,7 @@ BIP85-DRNG-SHAKE256 is a deterministic random number generator for cryptographic RSA key generation is an example of a function that requires orders of magnitude more than 64 bytes of random input. Further, it is not possible to precalculate the amount of random input required until the function has completed. drng_reader = BIP85DRNG.new(bip85_entropy) - rsa_key = RSA.generate_key(4096, drng_reader.read()) + rsa_key = RSA.generate_key(4096, drng_reader.read) ===Test Vectors=== INPUT: @@ -93,7 +97,8 @@ OUTPUT ==Reference Implementation== -* Python library implementation: [https://github.com/ethankosakovsky/bip85] +* Python 3.x library implementation: [https://github.com/akarve/bipsea] +* Python 2.x library implementation: [https://github.com/ethankosakovsky/bip85] * JavaScript library implementation: [https://github.com/hoganri/bip85-js] ==Applications== @@ -143,6 +148,10 @@ Language Table |- | Czech | 8' +|- +| Portuguese +| 9' +|- |} Words Table @@ -224,6 +233,10 @@ Application number: 32' 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. +WARNING: The above is inconsistent with BIP32 which uses the first 32 bytes for the private key. + +Applications may support Testnet by emitting TPRV keys if and only if the input root key is a Testnet key. + Path format is m/83696968'/32'/{index}' INPUT: @@ -257,7 +270,7 @@ The derivation path format is: m/83696968'/707764'/{pwd_len}'/{index}'m/83696968'/89101'/{sides}'/{rolls}'/{index}' + + 2 <= sides <= 2^32 - 1 + 1 <= rolls <= 2^32 - 1 + +Use this application to generate PIN numbers or any other numeric secret. +Roll values are zero-indexed, such that an N-sided die produces values in the range +[0, N-1], inclusive. Applications should separate printed rolls by a comma or similar. + +Create a BIP85 DRNG whose seed is the derived entropy. + +Calculate the following integers: + + bits_per_roll = ceil(log_2(sides)) + bytes_per_roll = ceil(bits_per_roll / 8) + +Read bytes_per_roll bytes from the DRNG. +Trim any bits in excess of bits_per_roll (retain the most +significant bits). The resulting integer represents a single roll or trial. +If the trial is greater than or equal to the number of sides, skip it and +move on to the next one. Repeat as needed until all rolls are complete. + +INPUT: +* MASTER BIP32 ROOT KEY: xprv9s21ZrQH143K2LBWUUQRFXhucrQqBpKdRRxNVq2zBqsx8HVqFk2uYo8kmbaLLHRdqtQpUm98uKfu3vca1LqdGhUtyoFnCNkfmXRyPXLjbKb +* PATH: m/83696968'/89101'/6'/10'/0' +OUTPUT +* DERIVED ENTROPY=5e41f8f5d5d9ac09a20b8a5797a3172b28c806aead00d27e36609e2dd116a59176a738804236586f668da8a51b90c708a4226d7f92259c69f64c51124b6f6cd2 +* DERIVED ROLLS=1,0,0,2,0,1,5,5,2,4 + ==Backwards Compatibility== This specification is not backwards compatible with any other existing specification. From 503d9360339061cfa7bc96492326dc12753df896 Mon Sep 17 00:00:00 2001 From: Aneesh Karve Date: Tue, 15 Oct 2024 11:10:19 -0700 Subject: [PATCH 02/16] BIP-85: Add definite article Co-authored-by: Jon Atack --- bip-0085.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki index 3a41b91b6e..7ede99b8fa 100644 --- a/bip-0085.mediawiki +++ b/bip-0085.mediawiki @@ -231,7 +231,7 @@ OUTPUT ===XPRV=== Application number: 32' -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. +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. WARNING: The above is inconsistent with BIP32 which uses the first 32 bytes for the private key. From c29be8958f543eba639a863f54ed3f4cf0e26377 Mon Sep 17 00:00:00 2001 From: Aneesh Karve Date: Tue, 15 Oct 2024 11:19:09 -0700 Subject: [PATCH 03/16] BIP-85: PR suggestions on grammar, clarity --- bip-0085.mediawiki | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki index 7ede99b8fa..d2e6e597da 100644 --- a/bip-0085.mediawiki +++ b/bip-0085.mediawiki @@ -233,7 +233,7 @@ Application number: 32' 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. -WARNING: The above is inconsistent with BIP32 which uses the first 32 bytes for the private key. +{{Warning|The above ordering reverses BIP32, wherein the private key is the first 32 bytes and the chain code is the last 32 bytes.}} Applications may support Testnet by emitting TPRV keys if and only if the input root key is a Testnet key. @@ -308,7 +308,7 @@ The derivation path format is: m/83696968'/707785'/{pwd_len}'/{index}' Date: Tue, 15 Oct 2024 11:24:34 -0700 Subject: [PATCH 04/16] BIP-85: Add change log --- bip-0085.mediawiki | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki index d2e6e597da..51fda80e93 100644 --- a/bip-0085.mediawiki +++ b/bip-0085.mediawiki @@ -416,6 +416,17 @@ The reason for running the derived key through HMAC-SHA512 and truncating the re Many thanks to Peter Gray and Christopher Allen for their input, and to Peter for suggesting extra application use cases. +==Change Log== + +===1.1.0=== + +====Added==== + +* Dice application +* Czech language code to application 39' +* TPRV guidance for application 32' +* Warning on application 32' key and chain code ordering + ==References== BIP32, BIP39 From 8afbdf5712cf1d7bf30d3e967793ba4f332bec78 Mon Sep 17 00:00:00 2001 From: Aneesh Karve Date: Sun, 20 Oct 2024 15:42:57 -0700 Subject: [PATCH 05/16] BIP-85: Proper , semver reference implementations, date on changelog, clarify warning language --- bip-0085.mediawiki | 37 +++++++++++++++++++++++-------------- 1 file changed, 23 insertions(+), 14 deletions(-) diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki index 51fda80e93..9ca1ed8d56 100644 --- a/bip-0085.mediawiki +++ b/bip-0085.mediawiki @@ -15,9 +15,9 @@ ==Abstract== -''"One Seed to rule them all,'' -''One Key to find them,'' -''One Path to bring them all,'' +''"One Seed to rule them all,''
+''One Key to find them,''
+''One Path to bring them all,''
''And in cryptography bind them."'' It is not possible to maintain one single (mnemonic) seed backup for all keychains used across various wallets because there are a variety of incompatible standards. Sharing of seeds across multiple wallets is not desirable for security reasons. Physical storage of multiple seeds is difficult depending on the security and redundancy required. @@ -34,6 +34,9 @@ The terminology related to keychains used in the wild varies widely, for example # '''BIP39 mnemonic''' is the mnemonic phrase that is calculated from the entropy used before hashing of the mnemonic in BIP39. # '''BIP39 seed''' is the result of hashing the BIP39 mnemonic seed. +When in doubt, assume '''big endian''' byte serialization, such that the leftmost +byte is the most significant. + ==Motivation== 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. @@ -97,9 +100,9 @@ OUTPUT ==Reference Implementation== -* Python 3.x library implementation: [https://github.com/akarve/bipsea] -* Python 2.x library implementation: [https://github.com/ethankosakovsky/bip85] -* JavaScript library implementation: [https://github.com/hoganri/bip85-js] +* 1.1 Python 3.x library implementation: [https://github.com/akarve/bipsea] +* 1.0 Python 2.x library implementation: [https://github.com/ethankosakovsky/bip85] +* 1.0 JavaScript library implementation: [https://github.com/hoganri/bip85-js] ==Applications== @@ -216,7 +219,16 @@ OUTPUT: ===HD-Seed WIF=== Application number: 2' -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. +Uses the most significant 32 bytes +There is a very small chance that you'll make an invalid +key that is zero or larger than the order of the curve. If this occurs, software +should hard fail (forcing users to iterate to the next index). From BIP32: +
+In case parse256(IL) 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 2127.) +
+ +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. Path format is m/83696968'/2'/{index}' @@ -231,9 +243,9 @@ OUTPUT ===XPRV=== Application number: 32' -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. +Taking 64 bytes of the HMAC digest, the first 32 bytes are the chain code, and the second 32 bytes are the private key for the BIP32 XPRV value. Child number, depth, and parent fingerprint are forced to zero. -{{Warning|The above ordering reverses BIP32, wherein the private key is the first 32 bytes and the chain code is the last 32 bytes.}} +{{Warning|BIP32 reverses the above by taking the first 32 bytes as the private key, and the second 32 bytes as the chain code.}} Applications may support Testnet by emitting TPRV keys if and only if the input root key is a Testnet key. @@ -418,7 +430,7 @@ Many thanks to Peter Gray and Christopher Allen for their input, and to Peter fo ==Change Log== -===1.1.0=== +===1.1.0 (2024-10-20)=== ====Added==== @@ -433,10 +445,7 @@ BIP32, BIP39 ==Footnotes== -[1] There is a very small chance that you'll make an invalid key that is zero or bigger than the order of the curve. If this occurs, software should hard fail (forcing users to iterate to the next index). - -From BIP32: -In case parse256(IL) 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 2127.) + ==Copyright== From 17a5279acdb78db3dd3282226a8d589be1c9302c Mon Sep 17 00:00:00 2001 From: Aneesh Karve Date: Mon, 21 Oct 2024 13:03:25 -0700 Subject: [PATCH 06/16] BIP-85: PR suggestion on range formatting Co-authored-by: Jon Atack --- bip-0085.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki index 9ca1ed8d56..eded213234 100644 --- a/bip-0085.mediawiki +++ b/bip-0085.mediawiki @@ -224,7 +224,7 @@ There is a very small chance that you'll make an invalid key that is zero or larger than the order of the curve. If this occurs, software should hard fail (forcing users to iterate to the next index). From BIP32:
-In case parse256(IL) 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 2127.) +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.)
of entropy as the secret exponent to derive a private key and encode as a compressed From f9b37362321ea9b50b8625ff3bbc0fa6e8e4e8ca Mon Sep 17 00:00:00 2001 From: Aneesh Karve Date: Mon, 21 Oct 2024 13:04:58 -0700 Subject: [PATCH 07/16] BIP-85: wordsmith BIP-32 warning Co-authored-by: Jon Atack --- bip-0085.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki index eded213234..d90234b393 100644 --- a/bip-0085.mediawiki +++ b/bip-0085.mediawiki @@ -245,7 +245,7 @@ Application number: 32' Taking 64 bytes of the HMAC digest, the first 32 bytes are the chain code, and the second 32 bytes are the private key for the BIP32 XPRV value. Child number, depth, and parent fingerprint are forced to zero. -{{Warning|BIP32 reverses the above by taking the first 32 bytes as the private key, and the second 32 bytes as the chain code.}} +{{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.}} Applications may support Testnet by emitting TPRV keys if and only if the input root key is a Testnet key. From 5206a352ce6b9ee03866c6ee8d10a9d194fc9090 Mon Sep 17 00:00:00 2001 From: Aneesh Karve Date: Mon, 21 Oct 2024 13:12:31 -0700 Subject: [PATCH 08/16] BIP-85: PR feedback on format, language, order of text --- bip-0085.mediawiki | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki index d90234b393..f48caf2eb2 100644 --- a/bip-0085.mediawiki +++ b/bip-0085.mediawiki @@ -34,7 +34,7 @@ The terminology related to keychains used in the wild varies widely, for example # '''BIP39 mnemonic''' is the mnemonic phrase that is calculated from the entropy used before hashing of the mnemonic in BIP39. # '''BIP39 seed''' is the result of hashing the BIP39 mnemonic seed. -When in doubt, assume '''big endian''' byte serialization, such that the leftmost +When in doubt, assume big endian byte serialization, such that the leftmost byte is the most significant. ==Motivation== @@ -55,9 +55,6 @@ For each application that requires its own wallet, a unique private key is deriv The HMAC-SHA512 function is specified in [http://tools.ietf.org/html/rfc4231 RFC 4231]. -Application codes may be arbitrary but are preferably semantic in some way, such as a BIP number or -ASCII character code sequence. - ===Test vectors=== ====Test case 1==== @@ -110,6 +107,8 @@ The Application number defines how entropy will be used post processing. Some ba Derivation path uses the format m/83696968'/{app_no}'/{index}' where ''{app_no}'' is the path for the application, and ''{index}'' is the index. +Application numbers should be semantic in some way, such as a BIP number or ASCII character code sequence. + ===BIP39=== Application number: 39' @@ -219,7 +218,7 @@ OUTPUT: ===HD-Seed WIF=== Application number: 2' -Uses the most significant 32 bytes +Uses the most significant 256 bits There is a very small chance that you'll make an invalid key that is zero or larger than the order of the curve. If this occurs, software should hard fail (forcing users to iterate to the next index). From BIP32: From a645d94f80865bcddd9925038ed1d12c2f0d5183 Mon Sep 17 00:00:00 2001 From: Aneesh Karve Date: Mon, 21 Oct 2024 13:25:33 -0700 Subject: [PATCH 09/16] BIP-85: PR grammar improvements --- bip-0085.mediawiki | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki index f48caf2eb2..11c197c125 100644 --- a/bip-0085.mediawiki +++ b/bip-0085.mediawiki @@ -39,11 +39,11 @@ byte is the most significant. ==Motivation== -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. +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. -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. +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. -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. +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. 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. @@ -51,9 +51,9 @@ Ultimately, all of the mnemonic/seed schemes start with some "initial entropy" t 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). -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: HMAC-SHA512(key="bip-entropy-from-k", msg=k). 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. +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: HMAC-SHA512(key="bip-entropy-from-k", msg=k). 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. -The HMAC-SHA512 function is specified in [http://tools.ietf.org/html/rfc4231 RFC 4231]. +The HMAC-SHA512 function is specified in [https://tools.ietf.org/html/rfc4231 RFC 4231]. ===Test vectors=== From 819f7b7ded569514633a5f6a2aceaa8f13d3a8b2 Mon Sep 17 00:00:00 2001 From: Aneesh Karve Date: Mon, 21 Oct 2024 17:06:59 -0700 Subject: [PATCH 10/16] BIP-85: Add dice app code to changelog --- bip-0085.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki index 11c197c125..19cb4fbeda 100644 --- a/bip-0085.mediawiki +++ b/bip-0085.mediawiki @@ -433,7 +433,7 @@ Many thanks to Peter Gray and Christopher Allen for their input, and to Peter fo ====Added==== -* Dice application +* Dice application 89101' * Czech language code to application 39' * TPRV guidance for application 32' * Warning on application 32' key and chain code ordering From 34b74779c0f52396b589816b75f7389df5377deb Mon Sep 17 00:00:00 2001 From: Aneesh Karve Date: Tue, 22 Oct 2024 15:34:20 -0700 Subject: [PATCH 11/16] BIP-85: Grammar and clarity from PR review Co-authored-by: Jon Atack --- bip-0085.mediawiki | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki index 19cb4fbeda..70f5f8f38f 100644 --- a/bip-0085.mediawiki +++ b/bip-0085.mediawiki @@ -41,7 +41,7 @@ byte is the most significant. 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. -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. +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, 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. 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. @@ -51,7 +51,7 @@ Ultimately, all of the mnemonic/seed schemes start with some "initial entropy" t 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). -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: HMAC-SHA512(key="bip-entropy-from-k", msg=k). 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. +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: HMAC-SHA512(key="bip-entropy-from-k", msg=k). 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. The HMAC-SHA512 function is specified in [https://tools.ietf.org/html/rfc4231 RFC 4231]. @@ -105,7 +105,7 @@ OUTPUT The Application number defines how entropy will be used post processing. Some basic examples follow: -Derivation path uses the format m/83696968'/{app_no}'/{index}' where ''{app_no}'' is the path for the application, and ''{index}'' is the index. +Derivation paths follow the format m/83696968'/{app_no}'/{index}', where ''{app_no}'' is the path for the application, and ''{index}'' is the index. Application numbers should be semantic in some way, such as a BIP number or ASCII character code sequence. @@ -227,7 +227,7 @@ In case parse256(IL) ≥ n or ki = 0, the resul 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. +WIF that will be used as the hdseed for Bitcoin Core wallets. Path format is m/83696968'/2'/{index}' From 3221abe13bd9ddd561f3e4ad84ada5b8816ae830 Mon Sep 17 00:00:00 2001 From: Aneesh Karve Date: Tue, 22 Oct 2024 15:48:53 -0700 Subject: [PATCH 12/16] BIP-85: Improve changelog and bump semvers accordingly; add alphanum password example to dice --- bip-0085.mediawiki | 23 +++++++++++++++++++++-- 1 file changed, 21 insertions(+), 2 deletions(-) diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki index 70f5f8f38f..477b68ae85 100644 --- a/bip-0085.mediawiki +++ b/bip-0085.mediawiki @@ -389,7 +389,9 @@ The derivation path format is: m/83696968'/89101'/{sides}'/{rolls}'/{index 2 <= sides <= 2^32 - 1 1 <= rolls <= 2^32 - 1 -Use this application to generate PIN numbers or any other numeric secret. +Use this application to generate PIN numbers, numeric secrets, and secrets over custom alphabets. +For example, applications could generate alphanumeric passwords from a 62-sided die (26 + 26 + 10). + Roll values are zero-indexed, such that an N-sided die produces values in the range [0, N-1], inclusive. Applications should separate printed rolls by a comma or similar. @@ -429,7 +431,24 @@ Many thanks to Peter Gray and Christopher Allen for their input, and to Peter fo ==Change Log== -===1.1.0 (2024-10-20)=== +===1.0.0 (2020-07-11)=== + +* Initial version + +===1.1.0 (2020-11-19)=== + +====Added==== + +* BIP85-DRNG-SHAKE256 +* RSA application 828365' + +===1.2.0 (2022-12-04)=== + +====Added==== + +* Base64 application 707764' + +===1.2.0 (2024-10-22)=== ====Added==== From f9df9a7efd84a81a1fbb6b623c940427f8fb6d36 Mon Sep 17 00:00:00 2001 From: Aneesh Karve Date: Tue, 22 Oct 2024 15:53:43 -0700 Subject: [PATCH 13/16] BIP-85: Rectify changelog dates and contents --- bip-0085.mediawiki | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki index 477b68ae85..27231c5720 100644 --- a/bip-0085.mediawiki +++ b/bip-0085.mediawiki @@ -431,7 +431,7 @@ Many thanks to Peter Gray and Christopher Allen for their input, and to Peter fo ==Change Log== -===1.0.0 (2020-07-11)=== +===1.0.0 (2020-06-11)=== * Initial version @@ -447,6 +447,7 @@ Many thanks to Peter Gray and Christopher Allen for their input, and to Peter fo ====Added==== * Base64 application 707764' +* Base85 application 707785' ===1.2.0 (2024-10-22)=== From f763695ad999300a2c436a4ee39ed495965ef4d7 Mon Sep 17 00:00:00 2001 From: Aneesh Karve Date: Tue, 22 Oct 2024 15:56:09 -0700 Subject: [PATCH 14/16] BIP-85: Correct 1.3.0 semver in changelog --- bip-0085.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki index 27231c5720..a894da3ada 100644 --- a/bip-0085.mediawiki +++ b/bip-0085.mediawiki @@ -449,7 +449,7 @@ Many thanks to Peter Gray and Christopher Allen for their input, and to Peter fo * Base64 application 707764' * Base85 application 707785' -===1.2.0 (2024-10-22)=== +===1.3.0 (2024-10-22)=== ====Added==== From 294db30b5c3fe8b7dee7c1080747198e253303ec Mon Sep 17 00:00:00 2001 From: Aneesh Karve Date: Tue, 22 Oct 2024 16:15:12 -0700 Subject: [PATCH 15/16] BIP-85: Remove fancy warning syntax b/c GH doesn't render it, wordsmith BIP32 warning --- bip-0085.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki index a894da3ada..e737a1f5bd 100644 --- a/bip-0085.mediawiki +++ b/bip-0085.mediawiki @@ -244,7 +244,7 @@ Application number: 32' Taking 64 bytes of the HMAC digest, the first 32 bytes are the chain code, and the second 32 bytes are the private key for the BIP32 XPRV value. Child number, depth, and parent fingerprint are forced to zero. -{{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.}} +''Warning'': The above order reverses the order of BIP32, which takes the first 32 bytes as the private key, and the second 32 bytes as the chain code. Applications may support Testnet by emitting TPRV keys if and only if the input root key is a Testnet key. From 0e5f2da68791662bee368eecf8fbc9b4939c5ac2 Mon Sep 17 00:00:00 2001 From: Aneesh Karve Date: Tue, 22 Oct 2024 23:58:57 -0700 Subject: [PATCH 16/16] BIP-85: Add and correct semvers in Reference Implementation section --- bip-0085.mediawiki | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki index e737a1f5bd..5877606ed6 100644 --- a/bip-0085.mediawiki +++ b/bip-0085.mediawiki @@ -97,9 +97,9 @@ OUTPUT ==Reference Implementation== -* 1.1 Python 3.x library implementation: [https://github.com/akarve/bipsea] -* 1.0 Python 2.x library implementation: [https://github.com/ethankosakovsky/bip85] -* 1.0 JavaScript library implementation: [https://github.com/hoganri/bip85-js] +* 1.3.0 Python 3.x library implementation: [https://github.com/akarve/bipsea] +* 1.1.0 Python 2.x library implementation: [https://github.com/ethankosakovsky/bip85] +* 1.0.0 JavaScript library implementation: [https://github.com/hoganri/bip85-js] ==Applications==