summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorHugo Nguyen <hugo@nunchuk.io>2021-02-15 06:19:14 -0800
committerbitcoindev <bitcoindev@gnusha.org>2021-02-15 14:19:29 +0000
commitbd22b19306143f1b21894b75a1db50308148c4c4 (patch)
treeeff02f5c8b2c8f489ac2d2fe930fad9e7c02da7f
parentf688e01ea039a10bd237030ce03159a04577eebc (diff)
downloadpi-bitcoindev-bd22b19306143f1b21894b75a1db50308148c4c4.tar.gz
pi-bitcoindev-bd22b19306143f1b21894b75a1db50308148c4c4.zip
Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
-rw-r--r--e9/69da5076c3069c7c212f345f98ba3998d81bb7788
1 files changed, 788 insertions, 0 deletions
diff --git a/e9/69da5076c3069c7c212f345f98ba3998d81bb7 b/e9/69da5076c3069c7c212f345f98ba3998d81bb7
new file mode 100644
index 000000000..571d71da9
--- /dev/null
+++ b/e9/69da5076c3069c7c212f345f98ba3998d81bb7
@@ -0,0 +1,788 @@
+Return-Path: <hugo@nunchuk.io>
+Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
+ by lists.linuxfoundation.org (Postfix) with ESMTP id AA165C013A
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Mon, 15 Feb 2021 14:19:29 +0000 (UTC)
+Received: from localhost (localhost [127.0.0.1])
+ by hemlock.osuosl.org (Postfix) with ESMTP id 8565A87031
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Mon, 15 Feb 2021 14:19:29 +0000 (UTC)
+X-Virus-Scanned: amavisd-new at osuosl.org
+Received: from hemlock.osuosl.org ([127.0.0.1])
+ by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
+ with ESMTP id qFkxTMolPxK2
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Mon, 15 Feb 2021 14:19:27 +0000 (UTC)
+X-Greylist: delayed 05:34:55 by SQLgrey-1.7.6
+Received: from mail-vk1-f180.google.com (mail-vk1-f180.google.com
+ [209.85.221.180])
+ by hemlock.osuosl.org (Postfix) with ESMTPS id 0A9308702B
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Mon, 15 Feb 2021 14:19:27 +0000 (UTC)
+Received: by mail-vk1-f180.google.com with SMTP id m145so1513286vke.7
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Mon, 15 Feb 2021 06:19:26 -0800 (PST)
+DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
+ d=nunchuk-io.20150623.gappssmtp.com; s=20150623;
+ h=mime-version:references:in-reply-to:from:date:message-id:subject:to
+ :cc; bh=ncEnMX1Pql0WuFGTJxBtB7HxUSWS97Pgve8xsmZQTNs=;
+ b=eNocWxvtMP7RwdfW0t419fY5x5ZTuE4H5o38MuOMNPp1wAm5GLEj/ICIB37PTzADWZ
+ bj8u3ELjs3BsPaXHKuuLt3XJom/5Psa3tqIV2cAvOAdY2iCHjNhKvqchN/E4Ri/ZTsxm
+ 7d2T1rr3XW2TGKc1yP40wZbWnEg8NuYcNwy2UVkx6nxyzdJSt74UBrmneN/l9DKmIJm4
+ eoDwXELMi0f32/K55vEwE8P1sNOheug10S8KJpeihPiJhsFVTBaaD0OhVQE9LKDyvPRW
+ QzStPp1H36n9Isci9CcshLVl5HFeJa32NoxbnoUK0DPeSwR4Jw2s2KCEJjugq2kAaEbT
+ OBQA==
+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:cc;
+ bh=ncEnMX1Pql0WuFGTJxBtB7HxUSWS97Pgve8xsmZQTNs=;
+ b=RSGG6SJvJTY0UNaF0aTLKiAXrpKBIVSvZUUFEe/BBMpo2ghXAYV4Ckcg7L2sQvdz71
+ swi/jqNWiIP3t5jYgYsYYkyyFPbGiReg0BUFYoKipuDyhBGzDEFUM71U+EhLW01WCNcV
+ mbnbT0qfX7/f174cUsVDqcz+Ger0TQz3HHxsPlUNKWTkVv2C8UBGZRNE1psL9IRpcJRf
+ ii4eWrVgb4/WfBoTOr1jw2+4e5E+lyezHFYtF++c8xwbGZFkrAR+g6DrnpGc/YW1REZv
+ 0pXRAJ6VhMWALQnNIXpHDJNk4fkyhfSVSQ6+i3riLFxz9YOM+rJTrH3y6wWN0rP3H5Xx
+ Iupw==
+X-Gm-Message-State: AOAM533pkuVftjLPuzCz5UUhimYQEqFJ+IoMf1ZbijT2Sa5M8EatOaZI
+ NRmTL8cLkCjX4P681W4+9YavxACHrRss960H2dEkQQ==
+X-Google-Smtp-Source: ABdhPJxsyn+Rli2yGFQwui5bFRyFourD0tzlNr6DPPQ25YAtYIKbhyDV5Cqp8xHtwusHQWFt6CKkbXXF+3ineiheDPI=
+X-Received: by 2002:a05:6122:788:: with SMTP id
+ k8mr7575847vkr.23.1613398765689;
+ Mon, 15 Feb 2021 06:19:25 -0800 (PST)
+MIME-Version: 1.0
+References: <CAPKmR9uyY70MhmVCh=C9DeyF2Tyxibux1E_bLPo00aW_h+OjLw@mail.gmail.com>
+ <CAPKmR9urumKTTdBFtu-xY+RdSptOGomnJGK+sbEVnmDH=ZkBKw@mail.gmail.com>
+ <CAPR5oBPtap5Q7DUbNsjy9JxLOp82nEOnj5WA=amas1OqVot-Ew@mail.gmail.com>
+In-Reply-To: <CAPR5oBPtap5Q7DUbNsjy9JxLOp82nEOnj5WA=amas1OqVot-Ew@mail.gmail.com>
+From: Hugo Nguyen <hugo@nunchuk.io>
+Date: Mon, 15 Feb 2021 06:19:14 -0800
+Message-ID: <CAPKmR9uhuC5L9RUK3MsMrzgNezTgmHsZ6MWwaud1bcxRje0=ww@mail.gmail.com>
+To: Craig Raw <craigraw@gmail.com>
+Content-Type: multipart/alternative; boundary="000000000000500c1805bb60aca6"
+X-Mailman-Approved-At: Mon, 15 Feb 2021 15:39:15 +0000
+Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
+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 <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, 15 Feb 2021 14:19:29 -0000
+
+--000000000000500c1805bb60aca6
+Content-Type: text/plain; charset="UTF-8"
+Content-Transfer-Encoding: quoted-printable
+
+Hi Craig,
+Thanks for the feedback! Sharing my comments inline.
+
+On Mon, Feb 15, 2021 at 5:53 AM Craig Raw <craigraw@gmail.com> wrote:
+
+> Hi all,
+>
+> Hugo and I have discussed off-list, and I have two concerns with this
+> proposal:
+>
+> 1. I believe adding the TOKEN and encryption to the exchange adds
+> complexity to already notoriously complex multisig, without adding much i=
+n
+> the way of security.
+>
+
+I disagree that this doesn't add security. This proposal was inspired by a
+real vulnerability we discovered in the wild while experimenting with HWWs,
+and during that process I noticed that there is little in the way of a an
+attacker to pull off a MITM attack, where he/she can intercept and tamper
+with the multisig configuration file, potentially swapping in their own
+XPUBs. This is especially important for remote multisig setups - which is
+not common now but I imagine will be a lot more common in the future.
+
+This is because the shared secret (TOKEN) must still be shared securely,
+> and if you have established an (off-protocol) secure channel to do this,
+> why not just share the actual multisig configuration data directly in tha=
+t
+> channel?
+
+
+Because multisig is inherently an interactive process. If we can create the
+multisig configuration in one shot for everybody, you're correct that this
+is not necessary! But the fact that multisig is by nature interactive and
+requires a few rounds of communication (since it needs each Signer to
+voluntarily share its XPUB before a wallet can be created) makes this
+necessary IMO.
+
+If you are able to do so, you retain the advantage of being able to inspect
+> the data directly.
+
+
+Note that some manual inspection is still part of the proposal. But instead
+of exclusively relying on manual inspection (which is error-prone, and also
+doesn't scale very well for a large number of signers), we strengthen this
+process by automating some of the checks and making it harder to tamper
+with.
+
+
+>
+> 2. Asking the user to enter the derivation into the Signer also adds (IMO
+> unnecessary) complexity to the multisig setup process. A different way of
+> doing it, which is specified in the UR crypto-account format linked to
+> previously, has the Signer provide as many common derivations (along with
+> their xpubs) as it can support for a given BIP44 account number. This has
+> the dual advantage of making things simpler for the user (they only have =
+to
+> provide an optional account number) and increasing the standardisation on
+> common derivation paths. On receiving these derivation/xpub pairs, the
+> Coordinator can simply pick the appropriate one.
+>
+
+Note that in the updated proposal, I added the option of the Signer
+automatically filling in the derivation paths on behalf of the user (and
+also should take care not to reuse XPUBs). Perhaps this can be made the
+default behavior.
+
+Best,
+Hugo
+
+
+>
+> These concerns noted, I agree it's a good idea to have Signers save the
+> multisig configuration as proposed, and it would be great to have
+> standardisation in hww import and export formats (not just for multisig).
+> On that note, I'd love to see greater adoption of the efficient UR2.0
+> standard and associated formats for airgapped data transmission using QR
+> codes.
+>
+> Craig
+>
+>
+> On Mon, Feb 15, 2021 at 11:13 AM Hugo Nguyen via bitcoin-dev <
+> bitcoin-dev@lists.linuxfoundation.org> wrote:
+>
+>> Hi all,
+>> I have updated the proposal based on further feedback. The new spec is
+>> included at the bottom.
+>>
+>> I have also created a public Github PR to make it easier to comment on
+>> the text of the spec itself: https://github.com/nunchuk-io/bips/pull/1 .
+>>
+>> Could someone please let me know what else needs to be done before a BIP
+>> number can be assigned?
+>>
+>>
+>> =3D=3D=3D Quick summary of changes from last update =3D=3D=3D
+>>
+>> 1. Define encryption modes
+>>
+>> # NO_ENCRYPTION: Encryption is disabled.
+>> # STANDARD : the TOKEN is a 64-bit nonce.
+>> # EXTENDED : the TOKEN is a 128-bit nonce.
+>>
+>> 2. Define signature algorithm
+>>
+>> Follow BIP-0322, legacy format allowed.
+>>
+>> 3. Multiple TOKENs (optional)
+>>
+>> Also add an option where the Coordinator can choose to use one common
+>> TOKEN for all Signers, or use one per Signer.
+>>
+>> =3D=3D=3D End of summary =3D=3D=3D
+>>
+>>
+>> Cheers,
+>> Hugo
+>>
+>>
+>> <pre>
+>> BIP: To be determined
+>> Layer: Applications
+>> Title: Bitcoin Secure Multisig Setup (BSMS)
+>> Author: Hugo Nguyen <hugo at nunchuk.io>, Peter Gray <peter at
+>> coinkite.com>, Marko Bencun <marko at shiftcrypto.ch>, Pavol Rusnak <
+>> stick@satoshilabs.com>, Aaron Chen <aarondongchen at gmail.com>, Rodolfo
+>> Novak <rodolfo at 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 acros=
+s
+>> 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 generat=
+e
+>> 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 addre=
+ss.
+>>
+>> This proposal seeks to address concerns #1 and #2: to mitigate the risk
+>> of tampering during the initial setup phase, and to define an interopera=
+ble
+>> 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
+>> BIP-0032], [
+>> https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md the
+>> descriptor language] and encryption.
+>>
+>> =3D=3D=3DRoles=3D=3D=3D
+>> =3D=3D=3D=3DCoordinator=3D=3D=3D=3D
+>>
+>> 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 secr=
+ets
+>> to the parties involved for secure communication. The Coordinator gather=
+s
+>> information from the Signers to generate a descriptor record. The
+>> Coordinator distributes the descriptor record back to the Signers.
+>>
+>> =3D=3D=3D=3DSigner=3D=3D=3D=3D
+>>
+>> The Signer is a participating member in the multisig. Its
+>> responsibilities include providing its key record -- which contains an
+>> Extended Public Key (XPUB) -- to the Coordinator, verifying that its XPU=
+B
+>> is included in the descriptor record and persisting the descriptor recor=
+d
+>> in its storage.
+>>
+>> =3D=3D=3DSetup Process=3D=3D=3D
+>>
+>> =3D=3D=3D=3DRound 1=3D=3D=3D=3D
+>>
+>> =3D=3D=3D=3D=3DCoordinator=3D=3D=3D=3D=3D
+>>
+>> * The Coordinator creates a multisig wallet creation session. The
+>> Coordinator constructs the multisig script and its policy parameters, su=
+ch
+>> as the total number of signers and the required number of signatures
+>> (<tt>M</tt> and <tt>N</tt>).
+>> * The session should expire after some time period determined by the
+>> Coordinator, e.g., 24 hours.
+>> * If encryption is enabled, the Coordinator distributes a secret
+>> <tt>TOKEN</tt> to each Signer over a secure channel. The Signer can use =
+the
+>> <tt>TOKEN</tt> to derive an <tt>ENCRYPTION_KEY</tt>. Refer to the
+>> Encryption section below for details on the <tt>TOKEN</tt>, the key
+>> derivation function and the encryption scheme. Depending on the use case=
+,
+>> the Coordinator can decide whether to share one common <tt>TOKEN</tt> fo=
+r
+>> all Signers, or to have one per Signer.
+>> * If encryption is disabled, <tt>TOKEN</tt> is set to <tt>0</tt>, and al=
+l
+>> the encryption/decryption steps below can be skipped.
+>>
+>> =3D=3D=3D=3D=3DSigner=3D=3D=3D=3D=3D
+>>
+>> * The Signer initiates a new secure multisig setup session by setting th=
+e
+>> <tt>TOKEN</tt>. The Signer derives an <tt>ENCRYPTION_KEY</tt> from the
+>> <tt>TOKEN</tt>. The Signer can keep the session open until a different
+>> value for the <tt>TOKEN</tt> is set.
+>> * The Signer generates a key record by prompting the user for a multisig
+>> derivation path and retrieves the XPUB at that derivation path. Optional=
+ly,
+>> the Signer can choose a path on behalf of the user. If the Signer choose=
+s
+>> the path, it should try to avoid reusing XPUBs for different wallets.
+>> * The first line in the record must be the <tt>TOKEN</tt>. The second
+>> line must be the <tt>KEY</tt>. The <tt>KEY</tt> is an XPUB plus its key
+>> origin information, written in the descriptor-defined format, i.e.:
+>> <tt>[{master key fingerprint}/{derivation path}]{XPUB}</tt>. The third l=
+ine
+>> must be a <tt>SIG</tt>, whereas <tt>SIG</tt> is the signature generated =
+by
+>> using the private key associated with the XPUB to sign the first two
+>> lines. The signature should follow [
+>> https://github.com/bitcoin/bips/blob/master/bip-0322.mediawiki
+>> BIP-0322], legacy format accepted. Finally, the Signer encrypts the enti=
+re
+>> record with <tt>ENCRYPTION_KEY</tt>.
+>>
+>> =3D=3D=3D=3DRound 2=3D=3D=3D=3D
+>>
+>> =3D=3D=3D=3D=3DCoordinator=3D=3D=3D=3D=3D
+>>
+>> * The Coordinator gathers key records from all participating Signers.
+>> Abort the setup if the wallet setup session has expired.
+>> * For each key record, the Coordinator decrypts it using
+>> <tt>ENCRYPTION_KEY</tt>. The Coordinator verifies that the included
+>> <tt>SIG</tt> is valid given the <tt>KEY</tt>.
+>> * If all key records look good, the Coordinator fills in all necessary
+>> information to generate a descriptor record, which is simply the descrip=
+tor
+>> string plus a <tt>CHECKSUM</tt>, all in one line. The <tt>CHECKSUM</tt> =
+has
+>> [
+>> https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md#checks=
+ums
+>> BECH32 encoding].
+>> * The Coordinator encrypts this descriptor record with
+>> <tt>ENCRYPTION_KEY</tt>.
+>> * The Coordinator sends the encrypted descriptor record to all
+>> participating Signers.
+>>
+>> =3D=3D=3D=3D=3DSigner=3D=3D=3D=3D=3D
+>>
+>> * The Signer imports the descriptor record, decrypts it using the
+>> <tt>ENCRYPTION_KEY</tt> derived from the open session.
+>> * The Signer calculates and verifies the descriptor=E2=80=99s <tt>CHECKS=
+UM</tt>.
+>> Abort the setup if the <tt>CHECKSUM</tt> is incorrect.
+>> * The Signer checks whether one of the <tt>KEY</tt>s in the descriptor
+>> belongs to it, using path and fingerprint information included in the
+>> descriptor. The check must perform an exact match on the <tt>KEY</tt>s, =
+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 <tt>KEY</tt=
+>.
+>> * For confirmation, the Signer must display to the user the
+>> <tt>CHECKSUM</tt>, plus other configurations, such as <tt>M</tt> and
+>> <tt>N</tt>. The total number of Signers, <tt>N</tt>, is important to
+>> prevent a <tt>KEY</tt> insertion attack. All participating Signers shoul=
+d
+>> be able to display the same confirmation.
+>> * If all checks pass, the Signer persists the descriptor record in its
+>> storage.
+>> * The Signer can choose to further restrict post-XPUB derivation paths,
+>> such as to those defined in [
+>> https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki BIP-0044]=
+.
+>> * The Signer should subsequently use the descriptor to generate and
+>> verify receive and change addresses.
+>>
+>> This completes the setup.
+>>
+>> =3D=3D=3DEncryption=3D=3D=3D
+>>
+>> =3D=3D=3D=3DThe Token=3D=3D=3D=3D
+>> We define three modes of encryption.
+>>
+>> # <tt>NO_ENCRYPTION</tt> : the <tt>TOKEN</tt> is set to <tt>0</tt>.
+>> Encryption is disabled.
+>> # <tt>STANDARD</tt> : the <tt>TOKEN</tt> is a 64-bit nonce.
+>> # <tt>EXTENDED</tt> : the <tt>TOKEN</tt> is a 128-bit nonce.
+>>
+>> The <tt>TOKEN</tt> can be converted to one of these formats:
+>> * A mnemonic phrase using [
+>> https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki BIP-0039]
+>> word list (6 words in <tt>STANDARD</tt> mode, 12 words in <tt>EXTENDED</=
+tt>
+>> mode)
+>> * A decimal number (20 digits in <tt>STANDARD</tt> mode, 40 digits in
+>> <tt>EXTENDED</tt> mode)
+>> * A QR code
+>> * Other formats
+>>
+>> The flexibility in the data format allows each Signer to customize the
+>> User Experience based on its respective capabilities.
+>>
+>> =3D=3D=3D=3DKey Derivation=3D=3D=3D=3D
+>> The key derivation function is [https://tools.ietf.org/html/rfc2898
+>> PBKDF2], with PRF =3D SHA512. Specifically:
+>>
+>> <tt>DK =3D PBKDF2(PRF, Password, Salt, c, dkLen)</tt>
+>>
+>> Whereas:
+>>
+>> * PRF =3D <tt>SHA512</tt>
+>> * Password =3D <tt>"No SPOF"</tt>
+>> * Salt =3D <tt>TOKEN</tt>
+>> * c =3D <tt>2048</tt>
+>> * dkLen =3D <tt>256</tt>
+>> * DK =3D Derived <tt>ENCRYPTION_KEY</tt>
+>>
+>> =3D=3D=3D=3DEncryption Scheme=3D=3D=3D=3D
+>> The encryption scheme is [https://tools.ietf.org/html/rfc3686 AES, CTR
+>> mode].
+>>
+>> =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-202=
+0-005-ur.md
+>> the BCR standard].
+>>
+>> Also refer to [
+>> https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-202=
+0-015-account.md
+>> UR Type Definition for BIP44 Accounts] and [
+>> https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-202=
+0-010-output-desc.md
+>> UR Type Definition for Bitcoin Output Descriptors] for more details.
+>>
+>> =3D=3DSecurity=3D=3D
+>>
+>> This proposal introduces two layers of protection. The first one is a
+>> temporary, secret token, used to encrypt the two rounds of communication
+>> between the Signer 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 throw=
+n
+>> 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 addin=
+g a
+>> new member.
+>>
+>> For the first two methods, one of the Signers will be able to detect tha=
+t
+>> 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.
+>>
+>> =3D=3DAcknowledgement=3D=3D
+>>
+>> Special thanks to Dmitry Petukhov, Christopher Allen, Craig Raw and
+>> others for their feedback on the specification.
+>>
+>> =3D=3DReferences=3D=3D
+>>
+>> Original mailing list thread:
+>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/01=
+8385.html
+>>
+>>
+>> _______________________________________________
+>> bitcoin-dev mailing list
+>> bitcoin-dev@lists.linuxfoundation.org
+>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
+>>
+>
+
+--000000000000500c1805bb60aca6
+Content-Type: text/html; charset="UTF-8"
+Content-Transfer-Encoding: quoted-printable
+
+<div dir=3D"ltr"><div>Hi Craig,<br>Thanks for the feedback! Sharing my comm=
+ents inline.</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"=
+gmail_attr">On Mon, Feb 15, 2021 at 5:53 AM Craig Raw &lt;<a href=3D"mailto=
+:craigraw@gmail.com">craigraw@gmail.com</a>&gt; wrote:<br></div><blockquote=
+ class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
+lid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Hi all,</div><=
+div><br></div>Hugo and I have discussed off-list, and I have two concerns w=
+ith this proposal:<div><br></div><div>1. I believe adding the TOKEN and enc=
+ryption to the exchange adds complexity to already notoriously complex mult=
+isig, without adding much in the way of security. </div></div></blockquote>=
+<div><br>I disagree that this doesn&#39;t add security. This proposal was i=
+nspired by a real vulnerability we discovered in the wild while experimenti=
+ng with HWWs, and during that process I noticed that there is little in the=
+ way of a an attacker to pull off a MITM attack, where he/she can intercept=
+ and tamper with the multisig configuration file, potentially swapping in t=
+heir own XPUBs. This is especially important for remote multisig setups - w=
+hich is not common now but I imagine will be a lot more common in the futur=
+e.<br><br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
+ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">This is because=
+ the shared secret (TOKEN) must still be shared securely, and if you have e=
+stablished an (off-protocol) secure channel to do this, why not just share =
+the actual multisig configuration data directly in that channel? </blockquo=
+te></div><div><br>Because multisig is inherently an interactive process. If=
+ we can create the multisig configuration in one shot for everybody, you&#3=
+9;re correct that this is not necessary! But the fact that multisig is by n=
+ature interactive and requires a few rounds of communication (since it need=
+s each Signer to voluntarily share its=C2=A0XPUB before a wallet can be cre=
+ated) makes this necessary IMO.<br></div><div><br><blockquote class=3D"gmai=
+l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
+4,204);padding-left:1ex">If you are able to do so, you retain the advantage=
+ of being able to inspect the data directly.</blockquote><br>Note that some=
+ manual inspection is still part of the proposal. But instead of exclusivel=
+y relying on manual inspection (which is error-prone, and also doesn&#39;t =
+scale very well for a large number of signers), we strengthen this process =
+by automating some of the checks and making it harder to tamper with.</div>=
+<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
+0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
+=3D"ltr"><div><br></div><div>2. Asking the user to enter the derivation int=
+o the Signer also adds (IMO unnecessary) complexity to the multisig setup p=
+rocess. A different way of doing it, which is specified in the UR crypto-ac=
+count format linked to previously, has the Signer provide as many common de=
+rivations (along with their xpubs) as it can support for a given BIP44 acco=
+unt number. This has the dual advantage of making things simpler for the us=
+er (they only have to provide an optional account number) and increasing th=
+e standardisation on common derivation paths. On receiving these derivation=
+/xpub pairs, the Coordinator can simply pick the appropriate one.</div></di=
+v></blockquote><div><br>Note that in the updated proposal, I added the opti=
+on of the Signer automatically filling in the derivation paths on behalf of=
+ the user (and also should take care not to reuse XPUBs). Perhaps this can =
+be made the default behavior.<br><br>Best,<br>Hugo<br>=C2=A0</div><blockquo=
+te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
+solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><br></div><d=
+iv>These concerns noted, I agree it&#39;s a good idea to have Signers save =
+the multisig configuration as proposed, and it would be great to have stand=
+ardisation in hww import and export formats (not just for multisig). On tha=
+t note, I&#39;d love to see greater adoption of the efficient UR2.0 standar=
+d and associated formats for airgapped data transmission using QR codes.</d=
+iv><div><br></div><div>Craig</div><div><br></div></div><br><div class=3D"gm=
+ail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Feb 15, 2021 at 11=
+:13 AM Hugo Nguyen via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.=
+linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.or=
+g</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin=
+:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"=
+><div dir=3D"ltr"><div>Hi all,<br>I have updated the proposal based on furt=
+her feedback. The new spec is included at the bottom.</div><div><br></div><=
+div>I have also created a public Github PR to make it easier to comment on =
+the text of the spec itself:=C2=A0<a href=3D"https://github.com/nunchuk-io/=
+bips/pull/1" target=3D"_blank">https://github.com/nunchuk-io/bips/pull/1</a=
+> .<br><br>Could someone please let me know what else needs to be done befo=
+re a BIP number can be assigned?<br><br><br>=3D=3D=3D Quick summary of chan=
+ges from last update =3D=3D=3D<br><br>1. Define encryption modes<br><br># N=
+O_ENCRYPTION: Encryption is disabled.<br># STANDARD : the TOKEN is a 64-bit=
+ nonce.<br># EXTENDED : the TOKEN is a 128-bit nonce.<br><br>2. Define sign=
+ature algorithm<br><br>Follow BIP-0322, legacy format allowed.<br><br>3. Mu=
+ltiple TOKENs (optional)<br><br>Also add an option where the Coordinator ca=
+n choose to use one common TOKEN for all Signers, or use one per Signer.<br=
+><br>=3D=3D=3D End of summary =3D=3D=3D</div><div><br></div><div><br>Cheers=
+,<br>Hugo</div><div class=3D"gmail_quote"><div><br><br>&lt;pre&gt;<br>=C2=
+=A0 BIP: To be determined<br>=C2=A0 Layer: Applications<br>=C2=A0 Title: Bi=
+tcoin Secure Multisig Setup (BSMS)<br>=C2=A0 Author: Hugo Nguyen &lt;hugo a=
+t <a href=3D"http://nunchuk.io" target=3D"_blank">nunchuk.io</a>&gt;, Peter=
+ Gray &lt;peter at <a href=3D"http://coinkite.com" target=3D"_blank">coinki=
+te.com</a>&gt;, Marko Bencun &lt;marko at <a href=3D"http://shiftcrypto.ch"=
+ target=3D"_blank">shiftcrypto.ch</a>&gt;, Pavol Rusnak &lt;<a href=3D"mail=
+to:stick@satoshilabs.com" target=3D"_blank">stick@satoshilabs.com</a>&gt;, =
+Aaron Chen &lt;aarondongchen at <a href=3D"http://gmail.com" target=3D"_bla=
+nk">gmail.com</a>&gt;, Rodolfo Novak &lt;rodolfo at <a href=3D"http://coink=
+ite.com" target=3D"_blank">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-11-10<br>=C2=A0 License: =
+BSD-2-Clause<br>&lt;/pre&gt;<br><br>=3D=3DIntroduction=3D=3D<br><br>=3D=3D=
+=3DAbstract=3D=3D=3D<br><br>This document proposes a mechanism to set up mu=
+ltisig wallets securely.<br><br>=3D=3D=3DCopyright=3D=3D=3D<br><br>This BIP=
+ is licensed under the 2-clause BSD license.<br><br>=3D=3D=3DMotivation=3D=
+=3D=3D<br><br>The Bitcoin multisig experience has been greatly streamlined =
+under [<a href=3D"https://github.com/bitcoin/bips/blob/master/bip-0174.medi=
+awiki" target=3D"_blank">https://github.com/bitcoin/bips/blob/master/bip-01=
+74.mediawiki</a> BIP-0174<br>(Partially Signed Bitcoin Transaction)]. Howev=
+er, what is still missing is a standardized process for setting up multisig=
+ wallets securely across different vendors.<br><br>There are a number of co=
+ncerns when it comes to setting up a multisig wallet:<br><br># Whether the =
+multisig configuration, such as Signer membership, script type, derivation =
+paths and number of signatures required, is correct and not tampered with.<=
+br># Whether Signer persists the multisig configuration in their respective=
+ storage, and under what format.<br># Whether Signer&#39;s storage is tampe=
+r-proof.<br># Whether Signer subsequently uses the multisig configuration t=
+o generate and verify receive and change addresses.<br><br>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.<br><br>This propos=
+al seeks to address concerns #1 and #2: to mitigate the risk of tampering d=
+uring the initial setup phase, and to define an interoperable multisig conf=
+iguration format.<br><br>Concerns #3 and #4 should be handled by Signers an=
+d 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 th=
+e multisig support [<a href=3D"https://github.com/bitcoin/bips/blob/master/=
+bip-0032.mediawiki" target=3D"_blank">https://github.com/bitcoin/bips/blob/=
+master/bip-0032.mediawiki</a> BIP-0032], [<a href=3D"https://github.com/bit=
+coin/bitcoin/blob/master/doc/descriptors.md" target=3D"_blank">https://gith=
+ub.com/bitcoin/bitcoin/blob/master/doc/descriptors.md</a> the descriptor la=
+nguage] and encryption.<br><br>=3D=3D=3DRoles=3D=3D=3D<br>=3D=3D=3D=3DCoord=
+inator=3D=3D=3D=3D<br><br>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 descrip=
+tor record. The Coordinator distributes the descriptor record back to the S=
+igners.<br><br>=3D=3D=3D=3DSigner=3D=3D=3D=3D<br><br>The Signer is a partic=
+ipating member in the multisig. Its responsibilities include providing its =
+key record -- which contains an Extended Public Key (XPUB) -- to the Coordi=
+nator, verifying that its XPUB is included in the descriptor record and per=
+sisting the descriptor record in its storage.<br><br>=3D=3D=3DSetup Process=
+=3D=3D=3D<br><br>=3D=3D=3D=3DRound 1=3D=3D=3D=3D<br><br>=3D=3D=3D=3D=3DCoor=
+dinator=3D=3D=3D=3D=3D<br><br>* The Coordinator creates a multisig wallet c=
+reation session. The Coordinator constructs the multisig script and its pol=
+icy parameters, such as the total number of signers and the required number=
+ of signatures (&lt;tt&gt;M&lt;/tt&gt; and &lt;tt&gt;N&lt;/tt&gt;).<br>* Th=
+e session should expire after some time period determined by the Coordinato=
+r, e.g., 24 hours.<br>* If encryption is enabled, the Coordinator distribut=
+es a secret &lt;tt&gt;TOKEN&lt;/tt&gt; to each Signer over a secure channel=
+. The Signer can use the &lt;tt&gt;TOKEN&lt;/tt&gt; to derive an &lt;tt&gt;=
+ENCRYPTION_KEY&lt;/tt&gt;. Refer to the Encryption section below for detail=
+s on the &lt;tt&gt;TOKEN&lt;/tt&gt;, the key derivation function and the en=
+cryption scheme. Depending on the use case, the Coordinator can decide whet=
+her to share one common &lt;tt&gt;TOKEN&lt;/tt&gt; for all Signers, or to h=
+ave one per Signer.<br>* If encryption is disabled, &lt;tt&gt;TOKEN&lt;/tt&=
+gt; is set to &lt;tt&gt;0&lt;/tt&gt;, and all the encryption/decryption ste=
+ps below can be skipped.<br><br>=3D=3D=3D=3D=3DSigner=3D=3D=3D=3D=3D<br><br=
+>* The Signer initiates a new secure multisig setup session by setting the =
+&lt;tt&gt;TOKEN&lt;/tt&gt;. The Signer derives an &lt;tt&gt;ENCRYPTION_KEY&=
+lt;/tt&gt; from the &lt;tt&gt;TOKEN&lt;/tt&gt;. The Signer can keep the ses=
+sion open until a different value for the &lt;tt&gt;TOKEN&lt;/tt&gt; is set=
+.<br>* The Signer generates a key record by prompting the user for a multis=
+ig derivation path and retrieves the XPUB at that derivation path. Optional=
+ly, the Signer can choose a path on behalf of the user. If the Signer choos=
+es the path, it should try to avoid reusing XPUBs for different wallets.<br=
+>* The first line in the record must be the &lt;tt&gt;TOKEN&lt;/tt&gt;. The=
+ second line must be the &lt;tt&gt;KEY&lt;/tt&gt;. The &lt;tt&gt;KEY&lt;/tt=
+&gt; is an XPUB plus its key origin information, written in the descriptor-=
+defined format, i.e.: &lt;tt&gt;[{master key fingerprint}/{derivation path}=
+]{XPUB}&lt;/tt&gt;. The third line must be a &lt;tt&gt;SIG&lt;/tt&gt;, wher=
+eas &lt;tt&gt;SIG&lt;/tt&gt; is the signature generated by using the privat=
+e key associated with the XPUB to sign the first two lines.=C2=A0 The signa=
+ture should follow [<a href=3D"https://github.com/bitcoin/bips/blob/master/=
+bip-0322.mediawiki" target=3D"_blank">https://github.com/bitcoin/bips/blob/=
+master/bip-0322.mediawiki</a> BIP-0322], legacy format accepted. Finally, t=
+he Signer encrypts the entire record with &lt;tt&gt;ENCRYPTION_KEY&lt;/tt&g=
+t;.<br><br>=3D=3D=3D=3DRound 2=3D=3D=3D=3D<br><br>=3D=3D=3D=3D=3DCoordinato=
+r=3D=3D=3D=3D=3D<br><br>* The Coordinator gathers key records from all part=
+icipating Signers. Abort the setup if the wallet setup session has expired.=
+<br>* For each key record, the Coordinator decrypts it using &lt;tt&gt;ENCR=
+YPTION_KEY&lt;/tt&gt;. The Coordinator verifies that the included &lt;tt&gt=
+;SIG&lt;/tt&gt; is valid given the &lt;tt&gt;KEY&lt;/tt&gt;.<br>* If all ke=
+y records look good, the Coordinator fills in all necessary information to =
+generate a descriptor record, which is simply the descriptor string plus a =
+&lt;tt&gt;CHECKSUM&lt;/tt&gt;, all in one line. The &lt;tt&gt;CHECKSUM&lt;/=
+tt&gt; has [<a href=3D"https://github.com/bitcoin/bitcoin/blob/master/doc/d=
+escriptors.md#checksums" target=3D"_blank">https://github.com/bitcoin/bitco=
+in/blob/master/doc/descriptors.md#checksums</a> BECH32 encoding].<br>* The =
+Coordinator encrypts this descriptor record with &lt;tt&gt;ENCRYPTION_KEY&l=
+t;/tt&gt;.<br>* The Coordinator sends the encrypted descriptor record to al=
+l participating Signers.<br><br>=3D=3D=3D=3D=3DSigner=3D=3D=3D=3D=3D<br><br=
+>* The Signer imports the descriptor record, decrypts it using the &lt;tt&g=
+t;ENCRYPTION_KEY&lt;/tt&gt; derived from the open session.<br>* The Signer =
+calculates and verifies the descriptor=E2=80=99s &lt;tt&gt;CHECKSUM&lt;/tt&=
+gt;. Abort the setup if the &lt;tt&gt;CHECKSUM&lt;/tt&gt; is incorrect.<br>=
+* The Signer checks whether one of the &lt;tt&gt;KEY&lt;/tt&gt;s in the des=
+criptor belongs to it, using path and fingerprint information included in t=
+he descriptor. The check must perform an exact match on the &lt;tt&gt;KEY&l=
+t;/tt&gt;s, 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 &l=
+t;tt&gt;KEY&lt;/tt&gt;.<br>* For confirmation, the Signer must display to t=
+he user the &lt;tt&gt;CHECKSUM&lt;/tt&gt;, plus other configurations, such =
+as &lt;tt&gt;M&lt;/tt&gt; and &lt;tt&gt;N&lt;/tt&gt;. The total number of S=
+igners, &lt;tt&gt;N&lt;/tt&gt;, is important to prevent a &lt;tt&gt;KEY&lt;=
+/tt&gt; insertion attack. All participating Signers should be able to displ=
+ay the same confirmation.<br>* If all checks pass, the Signer persists the =
+descriptor record in its storage.<br>* The Signer can choose to further res=
+trict post-XPUB derivation paths, such as to those defined in [<a href=3D"h=
+ttps://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki" target=3D"_b=
+lank">https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki</a> BI=
+P-0044].<br>* The Signer should subsequently use the descriptor to generate=
+ and verify receive and change addresses.<br><br>This completes the setup.<=
+br><br>=3D=3D=3DEncryption=3D=3D=3D<br><br>=3D=3D=3D=3DThe Token=3D=3D=3D=
+=3D<br>We define three modes of encryption.<br><br># &lt;tt&gt;NO_ENCRYPTIO=
+N&lt;/tt&gt; : the &lt;tt&gt;TOKEN&lt;/tt&gt; is set to &lt;tt&gt;0&lt;/tt&=
+gt;. Encryption is disabled.<br># &lt;tt&gt;STANDARD&lt;/tt&gt; : the &lt;t=
+t&gt;TOKEN&lt;/tt&gt; is a 64-bit nonce.<br># &lt;tt&gt;EXTENDED&lt;/tt&gt;=
+ : the &lt;tt&gt;TOKEN&lt;/tt&gt; is a 128-bit nonce.<br><br>The &lt;tt&gt;=
+TOKEN&lt;/tt&gt; can be converted to one of these formats:<br>* A mnemonic =
+phrase using [<a href=3D"https://github.com/bitcoin/bips/blob/master/bip-00=
+39.mediawiki" target=3D"_blank">https://github.com/bitcoin/bips/blob/master=
+/bip-0039.mediawiki</a> BIP-0039] word list (6 words in &lt;tt&gt;STANDARD&=
+lt;/tt&gt; mode, 12 words in &lt;tt&gt;EXTENDED&lt;/tt&gt; mode)<br>* A dec=
+imal number (20 digits in &lt;tt&gt;STANDARD&lt;/tt&gt; mode, 40 digits in =
+&lt;tt&gt;EXTENDED&lt;/tt&gt; mode)<br>* A QR code<br>* Other formats<br><b=
+r>The flexibility in the data format allows each Signer to customize the Us=
+er Experience based on its respective capabilities.<br><br>=3D=3D=3D=3DKey =
+Derivation=3D=3D=3D=3D<br>The key derivation function is [<a href=3D"https:=
+//tools.ietf.org/html/rfc2898" target=3D"_blank">https://tools.ietf.org/htm=
+l/rfc2898</a> PBKDF2], with PRF =3D SHA512. Specifically:<br><br>&lt;tt&gt;=
+DK =3D PBKDF2(PRF, Password, Salt, c, dkLen)&lt;/tt&gt;<br><br>Whereas:<br>=
+<br>* PRF =3D &lt;tt&gt;SHA512&lt;/tt&gt;<br>* Password =3D &lt;tt&gt;&quot=
+;No SPOF&quot;&lt;/tt&gt;<br>* Salt =3D &lt;tt&gt;TOKEN&lt;/tt&gt;<br>* c =
+=3D &lt;tt&gt;2048&lt;/tt&gt;<br>* dkLen =3D &lt;tt&gt;256&lt;/tt&gt;<br>* =
+DK =3D Derived &lt;tt&gt;ENCRYPTION_KEY&lt;/tt&gt;<br><br>=3D=3D=3D=3DEncry=
+ption Scheme=3D=3D=3D=3D<br>The encryption scheme is [<a href=3D"https://to=
+ols.ietf.org/html/rfc3686" target=3D"_blank">https://tools.ietf.org/html/rf=
+c3686</a> AES, CTR mode].<br><br>=3D=3DQR Codes=3D=3D<br>For signers that u=
+se QR codes to transmit data, key and descriptor records can be converted t=
+o QR codes, following [<a href=3D"https://github.com/BlockchainCommons/Rese=
+arch/blob/master/papers/bcr-2020-005-ur.md" target=3D"_blank">https://githu=
+b.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-005-ur.md</a> =
+the BCR standard].<br><br>Also refer to [<a href=3D"https://github.com/Bloc=
+kchainCommons/Research/blob/master/papers/bcr-2020-015-account.md" target=
+=3D"_blank">https://github.com/BlockchainCommons/Research/blob/master/paper=
+s/bcr-2020-015-account.md</a> UR Type Definition for BIP44 Accounts] and [<=
+a href=3D"https://github.com/BlockchainCommons/Research/blob/master/papers/=
+bcr-2020-010-output-desc.md" target=3D"_blank">https://github.com/Blockchai=
+nCommons/Research/blob/master/papers/bcr-2020-010-output-desc.md</a> UR Typ=
+e Definition for Bitcoin Output Descriptors] for more details.<br><br>=3D=
+=3DSecurity=3D=3D<br><br>This proposal introduces two layers of protection.=
+ The first one is a temporary, secret token, used to encrypt the two rounds=
+ of communication between the Signer and the Coordinator. The second one is=
+ through the descriptor checksum and visual inspection of the descriptor it=
+self.<br><br>The token is only needed during the setup phase, and can be sa=
+fely thrown away afterwards. The token does not guarantee that the Signer m=
+embership set is not modified, since that depends on the overall security o=
+f all parties in the setup, but it can make it significantly harder for an =
+attacker to do so.<br><br>There are three ways an attacker can modify the m=
+embership set: by changing an existing member, by removing an existing memb=
+er, or by adding a new member.<br><br>For the first two methods, one of the=
+ Signers will be able to detect that its membership has been changed or rem=
+oved, and reject the final descriptor. Thus, it is vital that all participa=
+ting Signers check that their membership is intact in the descriptor. Even =
+one Signer failing to check for its membership means that the setup could b=
+e compromised.<br><br>For the third type of attack, the descriptor checksum=
+ and visual inspection of the descriptor itself are the only way to guard a=
+gainst malicious members from being inserted into the set.<br><br>=3D=3DAck=
+nowledgement=3D=3D<br><br>Special thanks to Dmitry Petukhov, Christopher Al=
+len, Craig Raw and others for their feedback on the specification.<br><br>=
+=3D=3DReferences=3D=3D<br><br>Original mailing list thread: <a href=3D"http=
+s://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018385.ht=
+ml" target=3D"_blank">https://lists.linuxfoundation.org/pipermail/bitcoin-d=
+ev/2021-February/018385.html</a><br><br>=C2=A0</div></div></div>
+_______________________________________________<br>
+bitcoin-dev mailing list<br>
+<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
+bitcoin-dev@lists.linuxfoundation.org</a><br>
+<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
+rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
+man/listinfo/bitcoin-dev</a><br>
+</blockquote></div>
+</blockquote></div></div>
+
+--000000000000500c1805bb60aca6--
+