mirror of
https://github.com/bitcoin/bips.git
synced 2025-01-18 21:35:13 +01:00
introduce BIP-0043 and BIP-0044
This commit is contained in:
parent
4a58190577
commit
39b441f2ff
@ -180,7 +180,18 @@ Those proposing changes should consider that ultimately consent may rest with th
|
|||||||
| Pieter Wuille
|
| Pieter Wuille
|
||||||
| Standard
|
| Standard
|
||||||
| Draft
|
| Draft
|
||||||
<!-- 43-49 reserved for stratum extensions -->
|
|-
|
||||||
|
| [[bip-0043.mediawiki|43]]
|
||||||
|
| Purpose Field for Deterministic Wallets
|
||||||
|
| Slush
|
||||||
|
| Standard
|
||||||
|
| Draft
|
||||||
|
|-
|
||||||
|
| [[bip-0044.mediawiki|44]]
|
||||||
|
| Multi-Account Hierarchy for Deterministic Wallets
|
||||||
|
| Slush
|
||||||
|
| Standard
|
||||||
|
| Draft
|
||||||
|-
|
|-
|
||||||
| [[bip-0050.mediawiki|50]]
|
| [[bip-0050.mediawiki|50]]
|
||||||
| March 2013 Chain Fork Post-Mortem
|
| March 2013 Chain Fork Post-Mortem
|
||||||
|
61
bip-0043.mediawiki
Normal file
61
bip-0043.mediawiki
Normal file
@ -0,0 +1,61 @@
|
|||||||
|
<pre>
|
||||||
|
BIP: BIP-0043
|
||||||
|
Title: Purpose Field for Deterministic Wallets
|
||||||
|
Authors: Marek Palatinus <slush@satoshilabs.com>
|
||||||
|
Pavol Rusnak <stick@satoshilabs.com>
|
||||||
|
Status: Draft
|
||||||
|
Type: Standards Track
|
||||||
|
Created: 24-04-2014
|
||||||
|
</pre>
|
||||||
|
|
||||||
|
==Abstract==
|
||||||
|
|
||||||
|
This BIP introduces a "Purpose Field" for use in deterministic wallets
|
||||||
|
based on algorithm described in BIP-0032 (BIP32 from now on).
|
||||||
|
|
||||||
|
==Motivation==
|
||||||
|
|
||||||
|
Although Hierarchical Deterministic Wallet structure as described by BIP32
|
||||||
|
is an important step in user experience and security of the cryptocoin wallets,
|
||||||
|
the BIP32 specification offers implementors too many degrees of freedom.
|
||||||
|
Multiple implementations may claim they are BIP32 compatible, but in fact
|
||||||
|
they can produce wallets with different logical structures making them
|
||||||
|
non-interoperable. This situation unfortunately renders "BIP32 compatible"
|
||||||
|
statement rather useless.
|
||||||
|
|
||||||
|
|
||||||
|
==Purpose==
|
||||||
|
|
||||||
|
We propose the first level of BIP32 tree structure to be used as "purpose".
|
||||||
|
This purpose determines the further structure beneath this node.
|
||||||
|
|
||||||
|
<pre>
|
||||||
|
m / purpose' / *
|
||||||
|
</pre>
|
||||||
|
|
||||||
|
Apostrophe indicates that BIP32 hardened derivation is used.
|
||||||
|
|
||||||
|
We encourage different schemes to apply for assigning a separate BIP number
|
||||||
|
and use the same number for purpose field, so addresses won't be generated
|
||||||
|
from overlapping BIP32 spaces.
|
||||||
|
|
||||||
|
Example: Scheme described in BIP44 should use 44' (or 0x8000002C) as purpose.
|
||||||
|
|
||||||
|
Not all wallets may want to support the full range of features and possibilities
|
||||||
|
described in these BIPs. Instead of choosing arbitrary subset of defined features
|
||||||
|
and calling themselves BIPxx compatible, we suggest that software which needs
|
||||||
|
only a limited structure should describe such structure in another BIP and use
|
||||||
|
different "purpose" value.
|
||||||
|
|
||||||
|
|
||||||
|
==Master node serialization==
|
||||||
|
|
||||||
|
Because this scheme can be used to generate nodes for more cryptocurrencies
|
||||||
|
at once, or even something totally unrelated to cryptocurrencies, there's no
|
||||||
|
point in using a special version magic described in section "Serialization
|
||||||
|
format" of BIP32. We suggest to use always 0x0488B21E for public and 0x0488ADE4
|
||||||
|
for private nodes (leading to prefixes "xpub" and "xprv" respectively).
|
||||||
|
|
||||||
|
==Reference==
|
||||||
|
|
||||||
|
* [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]]
|
261
bip-0044.mediawiki
Normal file
261
bip-0044.mediawiki
Normal file
@ -0,0 +1,261 @@
|
|||||||
|
<pre>
|
||||||
|
BIP: BIP-0044
|
||||||
|
Title: Multi-Account Hierarchy for Deterministic Wallets
|
||||||
|
Authors: Marek Palatinus <slush@satoshilabs.com>
|
||||||
|
Pavol Rusnak <stick@satoshilabs.com>
|
||||||
|
Status: Draft
|
||||||
|
Type: Standards Track
|
||||||
|
Created: 24-04-2014
|
||||||
|
</pre>
|
||||||
|
|
||||||
|
==Abstract==
|
||||||
|
|
||||||
|
This BIP defines logical hierarchy for deterministic wallets based on algorithm
|
||||||
|
described in 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==
|
||||||
|
|
||||||
|
Hierarchy proposed in this paper is quite comprehensive. It allows to handle
|
||||||
|
multiple coins, multiple accounts, external and internal chains per account and
|
||||||
|
millions of addresses per chain.
|
||||||
|
|
||||||
|
==Path levels==
|
||||||
|
|
||||||
|
We define the following 5 levels in BIP32 path:
|
||||||
|
|
||||||
|
<pre>
|
||||||
|
m / purpose' / coin_type' / account' / change / address_index
|
||||||
|
</pre>
|
||||||
|
|
||||||
|
Apostrophe in the path indicates that BIP32 hardened derivation is used.
|
||||||
|
|
||||||
|
Each level has special meaning described in the chapters below.
|
||||||
|
|
||||||
|
===Purpose===
|
||||||
|
|
||||||
|
Purpose is a constant set to 44' (or 0x8000002C) 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 unlimited number of independent
|
||||||
|
cryptocoins such as Bitcoin, Litecoin or Namecoin. However, sharing the same
|
||||||
|
space for various cryptocoins has some disadvantages.
|
||||||
|
|
||||||
|
This level creates a separate subtree for every cryptocoin, avoiding
|
||||||
|
reusing addresses across cryptocoins and improving privacy issues.
|
||||||
|
|
||||||
|
Coin type is a constant set for each cryptocoin. Cryptocoin developers may ask
|
||||||
|
for registering unused number for their project.
|
||||||
|
|
||||||
|
The list of already allocated coin types is in the chapter
|
||||||
|
"Registered coin types" below.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
User can use these accounts to organize the funds in the same
|
||||||
|
fashion like 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 previous account does not
|
||||||
|
have a transaction history (meaning no its address has been used before).
|
||||||
|
|
||||||
|
Software needs to discover all used accounts after importing the seed from
|
||||||
|
an external source. Such algorithm is described in "Account discovery" chapter.
|
||||||
|
|
||||||
|
===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 account's 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 correct, 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 account with total 0 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.
|
||||||
|
|
||||||
|
Wallet software should warn when user is trying to exceed the gap limit on
|
||||||
|
an external chain by generating a new address.
|
||||||
|
|
||||||
|
==Registered coin types==
|
||||||
|
|
||||||
|
These are the registered coin types for usage in level 2 of BIP44 described in
|
||||||
|
chapter "Coin type" above.
|
||||||
|
|
||||||
|
All these constants are used as hardened derivation.
|
||||||
|
|
||||||
|
{|
|
||||||
|
!index
|
||||||
|
!hexa
|
||||||
|
!coin
|
||||||
|
|-
|
||||||
|
|0
|
||||||
|
|0x80000000
|
||||||
|
|Bitcoin
|
||||||
|
|-
|
||||||
|
|1
|
||||||
|
|0x80000001
|
||||||
|
|Bitcoin Testnet
|
||||||
|
|}
|
||||||
|
|
||||||
|
==Examples==
|
||||||
|
|
||||||
|
{|
|
||||||
|
!coin
|
||||||
|
!account
|
||||||
|
!chain
|
||||||
|
!address
|
||||||
|
!path
|
||||||
|
|-
|
||||||
|
|Bitcoin
|
||||||
|
|first
|
||||||
|
|external
|
||||||
|
|first
|
||||||
|
|m / 44' / 0' / 0' / 0 / 0
|
||||||
|
|-
|
||||||
|
|Bitcoin
|
||||||
|
|first
|
||||||
|
|external
|
||||||
|
|second
|
||||||
|
|m / 44' / 0' / 0' / 0 / 1
|
||||||
|
|-
|
||||||
|
|Bitcoin
|
||||||
|
|first
|
||||||
|
|change
|
||||||
|
|first
|
||||||
|
|m / 44' / 0' / 0' / 1 / 0
|
||||||
|
|-
|
||||||
|
|Bitcoin
|
||||||
|
|first
|
||||||
|
|change
|
||||||
|
|second
|
||||||
|
|m / 44' / 0' / 0' / 1 / 1
|
||||||
|
|-
|
||||||
|
|Bitcoin
|
||||||
|
|second
|
||||||
|
|external
|
||||||
|
|first
|
||||||
|
|m / 44' / 0' / 1' / 0 / 0
|
||||||
|
|-
|
||||||
|
|Bitcoin
|
||||||
|
|second
|
||||||
|
|external
|
||||||
|
|second
|
||||||
|
|m / 44' / 0' / 1' / 0 / 1
|
||||||
|
|-
|
||||||
|
|Bitcoin
|
||||||
|
|second
|
||||||
|
|change
|
||||||
|
|first
|
||||||
|
|m / 44' / 0' / 1' / 1 / 0
|
||||||
|
|-
|
||||||
|
|Bitcoin
|
||||||
|
|second
|
||||||
|
|change
|
||||||
|
|second
|
||||||
|
|m / 44' / 0' / 1' / 1 / 1
|
||||||
|
|-
|
||||||
|
|Bitcoin Testnet
|
||||||
|
|first
|
||||||
|
|external
|
||||||
|
|first
|
||||||
|
|m / 44' / 1' / 0' / 0 / 0
|
||||||
|
|-
|
||||||
|
|Bitcoin Testnet
|
||||||
|
|first
|
||||||
|
|external
|
||||||
|
|second
|
||||||
|
|m / 44' / 1' / 0' / 0 / 1
|
||||||
|
|-
|
||||||
|
|Bitcoin Testnet
|
||||||
|
|first
|
||||||
|
|change
|
||||||
|
|first
|
||||||
|
|m / 44' / 1' / 0' / 1 / 0
|
||||||
|
|-
|
||||||
|
|Bitcoin Testnet
|
||||||
|
|first
|
||||||
|
|change
|
||||||
|
|second
|
||||||
|
|m / 44' / 1' / 0' / 1 / 1
|
||||||
|
|-
|
||||||
|
|Bitcoin Testnet
|
||||||
|
|second
|
||||||
|
|external
|
||||||
|
|first
|
||||||
|
|m / 44' / 1' / 1' / 0 / 0
|
||||||
|
|-
|
||||||
|
|Bitcoin Testnet
|
||||||
|
|second
|
||||||
|
|external
|
||||||
|
|second
|
||||||
|
|m / 44' / 1' / 1' / 0 / 1
|
||||||
|
|-
|
||||||
|
|Bitcoin Testnet
|
||||||
|
|second
|
||||||
|
|change
|
||||||
|
|first
|
||||||
|
|m / 44' / 1' / 1' / 1 / 0
|
||||||
|
|-
|
||||||
|
|Bitcoin Testnet
|
||||||
|
|second
|
||||||
|
|change
|
||||||
|
|second
|
||||||
|
|m / 44' / 1' / 1' / 1 / 1
|
||||||
|
|}
|
||||||
|
|
||||||
|
==Compatible walets==
|
||||||
|
|
||||||
|
* [[https://mytrezor.com|myTREZOR web wallet]] ([[https://github.com/trezor/webwallet|source]])
|
||||||
|
|
||||||
|
==Reference==
|
||||||
|
|
||||||
|
* [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]]
|
||||||
|
* [[bip-0043.mediawiki|BIP43 - Purpose Field for Deterministic Wallets]]
|
Loading…
Reference in New Issue
Block a user