diff options
author | Fonta1n3 <fontainedenton@googlemail.com> | 2020-12-16 19:22:20 +0800 |
---|---|---|
committer | Fonta1n3 <fontainedenton@googlemail.com> | 2020-12-16 19:22:20 +0800 |
commit | e6b9822142eb41771dbaaa4dfd39d99432e92d49 (patch) | |
tree | b212408e94b257e4aecb4716bfa105522dcf31d8 | |
parent | 7e13d23d4339e5704f3c12d88704ee7520d16149 (diff) |
Create bip-0048.mediawiki
-rw-r--r-- | bip-0048.mediawiki | 253 |
1 files changed, 253 insertions, 0 deletions
diff --git a/bip-0048.mediawiki b/bip-0048.mediawiki new file mode 100644 index 0000000..7c39823 --- /dev/null +++ b/bip-0048.mediawiki @@ -0,0 +1,253 @@ +<pre> + BIP: 48 + Layer: Applications + Title: Multi-Account/Multi-Script Hierarchy for Deterministic Multi Signature Wallets + Author: Peter Denton <dentondevelopment@protonmail.com> + Comments-Summary: Mixed review (one person) + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0048 + Status: Proposed + Type: Standards Track + Created: 2020-12-16 +</pre> + +==Abstract== + +This BIP defines a logical hierarchy for deterministic multi-sig wallets based on an algorithm +described in BIP-0067 (BIP67 from now on), BIP-0032 (BIP32 from now on) and purpose scheme described in +BIP-0043 (BIP43 from now on). + +This BIP is a particular application of BIP43. + +==Motivation== + +The hierarchy proposed in this paper is quite comprehensive. It allows the handling of +multiple accounts, external and internal chains per account, multiple script types and +millions of addresses per chain. + +==Key sorting== + +Any wallet that supports BIP48 inherently supports deterministic key sorting as per BIP67 so that all possible +multi-signature addresses/scripts are derived from deterministically ordered public keys. + +==Path levels== + +We define the following 6 levels in BIP32 path: + +<pre> +m / purpose' / coin_type' / account' / script_type' / change / address_index +</pre> + +`h` in the path indicates that BIP32 hardened derivation is used. + +Each level has a special meaning, described in the chapters below. + +===Purpose=== + +Purpose is a constant set to 48' following the BIP43 recommendation. +It indicates that the subtree of this node is used according to this specification. + +Hardened derivation is used at this level. + +===Coin type=== + +One master node (seed) can be used for either multiple Bitcoin networks. +Sharing the same space for various networks has some disadvantages. + +Avoiding reusing addresses across networks and improving privacy issues. + +Coin type `0` for mainnet and `1` for testnet. + +Hardened derivation is used at this level. + +===Account=== + +This level splits the key space into independent user identities, +so the wallet never mixes the coins across different accounts. + +Users can use these accounts to organize the funds in the same +fashion as bank accounts; for donation purposes (where all +addresses are considered public), for saving purposes, +for common expenses etc. + +Accounts are numbered from index 0 in sequentially increasing manner. +This number is used as child index in BIP32 derivation. + +Hardened derivation is used at this level. + +Software should prevent a creation of an account if a previous account does not +have a transaction history (meaning none of its addresses have been used before). + +Software needs to discover all used accounts after importing the seed from +an external source. Such an algorithm is described in "Account discovery" chapter. + +===Script=== + +This level splits the key space into three separate `script_type`(s). To provide +optimum backward compatibility. + +The recommended default is pay to witness script hash `m/48'/0'/0'/2'`. + +The following represent mainnet, account 0. + +`1'`: Nested Segwit (p2sh-p2wsh) `m/48'/0'/0'/1'`</br> +`2'`: Native Segwit (p2wsh) `m/48'/0'/0'/2'`</br> +`3'`: Legacy (p2sh) `m/48'/0'/0'/3'`</br> + +===Change=== + +Constant 0 is used for external chain and constant 1 for internal chain (also +known as change addresses). External chain is used for addresses that are meant +to be visible outside of the wallet (e.g. for receiving payments). Internal +chain is used for addresses which are not meant to be visible outside of the +wallet and is used for return transaction change. + +Public derivation is used at this level. + +===Index=== + +Addresses are numbered from index 0 in sequentially increasing manner. +This number is used as child index in BIP32 derivation. + +Public derivation is used at this level. + +==Account discovery== + +When the master seed is imported from an external source the software should +start to discover the accounts in the following manner: + +* derive the first accounts node (index = 0) +* derive the external chain node of this account +* scan addresses of the external chain; respect the gap limit described below +* if no transactions are found on the external chain, stop discovery +* if there are some transactions, increase the account index and go to step 1 + +This algorithm is successful because software should disallow creation of new +accounts if previous one has no transaction history, as described in chapter +"Account" above. + +Please note that the algorithm works with the transaction history, not account +balances, so you can have an account with 0 total coins and the algorithm will +still continue with discovery. + +===Address gap limit=== + +Address gap limit is currently set to 20. If the software hits 20 unused +addresses in a row, it expects there are no used addresses beyond this point +and stops searching the address chain. We scan just the external chains, because +internal chains receive only coins that come from the associated external chains. + +Wallet software should warn when the user is trying to exceed the gap limit on +an external chain by generating a new address. + +==Examples== + +{| +!coin +!account +!script +!chain +!address +!path +|- +|Bitcoin +|first +|external +|first +|m / 48' / 0' / 0' / 2' / 0 / 0 +|- +|Bitcoin +|first +|external +|second +|m / 48' / 0' / 0' / 2' / 0 / 1 +|- +|Bitcoin +|first +|change +|first +|m / 48' / 0' / 0' / 2' / 1 / 0 +|- +|Bitcoin +|first +|change +|second +|m / 48' / 0' / 0' / 2' / 1 / 1 +|- +|Bitcoin +|second +|external +|first +|m / 48' / 0' / 1' / 2' / 0 / 0 +|- +|Bitcoin +|second +|external +|second +|m / 48' / 0' / 1' / 2' / 0 / 1 +|- +|Bitcoin +|second +|change +|first +|m / 48' / 0' / 1' / 2' / 1 / 0 +|- +|Bitcoin +|second +|change +|second +|m / 48' / 1' / 1' / 2' / 1 / 1 +|- +|Bitcoin Testnet +|first +|external +|first +|m / 48' / 1' / 0' / 2' / 0 / 0 +|- +|Bitcoin Testnet +|first +|external +|second +|m / 48' / 1' / 0' / 2' / 0 / 1 +|- +|Bitcoin Testnet +|first +|change +|first +|m / 48' / 1' / 0' / 2' / 1 / 0 +|- +|Bitcoin Testnet +|first +|change +|second +|m / 48' / 1' / 0' / 2' / 1 / 1 +|- +|Bitcoin Testnet +|second +|external +|first +|m / 48' / 1' / 1' / 2' / 0 / 0 +|- +|Bitcoin Testnet +|second +|external +|second +|m / 48' / 1' / 1' / 2' / 0 / 1 +|- +|Bitcoin Testnet +|second +|change +|first +|m / 48' / 1' / 1' / 2' / 1 / 0 +|- +|Bitcoin Testnet +|second +|change +|second +|m / 48 h / 1' / 1' / 2' / 1 / 1 +|} + +==Reference== + +* [[bip-0067.mediawiki|BIP67 - Deterministic Pay-to-script-hash multi-signature addresses through public key sorting]] +* [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]] +* [[bip-0043.mediawiki|BIP43 - Purpose Field for Deterministic Wallets]] |