summaryrefslogtreecommitdiff
path: root/bip-0085.mediawiki
diff options
context:
space:
mode:
authoravirgovi <avirgovi@cisco.com>2020-06-25 13:42:03 +0200
committeravirgovi <avirgovi@cisco.com>2020-06-25 13:42:03 +0200
commitf6b935f308890f0007dc7b2789e5663456389aa4 (patch)
tree3729ca69eeda1bc5fc6804f81362ded0db6fc12f /bip-0085.mediawiki
parenta5beb39040cce5749307656d768c4f9bb05bd295 (diff)
downloadbips-f6b935f308890f0007dc7b2789e5663456389aa4.tar.xz
moved duplicate segments to footnotes
Diffstat (limited to 'bip-0085.mediawiki')
-rw-r--r--bip-0085.mediawiki21
1 files changed, 9 insertions, 12 deletions
diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki
index 1092e64..99d4291 100644
--- a/bip-0085.mediawiki
+++ b/bip-0085.mediawiki
@@ -188,12 +188,7 @@ OUTPUT:
===HD-Seed WIF===
Application number: 2'
-Uses 256 bits 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.
-
-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 should iterate to the next index).
-
-From BIP32:
-> 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>.)
+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.
Path format is <code>m/83696968'/2'/{index}'</code>
@@ -208,12 +203,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 are the private key for BIP32 XPRV value. Child number, depth, and parent fingerprint are forced to zero.
-
-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 should iterate to the next index).
-
-From BIP32:
-> In case parse<sub>256</sub>(I<sub>R</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>.)
+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.
Path format is <code>m/83696968'/32'/{index}'</code>
@@ -259,6 +249,13 @@ Many thanks to Peter Gray and Christopher Allen for their input, and to Peter fo
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 should iterate to the next index).
+
+From BIP32:
+> 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>.)
+
==Copyright==
This BIP is dual-licensed under the Open Publication License and BSD 2-clause license.