From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 773B6C013A for ; Tue, 9 Feb 2021 09:33:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id 73DBC860EA for ; Tue, 9 Feb 2021 09:33:53 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from fraxinus.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZwnUciCEjgbX for ; Tue, 9 Feb 2021 09:33:50 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-io1-f49.google.com (mail-io1-f49.google.com [209.85.166.49]) by fraxinus.osuosl.org (Postfix) with ESMTPS id 4B4AE86031 for ; Tue, 9 Feb 2021 09:33:50 +0000 (UTC) Received: by mail-io1-f49.google.com with SMTP id e133so18021000iof.8 for ; Tue, 09 Feb 2021 01:33:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=ODI0+LId4XwadBF+mOfZ/DK/K4a8WxfhKgMTppGNjug=; b=pfAGoc8SG8OGsyLmilyvs4hQWQZDrX39vyxuS9vZUnOR07OrNrqB2Y03D2EDhLguas hx+ak/I71XQIRbBlytmojMDa5CRS1EUSXYjMFVco3MBW3D5X4eyHJ34jmJPrFn+SG9iE SyHZEWJ1Ru/lo0LOkqFVYnu+X5Tq9ChdT9S5G6q2ketBdFMOghxjMwRq9mdsdf73En6w 4HqkvaK8wuw+yQKg9dwkEZLp3ga6BdX8Lbolk7wozDZ5XCDVgL3/aRH1Dl9E333BcTkX lF0sZjKmrDoOlui6hjh0OCM5sBs/FWMnDn0BQaXz7+fDO4V2tekYteyw3dd2elZbHSgq Q8Tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=ODI0+LId4XwadBF+mOfZ/DK/K4a8WxfhKgMTppGNjug=; b=eexamQoFZh+HMouqOjg1NZ51Li+qqwxKurzASSzRo1uSBMD0spmOTT3xthvOMJwUU4 wjvQCExKvH9ybkeydKSqJsRHPmPyatwxRoCZST2c2kW2jxzN08q4g+dV9G0hSbbSw7g/ iRlRlKJbONMvz7wvtHAfBcNWUx17dynIEA4LhZRgOSoiJvuN/nT0wruP7566Y8RV7y1g ZO5gAF7ebNvTtrnuZU/3R9d6quMxOBc4gwbOSsxM6ORF0CwXzuQFFMKbChL86KvqPTKA y9F/J6v8M3w61iK/BZOY95JB+JCOLky1EuR/uN6URRj2wcmFbTKaPBjQVSTdvfFEhvPj K+ZA== X-Gm-Message-State: AOAM531h5wKBaC+yGgSwE8QgUDvWeeZ2dW4L1xRufLurmK1Zit6hZaQo AxtBvWZfHz1I8mpkxTGmLQ66PM53vZfoU/bfVxY= X-Google-Smtp-Source: ABdhPJxt1SbFb13ysmP0k6u6ctaHh7bZnSKM7TYHwQGuiNhx9MDcKieTZ4HQWUPjz21nTC/gvnZqbwXpT597VGRiQdg= X-Received: by 2002:a05:6602:106:: with SMTP id s6mr18070868iot.17.1612863229595; Tue, 09 Feb 2021 01:33:49 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Craig Raw Date: Tue, 9 Feb 2021 11:33:38 +0200 Message-ID: To: Hugo Nguyen , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000df152b05bae3fb50" X-Mailman-Approved-At: Tue, 09 Feb 2021 11:38:02 +0000 Subject: Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2021 09:33:53 -0000 --000000000000df152b05bae3fb50 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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-0= 15-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-0= 10-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
>
> > =3D=3DIntroduction=3D=3D > > =3D=3D=3DAbstract=3D=3D=3D > > This document proposes a mechanism to set up multisig wallets securely. > > =3D=3D=3DCopyright=3D=3D=3D > > This BIP is licensed under the 2-clause BSD license. > > =3D=3D=3DMotivation=3D=3D=3D > > 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 i= s > 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 addres= s. > > This proposal seeks to address concerns #1 and #2: to mitigate the risk o= f > 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. > > =3D=3DSpecification=3D=3D > > =3D=3D=3DPrerequisites=3D=3D=3D > 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. > > =3D=3DRoles=3D=3D > =3D=3D=3DCoordinator=3D=3D=3D > > 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 toke= n, > to be shared among the parties 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. > > =3D=3D=3DSigner=3D=3D=3D > > The Signer is a participating member in the multisig. Its responsibilitie= s > include providing its XPUB to the Coordinator, verifying that its XPUB is > included in the descriptor record and persisting the descriptor record in > its storage. > > =3D=3DSetup Process=3D=3D > > =3D=3D=3DRound 1=3D=3D=3D > > =3D=3D=3D=3DCoordinator=3D=3D=3D=3D > > * The Coordinator creates a multisig wallet creation session. The > Coordinator determines the type of multisig script used and the signing > configuration (M and N). > * If encryption is enabled, the Coordinator also generates a secret token= , > hereby denoted TOKEN. > * TOKEN is in ASCII format and must have a minimum of 8 characters. TOKEN > should expire after some time period determined by the Coordinator, e.g., > 24 hours. > * TOKEN acts as an encryption key among the parties. The method of > encryption is AES, CTR mode. The encryption key can be calculated by > performing a double hash operation on the TOKEN: ENCRYPTION_KEY =3D > SHA256(SHA256(TOKEN)). > * A TOKEN value of -1 means that encryption is disabled and all > the encryption/decryption steps below can be skipped. > * The Coordinator shares the TOKEN with all participating Signers over a > secure channel. > > =3D=3D=3D=3DSigner=3D=3D=3D=3D > > * The Signer generates a key record by prompting the user for the TOKEN > and a derivation path. > * The first line in the record must be the TOKEN. If encryption > is disabled, set the TOKEN to -1. The second line must be the KEY, > whereas KEY is an XPUB. KEY must include key origin information and writt= en > in the descriptor-defined format, i.e.: [{master key > fingerprint}/{derivation path}]{XPUB}. The third line must be a > SIG, whereas SIG is the signature generated by using the > corresponding private key to sign the first two lines. Finally, the Signe= r > encrypts the entire record with ENCRYPTION_KEY. > > =3D=3D=3DRound 2=3D=3D=3D > > =3D=3D=3D=3DCoordinator=3D=3D=3D=3D > > * The Coordinator gathers key records from all participating Signers. > Abort the setup if TOKEN has expired. > * For each key record, the Coordinator decrypts it using ENCRYPTION_KEY. > The Coordinator verifies that the included SIG is valid given the KEY. > * If all key records look good, the Coordinator generates a descriptor > record, which is simply the descriptor string plus a CHECKSUM, a= ll > in one line. The CHECKSUM has BECH32 encoding and is described at [ > https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md#checksu= ms]. > The Coordinator encrypts this descriptor record with ENCRYPTION_KEY. > * The Coordinator sends the encrypted descriptor record to all > participating Signers. > > =3D=3D=3D=3DSigner=3D=3D=3D=3D > > * The Signer imports the descriptor record, decrypts it by prompting the > user for TOKEN. > * The Signer calculates and verifies the descriptor=E2=80=99s CHECKSUM. A= bort the > setup if the CHECKSUM is incorrect. > * The Signer checks whether one of the KEYs in the descriptor belongs to > it, using path and fingerprint information included in the descriptor. Th= e > check must perform an exact match on the KEYs, and not using shortcuts su= ch > as matching fingerprints (which is trivial to spoof). Abort the setup if = it > doesn=E2=80=99t detect its own KEY. > * For confirmation, the Signer must display to the user the descriptor's > CHECKSUM, plus other configurations, such as M and N. The total number of > Signers, N, is important to prevent a KEY insertion attack. All > participating Signers should be able to display the same confirmation. > * If all checks pass, the Signer persists the descriptor record in its > storage. The Signer should subsequently use the descriptor to generate an= d > verify receive and change addresses. > > This completes the setup. > > =3D=3DQR Codes=3D=3D > For signers that use QR codes to transmit data, key and descriptor record= s > can be converted to QR codes, following [ > https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020= -005-ur.md > the BCR standard]. > > =3D=3DSecurity=3D=3D > > This proposal introduce two layers of protection. The first one is a > temporary, secret token, used to encrypt the two rounds of communication > between the Signers and the Coordinator. The second one is through the > descriptor checksum and visual inspection of the descriptor itself. > > The token is only needed during the setup phase, and can be safely thrown > away afterwards. The token does not guarantee that the Signer membership > set is not modified, since that depends on the overall security of all > parties in the setup, but it can make it significantly harder for an > attacker to do so. > > There are three ways an attacker can modify the membership set: by > changing an existing member, by removing an existing member, or by adding= a > new member. > > For the first two methods, one of the Signers will be able to detect that > its membership has been changed or removed, and reject the final > descriptor. Thus, it is vital that all participating Signers check that > their membership is intact in the descriptor. Even one Signer failing to > check for its membership means that the setup could be compromised. > > For the third type of attack, the descriptor checksum and visual > inspection of the descriptor itself are the only way to guard against > malicious members from being inserted into the set. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --000000000000df152b05bae3fb50 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 Coordina= tor shares the TOKEN with all participating Signers over a secure channel.<= /div>

What secure channel do you propose? Current= ly, with the default of a software wallet coordinator=C2=A0talking to hardw= are 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 t= he majority of setups will be locally done with the reasonable=C2=A0assumpt= ion 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.=C2=A0

> The second one is through the descri= ptor checksum and visual inspection of the descriptor itself.
This is a reasonable=C2=A0suggestion, although it's = worth noting that support for storing multisig setups on hardware wallets v= aries. Coldcard supports this through importing of a proprietary .txt forma= t file (which has been adopted by a number of other vendors). Trezor and Le= dger (AFAIK) do not however store multisig setups, which could make this st= ep confusing. With that said, the use of an output descriptor is certainly = a more standardised approach,=C2=A0albeit one without the wallet name inclu= ded. 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 r= ight approach. I'll link directly to the two BCR UR2.0 formats here whi= ch are relevant:

1. For sharing the sharing the BI= P44 account information from the signers to the coordinator, the crypto-acc= ount format: [https://github.co= m/BlockchainCommons/Research/blob/master/papers/bcr-2020-015-account.md= ]
2. For sharing the output descriptor from the coordinator to th= e signers, the crypto-output format: [https://github.com/BlockchainCommons/Research/blob/master/paper= s/bcr-2020-010-output-desc.md]

Craig

On Tue, Feb 9, 2021 at 9:53 AM Hugo Nguyen via b= itcoin-dev <bit= coin-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=C2=A0below a= s co-authors.

This was inspired by my own experience working with ha= rdware wallets on the market, as well as existing research into the challen= ges of multisig.

Cheers,
Hugo

<pre><= br>=C2=A0 BIP: To be determined
=C2=A0 Layer: Applications
=C2=A0 Tit= le: Bitcoin Secure Multisig Setup (BSMS)
=C2=A0 Author: Hugo Nguyen <= hugo@nunchuk.io>= ;, Peter Gray <p= eter@coinkite.com>, Marko Bencun <marko@shiftcrypto.ch>, Aaron Chen <aarondongchen@gma= il.com>, Rodolfo Novak <rodolfo@coinkite.com>
=C2=A0 Comments-Summary: N= o comments yet.
=C2=A0 Comments-URI:
=C2=A0 Status: Proposed
=C2= =A0 Type: Standards Track
=C2=A0 Created: 2020-11-10
=C2=A0 License: = BSD-2-Clause
</pre>

=3D=3DIntroduction=3D=3D

=3D=3D= =3DAbstract=3D=3D=3D

This document proposes a mechanism to set up mu= ltisig wallets securely.

=3D=3D=3DCopyright=3D=3D=3D

This BI= P is licensed under the 2-clause BSD license.

=3D=3D=3DMotivation=3D= =3D=3D

The Bitcoin multisig experience has been greatly streamlined = under [https://github.com/bitcoin/bips/blob/master/bip-01= 74.mediawiki BIP-0174 (Partially Signed Bitcoin Transaction)]. However,= what is still missing is a standardized process for setting up multisig wa= llets securely across different vendors.

There are a number of conce= rns when it comes to setting up a multisig wallet:

# Whether the mul= tisig configuration, such as Signer membership, script type, derivation pat= hs and number of signatures required, is correct and not tampered with.
= # Whether Signer persists the multisig configuration in their respective st= orage, and under what format.
# Whether Signer's storage is tamper-p= roof.
# Whether Signer subsequently uses the multisig configuration to g= enerate and verify receive and change addresses.

An attacker who can= modify the multisig configuration can steal or hold funds to ransom by dup= ing the user into sending funds to the wrong address.

This proposal = seeks to address concerns #1 and #2: to mitigate the risk of tampering duri= ng the initial setup phase, and to define an interoperable multisig configu= ration format.

Concerns #3 and #4 should be handled by Signers and i= s out of scope of this proposal.

=3D=3DSpecification=3D=3D

= =3D=3D=3DPrerequisites=3D=3D=3D
This proposal assumes the parties in the= multisig support [https://github.com/bitcoin/bips/blob/m= aster/bip-0032.mediawiki BIP32], [https://github.c= om/bitcoin/bitcoin/blob/master/doc/descriptors.md the descriptor langua= ge] and encryption.

=3D=3DRoles=3D=3D
=3D=3D=3DCoordinator=3D=3D= =3D

The Coordinator initiates the multisig setup. The Coordinator de= termines what type of multisig is used and how many members and signatures = are needed. If encryption is enabled, the Coordinator generates a secret to= ken, to be shared among the parties for secure communication. The Coordinat= or gathers information from the Signers to generate a descriptor record. Th= e Coordinator distributes the descriptor record back to the Signers.
=3D=3D=3DSigner=3D=3D=3D

The Signer is a participating member in th= e multisig. Its responsibilities include providing its XPUB to the Coordina= tor, verifying that its XPUB is included in the descriptor record and persi= sting the descriptor record in its storage.

=3D=3DSetup Process=3D= =3D

=3D=3D=3DRound 1=3D=3D=3D

=3D=3D=3D=3DCoordinator=3D=3D= =3D=3D

* The Coordinator creates a multisig wallet creation session.= The Coordinator determines the type of multisig script used and the signin= g configuration (<tt>M</tt> and <tt>N</tt>).
* I= f encryption is enabled, the Coordinator also generates a secret token, her= eby denoted <tt>TOKEN</tt>.
* TOKEN is in ASCII format and = must have a minimum of 8 characters. TOKEN should expire after some time pe= riod determined by the Coordinator, e.g., 24 hours.
* TOKEN acts as an e= ncryption key among the parties. The method of encryption is AES, CTR mode.= The encryption key can be calculated by performing a double hash operation= on the TOKEN: <tt>ENCRYPTION_KEY =3D SHA256(SHA256(TOKEN))</tt>= ;.
* A TOKEN value of <tt>-1</tt> means that encryption is d= isabled and all the encryption/decryption steps below can be skipped.
* = The Coordinator shares the TOKEN with all participating Signers over a secu= re channel.

=3D=3D=3D=3DSigner=3D=3D=3D=3D

* The Signer gener= ates a key record by prompting the user for the TOKEN and a derivation path= .
* The first line in the record must be the <tt>TOKEN</tt>.= If encryption is disabled, set the TOKEN to -1. The second line must be th= e <tt>KEY</tt>, whereas KEY is an XPUB. KEY must include key or= igin information and written in the descriptor-defined format, i.e.: <tt= >[{master key fingerprint}/{derivation path}]{XPUB}</tt>. The thir= d line must be a <tt>SIG</tt>, whereas SIG is the signature gen= erated by using the corresponding private key to sign the first two lines. = Finally, the Signer encrypts the entire record with ENCRYPTION_KEY.

= =3D=3D=3DRound 2=3D=3D=3D

=3D=3D=3D=3DCoordinator=3D=3D=3D=3D
* The Coordinator gathers key records from all participating Signers. Abor= t the setup if TOKEN has expired.
* For each key record, the Coordinator= decrypts it using ENCRYPTION_KEY. The Coordinator verifies that the includ= ed SIG is valid given the KEY.
* If all key records look good, the Coord= inator generates a descriptor record, which is simply the descriptor string= plus a <tt>CHECKSUM</tt>, all in one line. The CHECKSUM has BE= CH32 encoding and is described at [https://g= ithub.com/bitcoin/bitcoin/blob/master/doc/descriptors.md#checksums]. Th= e Coordinator encrypts this descriptor record with ENCRYPTION_KEY.
* The= Coordinator sends the encrypted descriptor record to all participating Sig= ners.

=3D=3D=3D=3DSigner=3D=3D=3D=3D

* The Signer imports the= descriptor record, decrypts it by prompting the user for TOKEN.
* The S= igner calculates and verifies the descriptor=E2=80=99s CHECKSUM. Abort the = setup if the CHECKSUM is incorrect.
* The Signer checks whether one of = the KEYs in the descriptor belongs to it, using path and fingerprint inform= ation included in the descriptor. The check must perform an exact match on = the KEYs, and not using shortcuts such as matching fingerprints (which is t= rivial to spoof). Abort the setup if it doesn=E2=80=99t detect its own KEY.=
* For confirmation, the Signer must display to the user the descriptor&= #39;s CHECKSUM, plus other configurations, such as M and N. The total numbe= r of Signers, N, is important to prevent a KEY insertion attack. All partic= ipating Signers should be able to display the same confirmation.
* If a= ll checks pass, the Signer persists the descriptor record in its storage. T= he Signer should subsequently use the descriptor to generate and verify rec= eive and change addresses.

This completes the setup.

=3D=3DQR= Codes=3D=3D
For signers that use QR codes to transmit data, key and des= criptor records can be converted to QR codes, following [https://github.com/BlockchainCommons/Research/blob/mas= ter/papers/bcr-2020-005-ur.md the BCR standard].

=3D=3DSecurity= =3D=3D

This proposal introduce two layers of protection. The first o= ne is a temporary, secret token, used to encrypt the two rounds of communic= ation between the Signers and the Coordinator. The second one is through th= e descriptor checksum and visual inspection of the descriptor itself.
The token is only needed during the setup phase, and can be safely thrown= away afterwards. The token does not guarantee that the Signer membership s= et is not modified, since that depends on the overall security of all parti= es in the setup, but it can make it significantly harder for an attacker to= do so.

There are three ways an attacker can modify the membership s= et: by changing an existing member, by removing an existing member, or by a= dding a new member.

For the first two methods, one of the Signers wi= ll be able to detect that its membership has been changed or removed, and r= eject the final descriptor. Thus, it is vital that all participating Signer= s check that their membership is intact in the descriptor. Even one Signer = failing to check for its membership means that the setup could be compromis= ed.

For the third type of attack, the descriptor checksum and visual= inspection of the descriptor itself are the only way to guard against mali= cious members from being inserted into the set.
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000df152b05bae3fb50--