From 60015d779adab5d9dfce81d2d36436c52f63c90a Mon Sep 17 00:00:00 2001 From: Andreas Schildbach Date: Wed, 14 May 2014 13:43:26 +0200 Subject: [PATCH] Remove proposal for wallet structure from BIP32. It remained unused and it is not compatible to BIP43 and the BIPs based on it. If it turns out worthy to keep as a standard, I suggest reviving it under a new BIP number. As the removed part of the BIP was optional, this change of the standard does not change the compliance state of any BIP32 implementation. --- bip-0032.mediawiki | 44 +++++++++++--------------------------------- 1 file changed, 11 insertions(+), 33 deletions(-) diff --git a/bip-0032.mediawiki b/bip-0032.mediawiki index 0563d35e..b79aa8b6 100644 --- a/bip-0032.mediawiki +++ b/bip-0032.mediawiki @@ -1,4 +1,5 @@ RECENT CHANGES: +* (14 May 2014) Wallet structure proposal removed. * (16 Apr 2013) Added private derivation for i ≥ 0x80000000 (less risk of parent private key leakage) * (30 Apr 2013) Switched from multiplication by IL to addition of IL (faster, easier implementation) * (25 May 2013) Added test vectors @@ -147,42 +148,15 @@ In case IL is 0 or ≥n, the master key is invalid. ==Specification: Wallet structure== -The previous sections specified key trees and their nodes. The next step is imposing a wallet structure on this tree. The layout defined in this section is a default only, though clients are encouraged to mimick it for compatibility, even if not all features are supported. +The previous sections specified key trees and their nodes. The next step is imposing a wallet structure on this tree. Implementers are advised to follow +BIP43. -===The default wallet layout=== - -An HDW is organized as several 'accounts'. Accounts are numbered, the default account ("") being number 0. Clients are not required to support more than one account - if not, they only use the default account. - -Each account is composed of two keypair chains: an internal and an external one. The external keychain is used to generate new public addresses, while the internal keychain is used for all other operations (change addresses, generation addresses, ..., anything that doesn't need to be communicated). Clients that do not support separate keychains for these should use the external one for everything. -* m/iH/0/k corresponds to the k'th keypair of the external chain of account number i of the HDW derived from master m. -* m/iH/1/k corresponds to the k'th keypair of the internal chain of account number i of the HDW derived from master m. - -===Use cases=== - -====Full wallet sharing: m==== - -In cases where two systems need to access a single shared wallet, and both need to be able to perform spendings, one needs to share the master private extended key. Nodes can keep a pool of N look-ahead keys cached for external chains, to watch for incoming payments. The look-ahead for internal chains can be very small, as no gaps are to be expected here. An extra look-ahead could be active for the first unused account's chains - triggering the creation of a new account when used. Note that the name of the account will still need to be entered manually and cannot be synchronized via the block chain. - -====Audits: N(m/*)==== - -In case an auditor needs full access to the list of incoming and outgoing payments, one can share all account public extended keys. This will allow the auditor to see all transactions from and to the wallet, in all accounts, but not a single secret key. - -====Per-office balances: m/iH==== - -When a business has several independent offices, they can all use wallets derived from a single master. This will allow the headquarters to maintain a super-wallet that sees all incoming and outgoing transactions of all offices, and even permit moving money between the offices. - -====Recurrent business-to-business transactions: N(m/iH/0)==== - -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. - -====Unsecure money receiver: N(m/iH/0)==== - -When an unsecure webserver is used to run an e-commerce site, it needs to know public addresses that are used to receive payments. The webserver only needs to know the public extended key of the external chain of a single account. This means someone illegally obtaining access to the webserver can at most see all incoming payments, but will not (trivially) be able to distinguish outgoing transactions, nor see payments received by other webservers if there are several ones. +There used to be an proposed wallet layout in this specification. It was removed because it remained unused. Also, it was not compatible to BIP43 and the +BIPs based on it. ==Compatibility== -To comply with this standard, a client must at least be able to import an extended public or private key, to give access to its direct descendants as wallet keys. The wallet structure (master/account/chain/subchain) presented in the second part of the specification is advisory only, but is suggested as a minimal structure for easy compatibility - even when no separate accounts or distinction between internal and external chains is made. However, implementations may deviate from it for specific needs; more complex applications may call for a more complex tree structure. +To comply with this standard, a client must at least be able to import an extended public or private key, to give access to its direct descendants as wallet keys. ==Security== @@ -202,7 +176,7 @@ Private and public keys must be kept safe as usual. Leaking a private key means Somewhat more care must be taken regarding extended keys, as these correspond to an entire (sub)tree of keys. One weakness that may not be immediately obvious, is that knowledge of the extended public key + any non-hardened private key descending from it is equivalent to knowing the 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. ==Test Vectors== @@ -273,6 +247,10 @@ A PHP implemetation is available at https://github.com/Bit-Wasp/bitcoin-lib-php A C# implementation is available at https://github.com/NicolasDorier/NBitcoin (ExtKey, ExtPubKey) +==Reference== + +* [[bip-0043.mediawiki|BIP43 - Purpose Field for Deterministic Wallets]] + ==Acknowledgements== * Gregory Maxwell for the original idea of type-2 deterministic wallets, and many discussions about it.