BIP: x Layer: Applications Title: Multi-Account Hierarchy for P2WSH Multi-signature Deterministic Wallets Author: Braydon Fuller <[email protected]> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-x Status: Draft Type: Standards Track Created: 2019-02-12 License: PD
This BIP defines a structure for multi-account hierarchical deterministic P2WSH (BIP143) multi-party multi-signature wallets based on the algorithm described in BIP32 and purpose scheme described in BIP43. It is intended to be implemented along-side BIP44.
This BIP is a particular application of BIP43.
With the usage of P2WSH (BIP143) transactions it is necessary to have a common derivation scheme for multi-signature wallets.
The structure proposed in this paper is quite comprehensive. It allows the handling of multiple coins, multiple accounts, external and internal chains per account and millions of addresses per chain. It defines standard ways to create, use, import, and store wallets. It allows to handle multiple parties sharing an m-of-n wallet, on the following assumptions:
nparties share anm-of-nwallet.- Each party generates their master private keys independently.
- Multisig P2WSH (BIP143) is used for all addresses. Additional proposals can extend this for use with other addresses using a different purpose field.
- BIP32 is used to derive public keys, then create a multisig script, and the corresponding P2WSH address for that script.
- Address generation should not require communication between parties after the initial shared account setup.
- Transaction creation and signing requires communication between parties.
- A single master node (seed) can be used for multiple shared accounts with different parties, as is often the case with hardware.
We define the following levels in BIP32 path:
m / purpose' / coin_type' / shared_account' / change / address_index
Apostrophe in the path indicates that BIP32 hardened derivation is used.
Each level has special meaning described in the chapters below.
Purpose is a constant set to x, following the BIP43 recommendation. It indicates that the subtree of this node is used according to this specification.
m / x' / *
Hardened derivation is used at this level.
One master node (seed) can be used for many independent coins such as Bitcoin, Handshake, and others. However, sharing the same space for various coins has some disadvantages.
This level creates a separate subtree for every coin, avoiding reusing addresses across coins and improving privacy issues.
Coin type is a constant, set for each coin. Coin developers may ask for registering unused number for their project.
The list of already allocated coin types is in the chapter "Registered coin types" from BIP44.
Hardened derivation is used at this level.
This level splits the key space for independent shared accounts.
Users can use these shared accounts to organize with different groups of cosigners and for different purposes; donations (where all addresses are considered public), for saving, for common expenses etc.
This number is used as child index in BIP32 derivation.
Hardened derivation is used at this level.
To create a new shared account; each party shares their extended shared account public key with the other cosigners. Each party can generate any of the other's derived public keys, but only their own private keys.
Software should facilitate backup of the shared accounts and associated cosigner extended public keys whenever there is a new shared account created. Such backup serialization is described in the "Shared account export" chapter. Software should warn a user if a backup has not been made.
Software needs to restore based on the serialization of all shared accounts and cosigners when importing the seed from an external source. Such an algorithm is described in the "Shared account import" chapter.
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.
For example, if a cosigner wants to generate a change address, they would use m / x' / coin_type' / shared_account' / 1 / *, and m / x' / coin_type' / shared_account' / 0 / * for a receive address.
Non-hardened derivation is used at this level.
Addresses are numbered from index 0 in sequentially increasing manner. This number is used as child index in BIP32 derivation.
Non-hardened derivation is used at this level.
When generating an address, each party can independently generate the n needed public keys. They do this by deriving the public key for each cosigner tree, but using the same path. They can then generate the multisig script (by lexicographically sorting the public keys) and the corresponding p2wsh address.
When creating a transaction, first one of the parties creates a transaction proposal. This is a transaction that spends some output stored in any of the p2wsh multisig addresses. This proposal is sent to the other parties, who decide if they want to sign. If they approve the proposal, they can generate their needed private key for that specific address (using the same path that generated the public key in that address, but deriving the private key instead), and sign it. Once the proposal reaches m signatures, any cosigner can broadcast it to the network, becoming final.
When the master seed is imported from an external source the software should also include the account export data described in the "Shared account export" chapter, and then discover the addresses in the following manner:
For each shared account:
- store the shared account index mapped to the cosigner extended public keys and the
m-of-n - derive the external chain node of this account (
m / x' / coin_type' / account' / 0) for all cosigners - scan addresses of the chain; respect the gap limit described below
The initial exchange of account extended public keys between cosigners should be backed up with each cosigner's master seed for later discovery of each account. Each shared account is adding external entropy to the master seed, and essential to discovery and spending of coins.
The export is serialized as follows:
- 4 bytes: version bytes
- 4 bytes: number of accounts
- 4 bytes: shared account index
- 2 bytes:
mofm-of-n - 2 bytes:
nofm-of-n
- 1 byte: depth
- 4 bytes: the fingerprint of the parent's key
- 4 bytes: child number
- 32 bytes: the chain code
- 33 bytes: the public key
Address gap limit is currently set to 20. If the software hits 20 unused addresses (no transactions associated with that address) 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 user is trying to exceed the gap limit on an external chain by generating a new address.
- BIP32 - Hierarchical Deterministic Wallets
- BIP43 - Purpose Field for Deterministic Wallets
- BIP44 - Multi-Account Hierarchy for Deterministic Wallets
- BIP45 - Structure for Deterministic P2SH Multisignature Wallets
- BIP143 - Transaction Signature Verification for Version 0 Witness Program
This document is placed in the public domain.
I have also considered adding a case for a 1-of-1 account to be handled as a P2PKH address instead of P2WSH, so that there could be 1-of-1 accounts with 2-of-3 accounts of the same wallet. However, this can be better handled with the same master node (seed) via BIP44, and new accounts can be created without breaking the determinism of wallet recovery.