mirror of
https://github.com/bitcoin/bips.git
synced 2024-11-19 01:40:05 +01:00
Create bip-0048.mediawiki
This commit is contained in:
Fonta1n3
parent
7e13d23d43
commit
e6b9822142
253
bip-0048.mediawiki
Normal file
253
bip-0048.mediawiki
Normal file
@ -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]]
|
||||||
Loading…
Reference in New Issue
Block a user