Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
Hi Craig, Comments inline. On Tue, Feb 9, 2021 at 1:17 AM Craig Raw wrote: > Hi Hugo, > > Thanks for raising this again - I'll note there has already been much > discussion on this topic. With respect to your "two layers of protection": > > > The Coordinator shares the TOKEN with all participating Signers over a > secure channel. > > What secure channel do you propose? Currently, with the default of a > software wallet coordinator talking to hardware wallets, we have USB, file > (microSD), and QR as communication channels. It's unclear to me why the > token and encryption process is necessary - in fact it's easier to verify > what is going on using clear text, and the majority of setups will be > locally done with the reasonable assumption of a secure environment. When > the setup is remote, it's simpler to just transmit the key information over > the secure channel which presumably already has encryption. > > In short, a shared secret (the TOKEN) is needed because without it you cannot guarantee that the devices you are connecting to are legitimate members of the multisig wallet. Yes, the connection between the coordinator and each device could be secure - but a malicious actor can establish a secure channel just as well as a good one. You are correct that this is less of an issue for local setups, but this is especially important for distributed multisig - where you cannot physically see what's on the other side. I would love to remove the shared secret/encryption aspect out of the proposal, but so far I haven't found any way around this issue, aside from establishing a shared secret prior to setting up the wallet... I also realized that supporting this could be a big ask for vendors, so I've made this part of the proposal optional. Another note here is that right after I posted the proposal (classic...), I also realized there could be another optimization: the secure session established by the shared secret can remain open indefinitely on the device side - until a different TOKEN is entered. That way the user needs to enter the TOKEN only once, saving us one interaction. > > The second one is through the descriptor checksum and visual inspection > of the descriptor itself. > > This is a reasonable suggestion, although it's worth noting that support > for storing multisig setups on hardware wallets varies. Coldcard supports > this through importing of a proprietary .txt format file (which has been > adopted by a number of other vendors). Trezor and Ledger (AFAIK) do not > however store multisig setups, which could make this step confusing. With > that said, the use of an output descriptor is certainly a more standardised > approach, albeit one without the wallet name included. By the use of the > singular, I assume you mean a descriptor without the /0/* or /1/* suffix > (which I think is a good idea). > > I'm aware that Trezor and Ledger currently cannot support this. But IMHO lack of support on some devices shouldn't prevent us from setting a good standard here. Cosigner registration on the device is crucial, as you don't have to rely on everything being included in the PSBT (which also adds mental overhead as the user has to verify each and every transaction). Yes, descriptor without the /0/* and /1/* - Thanks for clarifying. Will update the proposal. > WRT to QR codes, using the BCR UR2.0 standard you linked to is IMO the > right approach. I'll link directly to the two BCR UR2.0 formats here which > are relevant: > > 1. For sharing the sharing the BIP44 account information from the signers > to the coordinator, the crypto-account format: [ > https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-015-account.md > ] > 2. For sharing the output descriptor from the coordinator to the signers, > the crypto-output format: [ > https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-010-output-desc.md > ] > > Thanks, will update! > Craig > > > > On Tue, Feb 9, 2021 at 9:53 AM Hugo Nguyen via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Hi all, >> I would like to propose a new BIP for Secure Multisig Setup. >> This proposal has taken inputs from folks at Coldcard, Shift Crypto and >> Cobo -- listed below as co-authors. >> >> This was inspired by my own experience working with hardware wallets on >> the market, as well as existing research into the challenges of multisig. >> >> Cheers, >> Hugo >> >> >> BIP: To be determined >> Layer: Applications >> Title: Bitcoin Secure Multisig Setup (BSMS) >> Author: Hugo Nguyen , Peter Gray , >> Marko Bencun , Aaron Chen , >> Rodolfo Novak >> Comments-Summary: No comments yet. >> Comments-URI: >> Status: Proposed >> Type: Standards Track >> Created: 2020-11-10 >> License: BSD-2-Clause >> >> >> ==Introduction== >> >> ===Abstract=== >> >> This document proposes a mechanism to set up multisig wallets securely. >> >> ===Copyright=== >> >> This BIP is licensed under the 2-clause BSD l
Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
On Tue, Feb 9, 2021 at 2:19 AM Christopher Allen < christoph...@lifewithalacrity.com> wrote: > > > On Tue, Feb 9, 2021 at 2:06 AM Hugo Nguyen wrote: > >> >> I don't think reusing XPUBs inside different multisig wallets is a good >> idea... For starters, loss of privacy in one wallet will immediately affect >> privacy of other wallets. I think multisig wallets should be completely >> firewalled from each other. That means one unique XPUB per wallet. This is >> what we have been doing with the Nunchuk wallet. >> > > To be clear, I have stated repeatedly that xpub reuse into multisig is a > poor practice. However, finding a trustless solution when a wallet is > airgapped with no network, or is stateless like Trezor, is quite hard. > > The challenge also includes how does an airgapped or stateless wallet know > that it is talking to the same process on the other side that that it gave > the xpub to in the first place. Without state to allow for a commitment, or > at least a TOFU, a cosigner who thought he was part of a 3 of 5 could > discover that he instead is in a 2 of 3, or in a script with an OR, as some > form of scam. > The shared secret approach that I mentioned in the proposal actually can help you here. The TOKEN doubles as a session ID - thereby establishing a common state on both sides. Best, Hugo > > — Christopher Allen > >> ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
Hi Christopher, Comments inline. On Tue, Feb 9, 2021 at 1:31 AM Christopher Allen < christoph...@lifewithalacrity.com> wrote: > In the Airgapped Wallet Community we also have been investigating > solutions, in particular as current common practice is is reuse the same > xpub for all multisigs, for instance [90081696/48'/0'/0'/2'] > xpub6DYLEkDfCdHzh5FHGHDJksQvFqu6kYANa1sfo6fA8n5ZWkSwyCRVVzyq9LY2eNGB6T9BKDeGJp2ZarjRZHd7WB95nSaFEDhFMK6zSV6D49b > > I don't think reusing XPUBs inside different multisig wallets is a good idea... For starters, loss of privacy in one wallet will immediately affect privacy of other wallets. I think multisig wallets should be completely firewalled from each other. That means one unique XPUB per wallet. This is what we have been doing with the Nunchuk wallet. > We’ve also have been looking into multi round commitment scheme, but > wanted to align the UX so that it would work like to musig for users. > Discussion on it is scattered, for instance > > https://github.com/BlockchainCommons/Airgapped-Wallet-Community/discussions/16#discussioncomment-212013 > > Nothing got as far as your version though. > > So Concept ACK from Blockchain Commons. Less clear on your specifics > though. We will review. > > Note that we are releasing a descriptor & multisig centric iOS and Android > reference wallet soon so solving this correctly and having interoperability > with others is very important for our roadmap. > Thank you and good to know ! Look forward to solving this correctly as well. Best, Hugo > > — Christopher Allen > > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
In the Airgapped Wallet Community we also have been investigating solutions, in particular as current common practice is is reuse the same xpub for all multisigs, for instance [90081696/48'/0'/0'/2'] xpub6DYLEkDfCdHzh5FHGHDJksQvFqu6kYANa1sfo6fA8n5ZWkSwyCRVVzyq9LY2eNGB6T9BKDeGJp2ZarjRZHd7WB95nSaFEDhFMK6zSV6D49b We’ve also have been looking into multi round commitment scheme, but wanted to align the UX so that it would work like to musig for users. Discussion on it is scattered, for instance https://github.com/BlockchainCommons/Airgapped-Wallet-Community/discussions/16#discussioncomment-212013 Nothing got as far as your version though. So Concept ACK from Blockchain Commons. Less clear on your specifics though. We will review. Note that we are releasing a descriptor & multisig centric iOS and Android reference wallet soon so solving this correctly and having interoperability with others is very important for our roadmap. — Christopher Allen ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
Hi Hugo, Thanks for raising this again - I'll note there has already been much discussion on this topic. With respect to your "two layers of protection": > The Coordinator shares the TOKEN with all participating Signers over a secure channel. What secure channel do you propose? Currently, with the default of a software wallet coordinator talking to hardware wallets, we have USB, file (microSD), and QR as communication channels. It's unclear to me why the token and encryption process is necessary - in fact it's easier to verify what is going on using clear text, and the majority of setups will be locally done with the reasonable assumption of a secure environment. When the setup is remote, it's simpler to just transmit the key information over the secure channel which presumably already has encryption. > The second one is through the descriptor checksum and visual inspection of the descriptor itself. This is a reasonable suggestion, although it's worth noting that support for storing multisig setups on hardware wallets varies. Coldcard supports this through importing of a proprietary .txt format file (which has been adopted by a number of other vendors). Trezor and Ledger (AFAIK) do not however store multisig setups, which could make this step confusing. With that said, the use of an output descriptor is certainly a more standardised approach, albeit one without the wallet name included. By the use of the singular, I assume you mean a descriptor without the /0/* or /1/* suffix (which I think is a good idea). WRT to QR codes, using the BCR UR2.0 standard you linked to is IMO the right approach. I'll link directly to the two BCR UR2.0 formats here which are relevant: 1. For sharing the sharing the BIP44 account information from the signers to the coordinator, the crypto-account format: [ https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-015-account.md ] 2. For sharing the output descriptor from the coordinator to the signers, the crypto-output format: [ https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-010-output-desc.md ] Craig On Tue, Feb 9, 2021 at 9:53 AM Hugo Nguyen via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi all, > I would like to propose a new BIP for Secure Multisig Setup. > This proposal has taken inputs from folks at Coldcard, Shift Crypto and > Cobo -- listed below as co-authors. > > This was inspired by my own experience working with hardware wallets on > the market, as well as existing research into the challenges of multisig. > > Cheers, > Hugo > > > BIP: To be determined > Layer: Applications > Title: Bitcoin Secure Multisig Setup (BSMS) > Author: Hugo Nguyen , Peter Gray , > Marko Bencun , Aaron Chen , > Rodolfo Novak > Comments-Summary: No comments yet. > Comments-URI: > Status: Proposed > Type: Standards Track > Created: 2020-11-10 > License: BSD-2-Clause > > > ==Introduction== > > ===Abstract=== > > This document proposes a mechanism to set up multisig wallets securely. > > ===Copyright=== > > This BIP is licensed under the 2-clause BSD license. > > ===Motivation=== > > The Bitcoin multisig experience has been greatly streamlined under [ > https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki 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: > > # Whether the multisig configuration, such as Signer membership, script > type, derivation paths and number of signatures required, is correct and > not tampered with. > # Whether Signer persists the multisig configuration in their respective > storage, and under what format. > # Whether Signer's storage is tamper-proof. > # Whether 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 to ransom by duping the user into sending funds to the wrong address. > > This proposal seeks to address concerns #1 and #2: to mitigate the risk of > tampering during the initial setup phase, and to define an interoperable > multisig configuration format. > > Concerns #3 and #4 should be handled by Signers and is out of scope of > this proposal. > > ==Specification== > > ===Prerequisites=== > This proposal assumes the parties in the multisig support [ > https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki BIP32], [ > https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md the > descriptor language] and encryption. > > ==Roles== > ===Coordinator=== > > The Coordinator initiates the multisig setup. The Coordinator determines > what type of multisig is used and how many members and signatures are > needed. If encryption is enabled, the Coordinator generates a secret token, > to be shared among
