You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki
+8-15Lines changed: 8 additions & 15 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -23,7 +23,7 @@ This BIP is licensed under the 2-clause BSD license.
23
23
24
24
==Motivation==
25
25
26
-
With the increase of more user friendly (offline) multisignature wallets, and adoption of new technologies such as [https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md the descriptor language] and [https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki BIP-0174 (Partially Signed Bitcoin Transactions)] it is necessary to create a common derivation scheme that makes use of all new technologies.
26
+
With the increase of more user friendly (offline) multisignature wallets, and adoption of new technologies such as [https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md the descriptor language] and [https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki BIP-0174 (Partially Signed Bitcoin Transactions)], it is necessary to create a common derivation scheme that makes use of all new technologies.
where the BIP43 <code>purpose'</code> path is separate for each script (P2PKH, P2WPKH-in-P2SH, and P2WPKH respectively). Having a script-per-derivation for single sig wallets allows for easy backup and restore, with just the private key information.
35
35
36
-
Multisignature wallets need more information to backup and restore, and these per-script derivations are made redundant with descriptors, which describe a collection of output scripts.
36
+
Multisignature wallets need more information to backup and restore (such as all cosigner public keys), and these per-script derivations are made redundant with descriptors, which provide that information (while also specifying a collection of output scripts).
37
37
A modern standardization is needed for multisig derivation paths. There are some in existence, but all have issues. For example, BIP45 specifies:
38
38
39
39
<pre>
@@ -100,7 +100,7 @@ This level splits the key space into independent user identities, following the
100
100
101
101
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.
102
102
103
-
Accounts are numbered from index 0 in sequentially increasing manner.
103
+
Accounts are numbered from index <code>0</code> in sequentially increasing manner.
104
104
This number is used as child index in BIP32 derivation.
105
105
106
106
Hardened derivation is used at this level.
@@ -111,13 +111,13 @@ This prevents key reuse - across ECDSA and Schnorr signatures, across different
111
111
112
112
===Change===
113
113
114
-
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.
114
+
Constant <code0</code> is used for external chain and constant <code>1</code> 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.
115
115
116
116
Public derivation is used at this level.
117
117
118
118
===Index===
119
119
120
-
Addresses are numbered from index 0 in sequentially increasing manner.
120
+
Addresses are numbered from index <code>0</code> in sequentially increasing manner.
121
121
This number is used as child index in BIP32 derivation.
122
122
123
123
Public derivation is used at this level.
@@ -127,26 +127,19 @@ Public derivation is used at this level.
127
127
The multisig descriptor that is generated from the cosigners' combined key records should be used to generate and discover addresses. For example:
# Derive the wallet's first account's node (index = 0)
131
-
# Derive the external chain node of this account (index = 0)
130
+
# Derive the external chain node of this account (constant = 0)
132
131
# Scan addresses of the external chain; respect the gap limit described below
133
-
# If there are some transactions, increase the account index and go to Step 2
134
-
# If no transactions are found on the external chain, continue to search the following account indices in compliance with the account gap limit described below.
135
132
136
-
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.
133
+
Please note that the algorithm works with the transaction history, not account balances, so you can have an address with 0 total coins and the algorithm will still continue with discovery.
137
134
138
-
The wallet implementation should scan the accounts and addresses following the parent descriptor string.
135
+
The wallet implementation should scan the addresses following the parent descriptor string.
139
136
140
137
===Address Gap Limit===
141
138
142
139
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.
143
140
144
141
Wallet software should warn when the user is trying to exceed the gap limit on an external chain by generating a new address.
145
142
146
-
===Account Gap Limit===
147
-
148
-
Account gap limit is currently set to 5. When the software hits an account that contains 20 unused addresses in a row, it will search the next 4 accounts (while obeying the address gap limit), before stopping discovery. If any transactions are found during this process, discovery is restarted (after finding 20 unused addresses) on the next account index, and the account gap limit is reset. Only when the address gap limit is found consecutively for the account gap limit is discovery stopped.
0 commit comments