summaryrefslogtreecommitdiff
path: root/bip-0048.mediawiki
diff options
context:
space:
mode:
authorFonta1n3 <fontainedenton@googlemail.com>2020-12-16 19:22:20 +0800
committerFonta1n3 <fontainedenton@googlemail.com>2020-12-16 19:22:20 +0800
commite6b9822142eb41771dbaaa4dfd39d99432e92d49 (patch)
treeb212408e94b257e4aecb4716bfa105522dcf31d8 /bip-0048.mediawiki
parent7e13d23d4339e5704f3c12d88704ee7520d16149 (diff)
downloadbips-e6b9822142eb41771dbaaa4dfd39d99432e92d49.tar.xz
Create bip-0048.mediawiki
Diffstat (limited to 'bip-0048.mediawiki')
-rw-r--r--bip-0048.mediawiki253
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]]