|
| 1 | +<pre> |
| 2 | + BIP: 48 |
| 3 | + Layer: Applications |
| 4 | + Title: Multi-Account/Multi-Script Hierarchy for Deterministic Multi Signature Wallets |
| 5 | + Author: Peter Denton < [email protected]> |
| 6 | + Comments-Summary: Mixed review (one person) |
| 7 | + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0048 |
| 8 | + Status: Proposed |
| 9 | + Type: Standards Track |
| 10 | + Created: 2020-12-16 |
| 11 | +</pre> |
| 12 | + |
| 13 | +==Abstract== |
| 14 | + |
| 15 | +This BIP defines a logical hierarchy for deterministic multi-sig wallets based on an algorithm |
| 16 | +described in BIP-0067 (BIP67 from now on), BIP-0032 (BIP32 from now on) and purpose scheme described in |
| 17 | +BIP-0043 (BIP43 from now on). |
| 18 | + |
| 19 | +This BIP is a particular application of BIP43. |
| 20 | + |
| 21 | +==Motivation== |
| 22 | + |
| 23 | +The hierarchy proposed in this paper is quite comprehensive. It allows the handling of |
| 24 | +multiple accounts, external and internal chains per account, multiple script types and |
| 25 | +millions of addresses per chain. |
| 26 | + |
| 27 | +==Key sorting== |
| 28 | + |
| 29 | +Any wallet that supports BIP48 inherently supports deterministic key sorting as per BIP67 so that all possible |
| 30 | +multi-signature addresses/scripts are derived from deterministically ordered public keys. |
| 31 | + |
| 32 | +==Path levels== |
| 33 | + |
| 34 | +We define the following 6 levels in BIP32 path: |
| 35 | + |
| 36 | +<pre> |
| 37 | +m / purpose' / coin_type' / account' / script_type' / change / address_index |
| 38 | +</pre> |
| 39 | + |
| 40 | +`h` in the path indicates that BIP32 hardened derivation is used. |
| 41 | + |
| 42 | +Each level has a special meaning, described in the chapters below. |
| 43 | + |
| 44 | +===Purpose=== |
| 45 | + |
| 46 | +Purpose is a constant set to 48' following the BIP43 recommendation. |
| 47 | +It indicates that the subtree of this node is used according to this specification. |
| 48 | + |
| 49 | +Hardened derivation is used at this level. |
| 50 | + |
| 51 | +===Coin type=== |
| 52 | + |
| 53 | +One master node (seed) can be used for either multiple Bitcoin networks. |
| 54 | +Sharing the same space for various networks has some disadvantages. |
| 55 | + |
| 56 | +Avoiding reusing addresses across networks and improving privacy issues. |
| 57 | + |
| 58 | +Coin type `0` for mainnet and `1` for testnet. |
| 59 | + |
| 60 | +Hardened derivation is used at this level. |
| 61 | + |
| 62 | +===Account=== |
| 63 | + |
| 64 | +This level splits the key space into independent user identities, |
| 65 | +so the wallet never mixes the coins across different accounts. |
| 66 | + |
| 67 | +Users can use these accounts to organize the funds in the same |
| 68 | +fashion as bank accounts; for donation purposes (where all |
| 69 | +addresses are considered public), for saving purposes, |
| 70 | +for common expenses etc. |
| 71 | + |
| 72 | +Accounts are numbered from index 0 in sequentially increasing manner. |
| 73 | +This number is used as child index in BIP32 derivation. |
| 74 | + |
| 75 | +Hardened derivation is used at this level. |
| 76 | + |
| 77 | +Software should prevent a creation of an account if a previous account does not |
| 78 | +have a transaction history (meaning none of its addresses have been used before). |
| 79 | + |
| 80 | +Software needs to discover all used accounts after importing the seed from |
| 81 | +an external source. Such an algorithm is described in "Account discovery" chapter. |
| 82 | + |
| 83 | +===Script=== |
| 84 | + |
| 85 | +This level splits the key space into three separate `script_type`(s). To provide |
| 86 | +optimum backward compatibility. |
| 87 | + |
| 88 | +The recommended default is pay to witness script hash `m/48'/0'/0'/2'`. |
| 89 | + |
| 90 | +The following represent mainnet, account 0. |
| 91 | + |
| 92 | +`1'`: Nested Segwit (p2sh-p2wsh) `m/48'/0'/0'/1'`</br> |
| 93 | +`2'`: Native Segwit (p2wsh) `m/48'/0'/0'/2'`</br> |
| 94 | +`3'`: Legacy (p2sh) `m/48'/0'/0'/3'`</br> |
| 95 | + |
| 96 | +===Change=== |
| 97 | + |
| 98 | +Constant 0 is used for external chain and constant 1 for internal chain (also |
| 99 | +known as change addresses). External chain is used for addresses that are meant |
| 100 | +to be visible outside of the wallet (e.g. for receiving payments). Internal |
| 101 | +chain is used for addresses which are not meant to be visible outside of the |
| 102 | +wallet and is used for return transaction change. |
| 103 | + |
| 104 | +Public derivation is used at this level. |
| 105 | + |
| 106 | +===Index=== |
| 107 | + |
| 108 | +Addresses are numbered from index 0 in sequentially increasing manner. |
| 109 | +This number is used as child index in BIP32 derivation. |
| 110 | + |
| 111 | +Public derivation is used at this level. |
| 112 | + |
| 113 | +==Account discovery== |
| 114 | + |
| 115 | +When the master seed is imported from an external source the software should |
| 116 | +start to discover the accounts in the following manner: |
| 117 | + |
| 118 | +* derive the first accounts node (index = 0) |
| 119 | +* derive the external chain node of this account |
| 120 | +* scan addresses of the external chain; respect the gap limit described below |
| 121 | +* if no transactions are found on the external chain, stop discovery |
| 122 | +* if there are some transactions, increase the account index and go to step 1 |
| 123 | +
|
| 124 | +This algorithm is successful because software should disallow creation of new |
| 125 | +accounts if previous one has no transaction history, as described in chapter |
| 126 | +"Account" above. |
| 127 | + |
| 128 | +Please note that the algorithm works with the transaction history, not account |
| 129 | +balances, so you can have an account with 0 total coins and the algorithm will |
| 130 | +still continue with discovery. |
| 131 | + |
| 132 | +===Address gap limit=== |
| 133 | + |
| 134 | +Address gap limit is currently set to 20. If the software hits 20 unused |
| 135 | +addresses in a row, it expects there are no used addresses beyond this point |
| 136 | +and stops searching the address chain. We scan just the external chains, because |
| 137 | +internal chains receive only coins that come from the associated external chains. |
| 138 | + |
| 139 | +Wallet software should warn when the user is trying to exceed the gap limit on |
| 140 | +an external chain by generating a new address. |
| 141 | + |
| 142 | +==Examples== |
| 143 | + |
| 144 | +{| |
| 145 | +!coin |
| 146 | +!account |
| 147 | +!script |
| 148 | +!chain |
| 149 | +!address |
| 150 | +!path |
| 151 | +|- |
| 152 | +|Bitcoin |
| 153 | +|first |
| 154 | +|external |
| 155 | +|first |
| 156 | +|m / 48' / 0' / 0' / 2' / 0 / 0 |
| 157 | +|- |
| 158 | +|Bitcoin |
| 159 | +|first |
| 160 | +|external |
| 161 | +|second |
| 162 | +|m / 48' / 0' / 0' / 2' / 0 / 1 |
| 163 | +|- |
| 164 | +|Bitcoin |
| 165 | +|first |
| 166 | +|change |
| 167 | +|first |
| 168 | +|m / 48' / 0' / 0' / 2' / 1 / 0 |
| 169 | +|- |
| 170 | +|Bitcoin |
| 171 | +|first |
| 172 | +|change |
| 173 | +|second |
| 174 | +|m / 48' / 0' / 0' / 2' / 1 / 1 |
| 175 | +|- |
| 176 | +|Bitcoin |
| 177 | +|second |
| 178 | +|external |
| 179 | +|first |
| 180 | +|m / 48' / 0' / 1' / 2' / 0 / 0 |
| 181 | +|- |
| 182 | +|Bitcoin |
| 183 | +|second |
| 184 | +|external |
| 185 | +|second |
| 186 | +|m / 48' / 0' / 1' / 2' / 0 / 1 |
| 187 | +|- |
| 188 | +|Bitcoin |
| 189 | +|second |
| 190 | +|change |
| 191 | +|first |
| 192 | +|m / 48' / 0' / 1' / 2' / 1 / 0 |
| 193 | +|- |
| 194 | +|Bitcoin |
| 195 | +|second |
| 196 | +|change |
| 197 | +|second |
| 198 | +|m / 48' / 1' / 1' / 2' / 1 / 1 |
| 199 | +|- |
| 200 | +|Bitcoin Testnet |
| 201 | +|first |
| 202 | +|external |
| 203 | +|first |
| 204 | +|m / 48' / 1' / 0' / 2' / 0 / 0 |
| 205 | +|- |
| 206 | +|Bitcoin Testnet |
| 207 | +|first |
| 208 | +|external |
| 209 | +|second |
| 210 | +|m / 48' / 1' / 0' / 2' / 0 / 1 |
| 211 | +|- |
| 212 | +|Bitcoin Testnet |
| 213 | +|first |
| 214 | +|change |
| 215 | +|first |
| 216 | +|m / 48' / 1' / 0' / 2' / 1 / 0 |
| 217 | +|- |
| 218 | +|Bitcoin Testnet |
| 219 | +|first |
| 220 | +|change |
| 221 | +|second |
| 222 | +|m / 48' / 1' / 0' / 2' / 1 / 1 |
| 223 | +|- |
| 224 | +|Bitcoin Testnet |
| 225 | +|second |
| 226 | +|external |
| 227 | +|first |
| 228 | +|m / 48' / 1' / 1' / 2' / 0 / 0 |
| 229 | +|- |
| 230 | +|Bitcoin Testnet |
| 231 | +|second |
| 232 | +|external |
| 233 | +|second |
| 234 | +|m / 48' / 1' / 1' / 2' / 0 / 1 |
| 235 | +|- |
| 236 | +|Bitcoin Testnet |
| 237 | +|second |
| 238 | +|change |
| 239 | +|first |
| 240 | +|m / 48' / 1' / 1' / 2' / 1 / 0 |
| 241 | +|- |
| 242 | +|Bitcoin Testnet |
| 243 | +|second |
| 244 | +|change |
| 245 | +|second |
| 246 | +|m / 48 h / 1' / 1' / 2' / 1 / 1 |
| 247 | +|} |
| 248 | + |
| 249 | +==Reference== |
| 250 | + |
| 251 | +* [[bip-0067.mediawiki|BIP67 - Deterministic Pay-to-script-hash multi-signature addresses through public key sorting]] |
| 252 | +* [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]] |
| 253 | +* [[bip-0043.mediawiki|BIP43 - Purpose Field for Deterministic Wallets]] |
0 commit comments