BIP 0032 - Revision history

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/1b87fc5c263f4d31/bip-0032.mediawiki

2024-04-24T16:56:44Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/1b87fc5c263f4d31/bip-0032.mediawiki

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/43da5dec5eaf0d81/bip-0032.mediawiki

2022-08-04T11:56:09Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/43da5dec5eaf0d81/bip-0032.mediawiki

← Older revision		Revision as of 11:56, 4 August 2022
Line 157:		Line 157:
	In case parse<sub>256</sub>(I<sub>L</sub>) is 0 or parse<sub>256</sub>(I<sub>L</sub>) ≥ n, the master key is invalid.		In case parse<sub>256</sub>(I<sub>L</sub>) is 0 or parse<sub>256</sub>(I<sub>L</sub>) ≥ n, the master key is invalid.

	~~[[File:BIP32~~-derivation.png~~\|700px]]~~		<img src=bip-0032/derivation.png></img>


	==Specification: Wallet structure==		==Specification: Wallet structure==

Manu: Fixed derivation.png image

2022-06-17T16:23:31Z

Fixed derivation.png image

← Older revision		Revision as of 16:23, 17 June 2022
Line 157:		Line 157:
	In case parse<sub>256</sub>(I<sub>L</sub>) is 0 or parse<sub>256</sub>(I<sub>L</sub>) ≥ n, the master key is invalid.		In case parse<sub>256</sub>(I<sub>L</sub>) is 0 or parse<sub>256</sub>(I<sub>L</sub>) ≥ n, the master key is invalid.

	~~<img src=bip~~-~~0032/~~derivation.png~~></img>~~		[[File:BIP32-derivation.png\|700px]]


	==Specification: Wallet structure==		==Specification: Wallet structure==

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/a3a397c82384220f/bip-0032.mediawiki

2022-01-03T02:50:30Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/a3a397c82384220f/bip-0032.mediawiki

← Older revision		Revision as of 02:50, 3 January 2022
Line 205:		Line 205:
	* Given a child extended private key (k<sub>i</sub>,c<sub>i</sub>) and the integer i, an attacker cannot find the parent private key k<sub>par</sub> more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.		* Given a child extended private key (k<sub>i</sub>,c<sub>i</sub>) and the integer i, an attacker cannot find the parent private key k<sub>par</sub> more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.
	* Given any number (2 ≤ N ≤ 2<sup>32</sup>-1) of (index, extended private key) tuples (i<sub>j</sub>,(k<sub>i<sub>j</sub></sub>,c<sub>i<sub>j</sub></sub>)), with distinct i<sub>j</sub>'s, determining whether they are derived from a common parent extended private key (i.e., whether there exists a (k<sub>par</sub>,c<sub>par</sub>) such that for each j in (0..N-1) CKDpriv((k<sub>par</sub>,c<sub>par</sub>),i<sub>j</sub>)=(k<sub>i<sub>j</sub></sub>,c<sub>i<sub>j</sub></sub>)), cannot be done more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.		* Given any number (2 ≤ N ≤ 2<sup>32</sup>-1) of (index, extended private key) tuples (i<sub>j</sub>,(k<sub>i<sub>j</sub></sub>,c<sub>i<sub>j</sub></sub>)), with distinct i<sub>j</sub>'s, determining whether they are derived from a common parent extended private key (i.e., whether there exists a (k<sub>par</sub>,c<sub>par</sub>) such that for each j in (0..N-1) CKDpriv((k<sub>par</sub>,c<sub>par</sub>),i<sub>j</sub>)=(k<sub>i<sub>j</sub></sub>,c<sub>i<sub>j</sub></sub>)), cannot be done more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.
	Note however that the following properties ~~does~~ not exist:		Note however that the following properties do not exist:
	* Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a child public key (K<sub>i</sub>), it is hard to find i.		* Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a child public key (K<sub>i</sub>), it is hard to find i.
	* Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a non-hardened child private key (k<sub>i</sub>), it is hard to find k<sub>par</sub>.		* Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a non-hardened child private key (k<sub>i</sub>), it is hard to find k<sub>par</sub>.

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/4c6389f8431f6778/bip-0032.mediawiki

2021-12-26T13:41:53Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/4c6389f8431f6778/bip-0032.mediawiki

← Older revision		Revision as of 13:41, 26 December 2021
Line 155:		Line 155:
	* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.		* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.
	* Use parse<sub>256</sub>(I<sub>L</sub>) as master secret key, and I<sub>R</sub> as master chain code.		* Use parse<sub>256</sub>(I<sub>L</sub>) as master secret key, and I<sub>R</sub> as master chain code.
	In case I<sub>L</sub> is 0 or ≥n, the master key is invalid.		In case parse<sub>256</sub>(I<sub>L</sub>) is 0 or parse<sub>256</sub>(I<sub>L</sub>) ≥ n, the master key is invalid.

	<img src=bip-0032/derivation.png></img>		<img src=bip-0032/derivation.png></img>

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/edffe529056f6dfd/bip-0032.mediawiki

2021-12-15T15:38:00Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/edffe529056f6dfd/bip-0032.mediawiki

@@ Line 8: / Line 8: @@
 * (15 Jan 2014) Rename keys with index ≥ 0x80000000 to hardened keys, and add explicit conversion functions.
 * (24 Feb 2017) Added test vectors for hardened derivation with leading zeros
 <pre>
@@ Line 122: / Line 123: @@
 However, N(m/a<sub>H</sub>) cannot be rewritten as N(m)/a<sub>H</sub>, as the latter is not possible.
-Each leaf node in the tree corresponds to an actual key, while the internal nodes correspond to the collections of keys that descend from them. The chain codes of the leaf nodes are ignored, and only their embedded private or public key is relevant. Because of this construction, knowing an extended private key allows reconstruction of all descendant private keys and public keys, and knowing an extended public keys allows reconstruction of all descendant non-hardened public keys.
+Each leaf node in the tree corresponds to an actual key, while the internal nodes correspond to the collections of keys that descend from them. The chain codes of the leaf nodes are ignored, and only their embedded private or public key is relevant. Because of this construction, knowing an extended private key allows reconstruction of all descendant private keys and public keys, and knowing an extended public key allows reconstruction of all descendant non-hardened public keys.
 ===Key identifiers===
@@ Line 276: / Line 277: @@
 ** ext prv: xprv9uPDJpEQgRQfDcW7BkF7eTya6RPxXeJCqCJGHuCJ4GiRVLzkTXBAJMu2qaMWPrS7AANYqdq6vcBcBUdJCVVFceUvJFjaPdGZ2y9WACViL4L
 ==Acknowledgements==

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/9d44e594b0baa509/bip-0032.mediawiki

2020-08-21T16:50:32Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/9d44e594b0baa509/bip-0032.mediawiki

← Older revision		Revision as of 16:50, 21 August 2020
Line 276:		Line 276:
	** ext prv: xprv9uPDJpEQgRQfDcW7BkF7eTya6RPxXeJCqCJGHuCJ4GiRVLzkTXBAJMu2qaMWPrS7AANYqdq6vcBcBUdJCVVFceUvJFjaPdGZ2y9WACViL4L		** ext prv: xprv9uPDJpEQgRQfDcW7BkF7eTya6RPxXeJCqCJGHuCJ4GiRVLzkTXBAJMu2qaMWPrS7AANYqdq6vcBcBUdJCVVFceUvJFjaPdGZ2y9WACViL4L

	~~==Implementations==~~

	~~Two Python implementations exist:~~

	PyCoin (https://github.com/richardkiss/pycoin) is a suite of utilities for dealing with Bitcoin that includes BIP0032 wallet features. BIP32Utils (https://pypi.org/project/bip32utils/) is a library and command line interface specifically focused on BIP0032 wallets and scripting.

	2 Java implementations exist: https://github.com/bitsofproof/supernode/blob/1.1/api/src/main/java/com/bitsofproof/supernode/api/ExtendedKey.java and https://github.com/bushidowallet/bushido-java-core/tree/master/src/main/java/com/bushidowallet/core/bitcoin/bip32

	~~A C++ implementation is available at https://github.com/ciphrex/mSIGNA/blob/master/deps/CoinCore/src/hdkeys.h~~

	~~An Objective-C implementation is available at https://github.com/oleganza/CoreBitcoin/blob/master/CoreBitcoin/BTCKeychain.h~~

	~~A Ruby implementation is available at https://github.com/GemHQ/money-tree~~

	~~Two Go implementations exist:~~

	hdkeychain (https://github.com/conformal/btcutil/tree/master/hdkeychain) provides an API for bitcoin hierarchical deterministic extended keys (BIP0032). Go HD Wallet (https://github.com/WeMeetAgain/go-hdwallet).

	~~Two JavaScript implementations exist: available at https://github.com/sarchar/brainwallet.github.com/tree/bip32 and https://github.com/bitpay/bitcore~~

	~~A PHP implementation is available at https://github.com/Bit-Wasp/bitcoin-lib-php~~

	~~A C# implementation is available at https://github.com/MetacoSA/NBitcoin (ExtKey, ExtPubKey)~~

	~~A Haskell implementation is available at https://github.com/haskoin/haskoin together with a CLI interface at https://github.com/np/hx~~

	==Acknowledgements==		==Acknowledgements==

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/8677fd57864430be/bip-0032.mediawiki

2019-11-04T15:51:41Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/8677fd57864430be/bip-0032.mediawiki

← Older revision		Revision as of 15:51, 4 November 2019
Line 298:		Line 298:
	A PHP implementation is available at https://github.com/Bit-Wasp/bitcoin-lib-php		A PHP implementation is available at https://github.com/Bit-Wasp/bitcoin-lib-php

	A C# implementation is available at https://github.com/~~NicolasDorier~~/NBitcoin (ExtKey, ExtPubKey)		A C# implementation is available at https://github.com/MetacoSA/NBitcoin (ExtKey, ExtPubKey)

	A Haskell implementation is available at https://github.com/haskoin/haskoin together with a CLI interface at https://github.com/np/hx		A Haskell implementation is available at https://github.com/haskoin/haskoin together with a CLI interface at https://github.com/np/hx

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/b5723035e23896d0/bip-0032.mediawiki

2019-09-24T17:52:31Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/b5723035e23896d0/bip-0032.mediawiki

Show changes

JonathanCross: Updating

2017-05-14T17:39:08Z

Updating

← Older revision		Revision as of 17:39, 14 May 2017
Line 1:		Line 1:
	{{bip}}		{{bip}}


	RECENT CHANGES:		RECENT CHANGES:
	* [16 Apr 2013] Added private derivation for ~~<tt>~~i >= 0x80000000~~</tt>~~ (less risk of parent private key leakage)		* (24 Feb 2017) Added test vectors for hardened derivation with leading zeros
	* [30 Apr 2013] Switched from multiplication by ~~<tt>~~I<sub>L</sub~~></tt~~> to addition of ~~<tt>~~I<sub>L</sub~~></tt~~> (faster, easier implementation)		* (16 Apr 2013) Added private derivation for i ≥ 0x80000000 (less risk of parent private key leakage)
	* [25 May 2013] Added test vectors		* (30 Apr 2013) Switched from multiplication by I<sub>L</sub> to addition of I<sub>L</sub> (faster, easier implementation)
	* [15 Jan 2014] Rename keys with index ≥ ~~0x8000000~~ to hardened keys, and add explicit conversion functions.		* (25 May 2013) Added test vectors
			* (15 Jan 2014) Rename keys with index ≥ 0x80000000 to hardened keys, and add explicit conversion functions.

	<pre>		<pre>
	BIP: 32		BIP: 32
			Layer: Applications
	Title: Hierarchical Deterministic Wallets		Title: Hierarchical Deterministic Wallets
	Author: Pieter Wuille		Author: Pieter Wuille <pieter.wuille@gmail.com>
	Status: ~~Accepted~~		Comments-Summary: No comments yet.
			Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0032
			Status: Final
	Type: Informational		Type: Informational
	Created: 11-02-~~2012~~		Created: 2012-02-11
			License: BSD-2-Clause
	</pre>		</pre>

	{{BipMoved\|bip-0032.mediawiki}}		{{BipMoved\|bip-0032.mediawiki}}

← Older revision		Revision as of 16:56, 24 April 2024
Line 29:		Line 29:
	The specification is intended to set a standard for deterministic wallets that can be interchanged between different clients. Although the wallets described here have many features, not all are required by supporting clients.		The specification is intended to set a standard for deterministic wallets that can be interchanged between different clients. Although the wallets described here have many features, not all are required by supporting clients.

	The specification consists of two parts. In a first part, a system for deriving a tree of keypairs from a single seed is presented. The second part demonstrates how to build a wallet structure on top of such a tree.		The specification consists of two parts. In the first part, a system for deriving a tree of keypairs from a single seed is presented. The second part demonstrates how to build a wallet structure on top of such a tree.

	==Copyright==		==Copyright==
Line 41:		Line 41:
	Deterministic wallets do not require such frequent backups, and elliptic curve mathematics permit schemes where one can calculate the public keys without revealing the private keys. This permits for example a webshop business to let its webserver generate fresh addresses (public key hashes) for each order or for each customer, without giving the webserver access to the corresponding private keys (which are required for spending the received funds).		Deterministic wallets do not require such frequent backups, and elliptic curve mathematics permit schemes where one can calculate the public keys without revealing the private keys. This permits for example a webshop business to let its webserver generate fresh addresses (public key hashes) for each order or for each customer, without giving the webserver access to the corresponding private keys (which are required for spending the received funds).

	However, deterministic wallets typically consist of a single "chain" of keypairs. The fact that there is only one chain means that sharing a wallet happens on an all-or-nothing basis. However, in some cases one only wants some (public) keys to be shared and recoverable. In the example of a webshop, the webserver does not need access to all public keys of the merchant's wallet; only to those addresses which are used to receive ~~customer~~'s payments, and not for example the change addresses that are generated when the merchant spends money. Hierarchical deterministic wallets allow such selective sharing by supporting multiple keypair chains, derived from a single root.		However, deterministic wallets typically consist of a single "chain" of keypairs. The fact that there is only one chain means that sharing a wallet happens on an all-or-nothing basis. However, in some cases one only wants some (public) keys to be shared and recoverable. In the example of a webshop, the webserver does not need access to all public keys of the merchant's wallet; only to those addresses which are used to receive customers' payments, and not for example the change addresses that are generated when the merchant spends money. Hierarchical deterministic wallets allow such selective sharing by supporting multiple keypair chains, derived from a single root.

	==Specification: Key derivation==		==Specification: Key derivation==
Line 108:		Line 108:
	* N(CKDpriv((k<sub>par</sub>, c<sub>par</sub>), i)) (works always).		* N(CKDpriv((k<sub>par</sub>, c<sub>par</sub>), i)) (works always).
	* CKDpub(N(k<sub>par</sub>, c<sub>par</sub>), i) (works only for non-hardened child keys).		* CKDpub(N(k<sub>par</sub>, c<sub>par</sub>), i) (works only for non-hardened child keys).
	The fact that they are equivalent is what makes non-hardened keys useful (one can derive child public keys of a given parent key without knowing any private key), and also what distinguishes them from hardened keys. The reason for not always using non-hardened keys (which are more useful) is security; see further for more information.		The fact that they are equivalent is what makes non-hardened keys useful (one can derive child public keys of a given parent key without knowing any private key), and also what distinguishes them from hardened keys. The reason for not always using non-hardened keys (which are more useful) is security; see further below for more information.

	====Public parent key → private child key====		====Public parent key → private child key====
Line 188:		Line 188:

	In case two business partners often transfer money, one can use the extended public key for the external chain of a specific account (M/i h/0) as a sort of "super address", allowing frequent transactions that cannot (easily) be associated, but without needing to request a new address for each payment.		In case two business partners often transfer money, one can use the extended public key for the external chain of a specific account (M/i h/0) as a sort of "super address", allowing frequent transactions that cannot (easily) be associated, but without needing to request a new address for each payment.
	Such a mechanism could also be used by mining pool operators as variable payout address.		Such a mechanism could also be used by mining pool operators as a variable payout address.

	====Unsecure money receiver: N(m/i<sub>H</sub>/0)====		====Unsecure money receiver: N(m/i<sub>H</sub>/0)====
Line 216:		Line 216:

	One weakness that may not be immediately obvious, is that knowledge of a parent extended public key plus any non-hardened private key descending from it is equivalent to knowing the parent extended private key (and thus every private and public key descending from it). This means that extended public keys must be treated more carefully than regular public keys.		One weakness that may not be immediately obvious, is that knowledge of a parent extended public key plus any non-hardened private key descending from it is equivalent to knowing the parent extended private key (and thus every private and public key descending from it). This means that extended public keys must be treated more carefully than regular public keys.
	It is also the reason for the existence of hardened keys, and why they are used for the account level in the tree. This way, a leak of account-specific (or below) private ~~key~~ never risks compromising the master or other accounts.		It is also the reason for the existence of hardened keys, and why they are used for the account level in the tree. This way, a leak of account-specific (or below) private keys never risks compromising the master or other accounts.