Bitcoin Book of BIPs

BIP 129

Introduction

Abstract

This document proposes a mechanism to set up multisig wallets securely.

This BIP is licensed under the 2-clause BSD license.

Motivation

The Bitcoin multisig experience has been greatly streamlined under BIP-0174 (Partially Signed Bitcoin Transaction). However, what is still missing is a standardized process for setting up multisig wallets securely across different vendors.

There are a number of concerns when it comes to setting up a multisig wallet:

  1. Whether the multisig configuration, such as Signer membership, script type, derivation paths and number of signatures required, is correct and not tampered with.
  2. Whether the keys or the multisig configuration are leaked during the setup.
  3. Whether the Signer persists the multisig configuration in their respective storage, and under what format.
  4. Whether the Signer’s storage is tamper-proof.
  5. Whether the Signer subsequently uses the multisig configuration to generate and verify receive and change addresses.

An attacker who can modify the multisig configuration can steal or hold funds for ransom by duping the user into sending funds to the wrong address. An attacker who cannot modify the configuration but can learn about the keys and/or the configuration can monitor transactions in the wallet, resulting in loss of privacy.

This proposal seeks to address concerns #1, #2 and #3: to mitigate the risk of tampering during the initial setup phase, and to define an interoperable multisig configuration format.

Concerns #4 and #5 should be handled by Signers and are out of scope of this proposal.

Specification

Prerequisites

This proposal assumes the parties in the multisig support BIP-0032, BIP-0322, BIP-0380 Output Script Descriptors (BIP-0381,BIP-0382,BIP-0383) and AES encryption.

File Extensions

All descriptor and key records should have a .bsms file extension. Encrypted data should have a .dat extension.

Newline

This specification uses line feed (LF) control character \n.

Roles

Coordinator

The Coordinator initiates the multisig setup. The Coordinator determines what type of multisig is used and the exact policy script. If encryption is enabled, the Coordinator also distributes a shared secret or shared secrets to the parties involved for secure communication. The Coordinator gathers information from the Signers to generate a descriptor record. The Coordinator distributes the descriptor record back to the Signers.

Signer

The Signer is any software or hardware that controls the private keys and can sign using those keys. The Signer is a participating member in the multisig. Its responsibilities include providing its key record – which contains a public key or an Extended Public Key (XPUB) – to the Coordinator, verifying that its KEY is included in the descriptor record and persisting the descriptor record in its storage.

Setup Process

Round 1
Coordinator
Signer
Round 2
Coordinator
Signer

This completes the setup.

Encryption

The Token

We define three modes of encryption.

  1. NO_ENCRYPTION : the TOKEN is set to 0x00. Encryption is disabled.
  2. STANDARD : the TOKEN is a 64-bit nonce.
  3. EXTENDED : the TOKEN is a 128-bit nonce.

The TOKEN can be converted to one of these formats:

The flexibility in the data format allows each Signer to customize the User Experience based on its respective capabilities.

Key Derivation

The key derivation function is PBKDF2, with PRF = SHA512. Specifically:

DKey = PBKDF2(PRF, Password, Salt, c, dkLen)

Whereas:

Encryption Scheme

The encryption scheme is AES-256-CTR.

MAC = HMAC-SHA256(HMAC_Key, hex-encoded TOKEN || Data)

IV = First 16 bytes of MAC

Ciphertext = AES-256-CTR-Encrypt(Plaintext, DKey, IV)

Plaintext = AES-256-CTR-Decrypt(Ciphertext, DKey, IV)

Whereas:

The MAC is to be sent along with the key and descriptor record, as specified above. Because it is a MAC over the entire plaintext, this is essentially an Encrypt-and-MAC form of authenticated encryption.

Descriptor Template

The output descriptor language only supports one-dimensional lists. This proposal introduces a descriptor template to represent multi-dimensional lists:

XPUB/**

Whereas /** can be replaced by any number of derivation path restrictions.

A descriptor template must be accompanied by derivation path restrictions. Signers should expand the template into concrete descriptors by replacing /** with the restrictions.

For example, the following template and derivation path restrictions:

Should translate to two concrete descriptors:

QR Codes

For signers that use QR codes to transmit data, key and descriptor records can be converted to QR codes, following the BCR standard.

Also refer to UR Type Definition for BIP44 Accounts and UR Type Definition for Bitcoin Output Descriptors for more details.

Compatibility

This specification is not backwards compatible with existing multisig implementations.

BSMS is opt-in, meaning existing multisig implementations can continue working as-is, with the caveat that they are likely to have various pitfalls. Some of the problems with existing solutions have been described in the #motivation section.

To comply with this standard, a Signer must be able to persist the descriptor record in its storage.

To use BSMS for a multisig wallet, the user should wait until all participating Signers in the multisig have implemented BSMS.

Security

This proposal introduces two layers of protection. The first one is a temporary, secret TOKEN. The second one is the confirmation of the wallet’s first address.

The TOKEN is used to encrypt the two rounds of communication between the Signer and the Coordinator. A MAC is also generated from the TOKEN and plaintext to authenticate the data being exchanged. The TOKEN is only needed during the setup phase, and can be safely discarded afterwards. It is not recommended to use the same TOKEN for multiple wallet creation sessions.

The wallet’s first address, on the other hand, can be used to verify the integrity of the multisig configuration. An attacker who tampers with the multisig configuration must also change the wallet’s first address. Parties must check with each other that all Signers confirm to the same address and policy parameters to reduce the chance of tampering.

Privacy

Encryption helps improve the privacy of the wallet by avoiding sharing keys and descriptors in plaintext.

If the parties wish to have stronger privacy, it is recommended to use a higher number of bits for the TOKEN, and to completely erase knowledge of the TOKEN after the multisig wallet has been set up.

Test Vectors

Mode: NO_ENCRYPTION with Public Keys

ROUND 1
BSMS 1.0
00
[59865f44/48'/0'/0'/2']026d15412460ba0d881c21837bb999233896085a9ed4e5445bd637c10e579768ba
Signer 1 key
H6DXgqkCb353BDPkzppMFpOcdJZlpur0WRetQhIBqSn6DFzoQWBtm+ibP5wERDRNi0bxxev9B+FIvyQWq0s6im4=
BSMS 1.0
00
[b7044ca6/48'/0'/0'/2']030baf0497ab406ff50cb48b4013abac8a0338758d2fd54cd934927afa57cc2062
Signer 2 key
H08mGNGN+NxX/snt+6eX2Q1HjjfDkOtotglshHi7xdsBdIrTVMCQbgQ5SdACNZ0B2AJcifK11nJj43SvaitSemI=
ROUND 2
BSMS 1.0
wsh(sortedmulti(1,[59865f44/48'/0'/0'/2']026d15412460ba0d881c21837bb999233896085a9ed4e5445bd637c10e579768ba,[b7044ca6/48'/0'/0'/2']030baf0497ab406ff50cb48b4013abac8a0338758d2fd54cd934927afa57cc2062))#rzx9dffd
No path restrictions
bc1quqy523xu3l8che3s8vja8n33qtg0uyugr9l5z092s3wa50p8t7rqy6zumf

Mode: NO_ENCRYPTION

ROUND 1
BSMS 1.0
00
[1cf0bf7e/48'/0'/0'/2']xpub6FL8FhxNNUVnG64YurPd16AfGyvFLhh7S2uSsDqR3Qfcm6o9jtcMYwh6DvmcBF9qozxNQmTCVvWtxLpKTnhVLN3Pgnu2D3pAoXYFgVyd8Yz
Signer 1 key
IB7v+qi1b+Xrwm/3bF+Rjl8QbIJ/FMQ40kUsOOQo1SqUWn5QlFWbBD8BKPRetfo1L1N7DmYjVscZNsmMrqRJGWw=
BSMS 1.0
00
[4fc1dd4a/48'/0'/0'/2']xpub6EebMbEps7ZcV3FYEnddRsvrFWDrt2tiPmCeM7pPXQEmphvq9ZfJ1LWFUDjf3vxCeBuPrfyGrMazWUsYsetrnHatQZVLJH7LsgCjtMqdzgj
Signer 2 key
HzUa4Z76PFHMl54flIIF3XKiHZ+KbWjjxCEG5G3ZqZSqTd6OgTiFFLqq9PXJXdfYm6/cnL8IVWQgjFF9DQhIqQs=
ROUND 2
BSMS 1.0
wsh(sortedmulti(2,[1cf0bf7e/48'/0'/0'/2']xpub6FL8FhxNNUVnG64YurPd16AfGyvFLhh7S2uSsDqR3Qfcm6o9jtcMYwh6DvmcBF9qozxNQmTCVvWtxLpKTnhVLN3Pgnu2D3pAoXYFgVyd8Yz/**,[4fc1dd4a/48'/0'/0'/2']xpub6EebMbEps7ZcV3FYEnddRsvrFWDrt2tiPmCeM7pPXQEmphvq9ZfJ1LWFUDjf3vxCeBuPrfyGrMazWUsYsetrnHatQZVLJH7LsgCjtMqdzgj/**))
/0/*,/1/*
bc1qrgc6p3kylfztu06ysl752gwwuekhvtfh9vr7zg43jvu60mutamcsv948ej

Mode: STANDARD Encryption

ROUND 1
BSMS 1.0
a54044308ceac9b7
[b7868815/48'/0'/0'/2']xpub6FA5rfxJc94K1kNtxRby1hoHwi7YDyTWwx1KUR3FwskaF6HzCbZMz3zQwGnCqdiFeMTPV3YneTGS2YQPiuNYsSvtggWWMQpEJD4jXU7ZzEh
Signer 1 key
H8DYht5P6ko0bQqDV6MtUxpzBSK+aVHxbvMavA5byvLrOlCEGmO1WFR7k2wu42J6dxXD8vrmDQSnGq5MTMMbZ98=
BSMS 1.0
a54044308ceac9b7
[eedff89a/48'/0'/0'/2']xpub6EhJvMneoLWAf8cuyLBLQiKiwh89RAmqXEqYeFuaCEHdHwxSRfzLrUxKXEBap7nZSHAYP7Jfq6gZmucotNzpMQ9Sb1nTqerqW8hrtmx6Y6o
Signer 2 key
H/IHW5dMGYsrRdYEz3ux+kKnkWBtxHzfYkREpnYbco38VnMvIxCbDuf7iu6960qDhBLR/RLjlb9UPtLmCMbczDE=
ROUND 2
BSMS 1.0
wsh(sortedmulti(2,[b7868815/48'/0'/0'/2']xpub6FA5rfxJc94K1kNtxRby1hoHwi7YDyTWwx1KUR3FwskaF6HzCbZMz3zQwGnCqdiFeMTPV3YneTGS2YQPiuNYsSvtggWWMQpEJD4jXU7ZzEh/**,[eedff89a/48'/0'/0'/2']xpub6EhJvMneoLWAf8cuyLBLQiKiwh89RAmqXEqYeFuaCEHdHwxSRfzLrUxKXEBap7nZSHAYP7Jfq6gZmucotNzpMQ9Sb1nTqerqW8hrtmx6Y6o/**))
/0/*,/1/*
bc1qhs4u273g4azq7kqqpe6vh5wfhasfmrq7nheyzsnq77humd7rwtkqagvakf

Mode: EXTENDED Encryption

ROUND 1
BSMS 1.0
108a2360adb302774eb521daebbeda5e
[793cc70b/48'/0'/0'/1']xpub6ErVmcYYHmavsMgxEcTZyzN5sqth1ZyRpFNJC26ij1wYGC2SBKYrgt9yariSbn7HLRoZUvhUhmPfsRTPrdhhGFscpPZzmch6UTdmRP1aZUj
Signer 1 key
ILG47LpCtjoD9UxL87jo5QFqA90t8g9fDQp/KBojdKgPPGB1pMx2bf9hPdORNZIOdCc/2+Gs6AOs3BEK9ubIuBw=
BSMS 1.0
d3fabc873b98165254fe18a71b5335b0
[b3118e52/48'/0'/0'/1']xpub6Du5Jn6eYZE96ccmAc1ZTFPzdnzrvqfG4mpamDun2qZYKywoiQJMCbS3kWWMr6U3XW6s125RLsaPABWgv2yA749ieaMe67FxkTjMsbcxCch
Signer 2 key
IDK4d/oO0pgfrwRu4Zb8vqlPEmJb9aKT1K2CCnI3RKepVAKs3fZsBrypcCdQfUy1TG/3O5vAR3gjldxcCA1Wzg8=
BSMS 1.0
78a7d5e7549453d719150de5459c9ce5
[842bd2ed/48'/0'/0'/1']xpub6Ex81KopPkEt9hJiWHabYy8LNsSR4A7sUQoFBk9dR8XxHrr4p9HrYWN3NCf5uwfopHnQkCG7FYnZMztKbtRtbh6tzZC4xtHPbmVVxRSN7ic
Signer 3 key
IL77mML0xo/O9dJn0T5EpQLuyRPPrdpgVJbtsdAugW5iX0MQ3Ci0f8jVnXu68Xm07CYjYGKX8af72jmkQKhNud0=
ROUND 2
BSMS 1.0
sh(wsh(multi(2,[793cc70b/48'/0'/0'/1']xpub6ErVmcYYHmavsMgxEcTZyzN5sqth1ZyRpFNJC26ij1wYGC2SBKYrgt9yariSbn7HLRoZUvhUhmPfsRTPrdhhGFscpPZzmch6UTdmRP1aZUj/**,[b3118e52/48'/0'/0'/1']xpub6Du5Jn6eYZE96ccmAc1ZTFPzdnzrvqfG4mpamDun2qZYKywoiQJMCbS3kWWMr6U3XW6s125RLsaPABWgv2yA749ieaMe67FxkTjMsbcxCch/**,[842bd2ed/48'/0'/0'/1']xpub6Ex81KopPkEt9hJiWHabYy8LNsSR4A7sUQoFBk9dR8XxHrr4p9HrYWN3NCf5uwfopHnQkCG7FYnZMztKbtRtbh6tzZC4xtHPbmVVxRSN7ic/**)))
/0/*,/1/*
3GzMtFXahiu4TpGNGFc4bHMvAcvz5vVQrT

Acknowledgement

Special thanks to Pavol Rusnak, Dmitry Petukhov, Christopher Allen, Craig Raw, Robert Spigler, Gregory Sanders, Ta Tat Tai, Michael Flaxman, Pieter Wuille, Salvatore Ingala, Ava Chow and others for their feedback on the specification.

References

Related mailing list threads:

  BIP: 328
  Layer: Applications
  Title: Derivation Scheme for MuSig2 Aggregate Keys
  Authors: Ava Chow <me@achow101.com>
  Status: Complete
  Type: Informational
  Assigned: 2024-06-04
  License: CC0-1.0