path: root/90/0a364ed340de3bf9681ef1736a482077c45482

Return-Path: <hugo@nunchuk.io>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 4D618C013A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  8 Feb 2021 23:14:31 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by whitealder.osuosl.org (Postfix) with ESMTP id 350CC860D5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  8 Feb 2021 23:14:31 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id drKFmDVWBN6e
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  8 Feb 2021 23:14:29 +0000 (UTC)
X-Greylist: delayed 00:20:41 by SQLgrey-1.7.6
Received: from mail-vs1-f52.google.com (mail-vs1-f52.google.com
 [209.85.217.52])
 by whitealder.osuosl.org (Postfix) with ESMTPS id 63DA48675E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  8 Feb 2021 23:14:29 +0000 (UTC)
Received: by mail-vs1-f52.google.com with SMTP id x13so1491666vsl.8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 08 Feb 2021 15:14:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=nunchuk-io.20150623.gappssmtp.com; s=20150623;
 h=mime-version:from:date:message-id:subject:to;
 bh=Y07EwtxgvxFcDIrtGLrSzHdBlAoTLIiGLAqrs4Fqu3M=;
 b=pAlESFqpayHJvP4HMWRAH2LF9xALzHBw4JX402ttCdaYFuHzNN7ivX6P5+jVW21SMd
 aCFRNlP7Wo8dkfQ8surCVm3D0K7Pd+Ns2jpW8eumgMd0CKsVrispj2oSJ2h+CM7cxzbU
 vP4jMeTKUJoLOaB4A8dd8jUCOqsKZg0bX3Q7MKdZFPVjROxF2BPvOuf5vxLLbr2g31+/
 AVBoQNgXN3iIXzEYiQWm5YQlVcIRPH/jczZcwLCoOSvzjTphk/cNtnm4XpAQL6aTZq7x
 tqXXW9L/TTDVTDaEHyKD15txueMoXXZyIbgSiVXh9rtdqr8g6/AwuJuSemdoRXxqtYV9
 oBrw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
 bh=Y07EwtxgvxFcDIrtGLrSzHdBlAoTLIiGLAqrs4Fqu3M=;
 b=rI0tPd/pEtOU9nCDmyiyC/vStijAcQ1uhtyMsRVKvbrpMmb5kKNy1i04rqX8cAXP1i
 s1uWSaDndGcFOXNt+gF5rv2CAdgl6zAAqssCipDsmk+PwcTc+/FiPoUidGBAFWhOupew
 wJuFK+z8XYWSmN3lxS4v+6XNzICZzuZTywH5oc+orUJhxJlBaDSt5fT8hQVooRhFMt7w
 +3nd4KPxSZAAQifbUTrOgxnJHZ5DkXBDPAm13hWL5R9ja6QuotJ8ZLqyObusRZarYrIn
 W9mXskMUqyIG432mWoQW9xp/qDUgFCWRn5bEDdx/affUbC/LRYM2jvYk5gCmwaJtGS9p
 UB8w==
X-Gm-Message-State: AOAM533HJRH3GqApxLgT6YhrwV4uMwDw9zFLsGfIdRu9qLWNbvkk8iIf
 E9IpxkfcCSxV//LYr1mAX/0+em9eVyAUjuJB3vDqLvjhjtOMji3AYEX3Hg==
X-Google-Smtp-Source: ABdhPJzkFLhI0LRvxyNSE6rXEjo0R0br7drvRAqumO+j8iw366MuaCnFJxTYuLHyNJIxNgugfSPSueiFIvgtmUSvDnU=
X-Received: by 2002:a05:6102:199:: with SMTP id
 r25mr12397629vsq.5.1612826068079; 
 Mon, 08 Feb 2021 15:14:28 -0800 (PST)
MIME-Version: 1.0
From: Hugo Nguyen <hugo@nunchuk.io>
Date: Mon, 8 Feb 2021 15:14:17 -0800
Message-ID: <CAPKmR9uyY70MhmVCh=C9DeyF2Tyxibux1E_bLPo00aW_h+OjLw@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary="000000000000df673d05badb54e8"
X-Mailman-Approved-At: Tue, 09 Feb 2021 07:53:31 +0000
Subject: [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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Feb 2021 23:14:31 -0000

--000000000000df673d05badb54e8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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

<pre>
  BIP: To be determined
  Layer: Applications
  Title: Bitcoin Secure Multisig Setup (BSMS)
  Author: Hugo Nguyen <hugo@nunchuk.io>, Peter Gray <peter@coinkite.com>,
Marko Bencun <marko@shiftcrypto.ch>, Aaron Chen <aarondongchen@gmail.com>,
Rodolfo Novak <rodolfo@coinkite.com>
  Comments-Summary: No comments yet.
  Comments-URI:
  Status: Proposed
  Type: Standards Track
  Created: 2020-11-10
  License: BSD-2-Clause
</pre>

=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 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.

=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 token,
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 responsibilities
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 (<tt>M</tt> and <tt>N</tt>).
* If encryption is enabled, the Coordinator also generates a secret token,
hereby denoted <tt>TOKEN</tt>.
* 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: <tt>ENCRYPTION_KEY =3D
SHA256(SHA256(TOKEN))</tt>.
* A TOKEN value of <tt>-1</tt> 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 <tt>TOKEN</tt>. If encryption is
disabled, set the TOKEN to -1. The second line must be the <tt>KEY</tt>,
whereas KEY is an XPUB. KEY must include key origin information and written
in the descriptor-defined format, i.e.: <tt>[{master key
fingerprint}/{derivation path}]{XPUB}</tt>. The third line must be a
<tt>SIG</tt>, whereas SIG is the signature generated 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. 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 <tt>CHECKSUM</tt>, all
in one line. The CHECKSUM has BECH32 encoding and is described at [
https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md#checksums=
].
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. Abo=
rt 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. The
check must perform an exact match on the KEYs, and not using shortcuts such
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 and
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 records
can be converted to QR codes, following [
https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-0=
05-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.

--000000000000df673d05badb54e8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi all,<br>I would like to propose a new BIP for Secure Mu=
ltisig Setup.<br>This proposal has taken inputs from folks at Coldcard, Shi=
ft Crypto and Cobo -- listed=C2=A0below as co-authors.<br><br>This was insp=
ired by my own experience working with hardware wallets on the market, as w=
ell as existing research into the challenges of multisig.<br><br>Cheers,<br=
>Hugo<br><div><br></div><div>&lt;pre&gt;<br>=C2=A0 BIP: To be determined<br=
>=C2=A0 Layer: Applications<br>=C2=A0 Title: Bitcoin Secure Multisig Setup =
(BSMS)<br>=C2=A0 Author: Hugo Nguyen &lt;<a href=3D"mailto:hugo@nunchuk.io"=
>hugo@nunchuk.io</a>&gt;, Peter Gray &lt;<a href=3D"mailto:peter@coinkite.c=
om">peter@coinkite.com</a>&gt;, Marko Bencun &lt;<a href=3D"mailto:marko@sh=
iftcrypto.ch">marko@shiftcrypto.ch</a>&gt;, Aaron Chen &lt;<a href=3D"mailt=
o:aarondongchen@gmail.com">aarondongchen@gmail.com</a>&gt;, Rodolfo Novak &=
lt;<a href=3D"mailto:rodolfo@coinkite.com">rodolfo@coinkite.com</a>&gt;<br>=
=C2=A0 Comments-Summary: No comments yet.<br>=C2=A0 Comments-URI:<br>=C2=A0=
 Status: Proposed<br>=C2=A0 Type: Standards Track<br>=C2=A0 Created: 2020-1=
1-10<br>=C2=A0 License: BSD-2-Clause<br>&lt;/pre&gt;<br><br>=3D=3DIntroduct=
ion=3D=3D<br><br>=3D=3D=3DAbstract=3D=3D=3D<br><br>This document proposes a=
 mechanism to set up multisig wallets securely. <br><br>=3D=3D=3DCopyright=
=3D=3D=3D<br><br>This BIP is licensed under the 2-clause BSD license.<br><b=
r>=3D=3D=3DMotivation=3D=3D=3D<br><br>The Bitcoin multisig experience has b=
een greatly streamlined under [<a href=3D"https://github.com/bitcoin/bips/b=
lob/master/bip-0174.mediawiki">https://github.com/bitcoin/bips/blob/master/=
bip-0174.mediawiki</a> BIP-0174 (Partially Signed Bitcoin Transaction)]. Ho=
wever, what is still missing is a standardized process for setting up multi=
sig wallets securely across different vendors.<br><br>There are a number of=
 concerns when it comes to setting up a multisig wallet:<br><br># Whether t=
he multisig configuration, such as Signer membership, script type, derivati=
on paths and number of signatures required, is correct and not tampered wit=
h.<br># Whether Signer persists the multisig configuration in their respect=
ive storage, and under what format.<br># Whether Signer&#39;s storage is ta=
mper-proof.<br># Whether Signer subsequently uses the multisig configuratio=
n to generate and verify receive and change addresses.<br><br>An attacker w=
ho can modify the multisig configuration can steal or hold funds to ransom =
by duping the user into sending funds to the wrong address.<br><br>This pro=
posal seeks to address concerns #1 and #2: to mitigate the risk of tamperin=
g during the initial setup phase, and to define an interoperable multisig c=
onfiguration format.<br><br>Concerns #3 and #4 should be handled by Signers=
 and is out of scope of this proposal.<br><br>=3D=3DSpecification=3D=3D<br>=
<br>=3D=3D=3DPrerequisites=3D=3D=3D<br>This proposal assumes the parties in=
 the multisig support [<a href=3D"https://github.com/bitcoin/bips/blob/mast=
er/bip-0032.mediawiki">https://github.com/bitcoin/bips/blob/master/bip-0032=
.mediawiki</a> BIP32], [<a href=3D"https://github.com/bitcoin/bitcoin/blob/=
master/doc/descriptors.md">https://github.com/bitcoin/bitcoin/blob/master/d=
oc/descriptors.md</a> the descriptor language] and encryption.<br><br>=3D=
=3DRoles=3D=3D<br>=3D=3D=3DCoordinator=3D=3D=3D<br><br>The Coordinator init=
iates the multisig setup. The Coordinator determines what type of multisig =
is used and how many members and signatures are needed. If encryption is en=
abled, the Coordinator generates a secret token, to be shared among the par=
ties for secure communication. The Coordinator gathers information from the=
 Signers to generate a descriptor record. The Coordinator distributes the d=
escriptor record back to the Signers.<br><br>=3D=3D=3DSigner=3D=3D=3D<br><b=
r>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.<br><br>=3D=3DSetup Process=3D=3D<br><br>=3D=3D=3DRound 1=3D=3D=
=3D<br><br>=3D=3D=3D=3DCoordinator=3D=3D=3D=3D<br><br>* The Coordinator cre=
ates a multisig wallet creation session. The Coordinator determines the typ=
e of multisig script used and the signing configuration (&lt;tt&gt;M&lt;/tt=
&gt; and &lt;tt&gt;N&lt;/tt&gt;).<br>* If encryption is enabled, the Coordi=
nator also generates a secret token, hereby denoted &lt;tt&gt;TOKEN&lt;/tt&=
gt;. <br>* 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.<br>* TOKEN acts as an encryption key among the parties. Th=
e method of encryption is AES, CTR mode. The encryption key can be calculat=
ed by performing a double hash operation on the TOKEN: &lt;tt&gt;ENCRYPTION=
_KEY =3D SHA256(SHA256(TOKEN))&lt;/tt&gt;.<br>* A TOKEN value of &lt;tt&gt;=
-1&lt;/tt&gt; means that encryption is disabled and all the encryption/decr=
yption steps below can be skipped.<br>* The Coordinator shares the TOKEN wi=
th all participating Signers over a secure channel.<br><br>=3D=3D=3D=3DSign=
er=3D=3D=3D=3D<br><br>* The Signer generates a key record by prompting the =
user for the TOKEN and a derivation path.<br>* The first line in the record=
 must be the &lt;tt&gt;TOKEN&lt;/tt&gt;. If encryption is disabled, set the=
 TOKEN to -1. The second line must be the &lt;tt&gt;KEY&lt;/tt&gt;, whereas=
 KEY is an XPUB. KEY must include key origin information and written in the=
 descriptor-defined format, i.e.: &lt;tt&gt;[{master key fingerprint}/{deri=
vation path}]{XPUB}&lt;/tt&gt;. The third line must be a &lt;tt&gt;SIG&lt;/=
tt&gt;, whereas SIG is the signature generated by using the corresponding p=
rivate key to sign the first two lines. Finally, the Signer encrypts the en=
tire record with ENCRYPTION_KEY.<br><br>=3D=3D=3DRound 2=3D=3D=3D<br><br>=
=3D=3D=3D=3DCoordinator=3D=3D=3D=3D<br><br>* The Coordinator gathers key re=
cords from all participating Signers. Abort the setup if TOKEN has expired.=
<br>* For each key record, the Coordinator decrypts it using ENCRYPTION_KEY=
. The Coordinator verifies that the included SIG is valid given the KEY.<br=
>* If all key records look good, the Coordinator generates a descriptor rec=
ord, which is simply the descriptor string plus a &lt;tt&gt;CHECKSUM&lt;/tt=
&gt;, all in one line. The CHECKSUM has BECH32 encoding and is described at=
 [<a href=3D"https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors=
.md#checksums">https://github.com/bitcoin/bitcoin/blob/master/doc/descripto=
rs.md#checksums</a>]. The Coordinator encrypts this descriptor record with =
ENCRYPTION_KEY.<br>* The Coordinator sends the encrypted descriptor record =
to all participating Signers.<br><br>=3D=3D=3D=3DSigner=3D=3D=3D=3D<br><br>=
* The Signer imports the descriptor record, decrypts it by prompting the us=
er for TOKEN.<br>* The Signer calculates and verifies the descriptor=E2=80=
=99s CHECKSUM. Abort the setup if the CHECKSUM is incorrect. <br>* The Sign=
er checks whether one of the KEYs in the descriptor belongs to it, using pa=
th and fingerprint information included in the descriptor. The check must p=
erform an exact match on the KEYs, and not using shortcuts such as matching=
 fingerprints (which is trivial to spoof). Abort the setup if it doesn=E2=
=80=99t detect its own KEY.<br>* For confirmation, the Signer must display =
to the user the descriptor&#39;s CHECKSUM, plus other configurations, such =
as M and N. The total number of Signers, N, is important to prevent a KEY i=
nsertion attack. All participating Signers should be able to display the sa=
me confirmation. <br>* If all checks pass, the Signer persists the descript=
or record in its storage. The Signer should subsequently use the descriptor=
 to generate and verify receive and change addresses.<br><br>This completes=
 the setup.<br><br>=3D=3DQR Codes=3D=3D<br>For signers that use QR codes to=
 transmit data, key and descriptor records can be converted to QR codes, fo=
llowing [<a href=3D"https://github.com/BlockchainCommons/Research/blob/mast=
er/papers/bcr-2020-005-ur.md">https://github.com/BlockchainCommons/Research=
/blob/master/papers/bcr-2020-005-ur.md</a> the BCR standard].<br><br>=3D=3D=
Security=3D=3D<br><br>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 th=
rough the descriptor checksum and visual inspection of the descriptor itsel=
f.<br><br>The token is only needed during the setup phase, and can be safel=
y thrown away afterwards. The token does not guarantee that the Signer memb=
ership set is not modified, since that depends on the overall security of a=
ll parties in the setup, but it can make it significantly harder for an att=
acker to do so.<br><br>There are three ways an attacker can modify the memb=
ership set: by changing an existing member, by removing an existing member,=
 or by adding a new member.<br><br>For the first two methods, one of the Si=
gners will be able to detect that its membership has been changed or remove=
d, and reject the final descriptor. Thus, it is vital that all participatin=
g 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 c=
ompromised.<br><br>For the third type of attack, the descriptor checksum an=
d visual inspection of the descriptor itself are the only way to guard agai=
nst malicious members from being inserted into the set.<br></div></div>

--000000000000df673d05badb54e8--