Published on: 2021-04-12T20:43:39+00:00
In a recent discussion on the bitcoin-dev mailing list, Christopher Allen proposed best practices for avoiding xpub reuse in multisig account creation. He recommends backing up multisig account maps and cosigner key material to enable fund recovery. It is suggested that transaction coordinators should send the cosigner "policy" and final "account map" to all cosigner wallets. These practices are possible with new generation multisig hardware and software wallets.Christopher Allen, a member of Blockchain Commons, has proposed measures to improve privacy in Bitcoin multisig accounts. He suggests that cosigner wallets and transaction coordinator services should not share the master xpub, and that the master xpub fingerprint should not be used due to privacy risks. Instead, a single parent fingerprint should be offered for each account. Transaction coordinators should also send the cosigner "policy" and final "account map" to all cosigner wallets.Salvatore Ingala and Hugo discuss the distinction between a "Signer" and a "Signing device" in a multisig setup. Salvatore proposes a wallet registration flow that allows a Signer to persist a multisig setup in its storage. Hugo emphasizes that signers must be stateful and highlights the problems with signing the descriptor record.Michael expresses concerns about the xpub validation problem and the risk of stateless hardware wallets having their xpubs swapped out. He suggests using a checksum with higher entropy to reduce xpub validation to O(n) and creating an unambiguous format for wallet ID. Hugo disagrees with going stateless and argues that signers must be stateful. Michael raises concerns about malicious receive addresses and the use of BIP39 words for session tokens.A proposed Bitcoin Secure Multisig Setup (BSMS) BIP aims to set up multisig wallets securely. Michael raises concerns about the BIP's shortcomings in addressing verification of hardware wallets and risks for stateless hardware wallets. The proposal outlines the process for creating a multisig wallet using encryption to improve privacy. The coordinator gathers key records from all participating signers and verifies their validity before generating a descriptor record. The descriptor record is encrypted and sent to all signers.In a conversation between Michael and Hugo, they discuss the issues with multisig in Bitcoin. Michael raises concerns about the xpub validation problem and the risk of compromised coordinators swapping out xpubs in stateless hardware wallets. Hugo disagrees with going stateless and highlights problems with signing the descriptor record. Michael also suggests avoiding the use of BIP39 words for session tokens.A proposed Bitcoin Secure Multisig Setup (BSMS) BIP has been drafted to address concerns surrounding tampering during initial setup. Michael Flaxman expresses concerns about the BIP's failure to address verification of hardware wallets and risks for stateless hardware wallets. The proposal outlines the process for creating a multisig wallet using encryption. The coordinator generates key records and a descriptor record, which are encrypted and sent to all signers.The context provided includes discussions on multisig setup context, the need for devices to persist the descriptor, and the redundancy of BIP48 with descriptors. It is suggested that Shamir Secret Sharing could be used for encryption convention and a preference for plain text over binary. Multisig setup context is considered important for developing multisig setups.Bitcoin Secure Multisig Setup (BSMS) proposal introduces a Coordinator and multiple Signers in the setup process. The Coordinator takes the lead in initiating the multisig setup, determining the type of multisig used, and gathering information from the signers to generate a descriptor record. Signers are responsible for providing their XPUB to the Coordinator, verifying its inclusion in the descriptor record, and persisting the record in their storage.The setup process involves two rounds of communication. In round one, the Coordinator creates a multisig wallet creation session, generates a secret token, and shares it securely with all participating signers. The signers then generate a key record by prompting the user for the token and a derivation path. In round two, the Coordinator gathers key records from all signers, decrypts them using an encryption key, verifies the included signatures, and generates a descriptor record. The descriptor record is encrypted and sent to all signers.To ensure security during setup, the proposal recommends using multi-round Distributed Key Generation (DKG) with appropriate commitments and verification of components. It also suggests using encryption conventions for the descriptor data, allowing decryption with any of the seeds to access the full setup. Additional suggestions include using magic bytes for file extensions and plaintext files for human readability.One concern raised is losing multisig setup context, which could result in lost coins. If one device is lost in a 2-of-3 setup without metadata, the coins will be lost. To address this, the proposal recommends an encryption convention that allows decryption of the full setup file with any of the seeds.
Updated on: 2023-08-02T03:06:18.370020+00:00