diff options
| author | Hugo Nguyen <hugo@nunchuk.io> | 2021-04-09 07:54:11 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2021-04-09 14:54:25 +0000 |
| commit | 54b460ff712d77de2b92288fba34ae6e53c443fe (patch) | |
| tree | 7444784ed831ba526278c7897550a7cc027fd16e | |
| parent | 2e36f944fb1fe33afcfd358e915a4f451935f08c (diff) | |
| download | pi-bitcoindev-54b460ff712d77de2b92288fba34ae6e53c443fe.tar.gz pi-bitcoindev-54b460ff712d77de2b92288fba34ae6e53c443fe.zip | |
Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
| -rw-r--r-- | fe/dc135f3b30f21a6ab8b6b5d5e5153ef8062030 | 349 |
1 files changed, 349 insertions, 0 deletions
diff --git a/fe/dc135f3b30f21a6ab8b6b5d5e5153ef8062030 b/fe/dc135f3b30f21a6ab8b6b5d5e5153ef8062030 new file mode 100644 index 000000000..5575c2e02 --- /dev/null +++ b/fe/dc135f3b30f21a6ab8b6b5d5e5153ef8062030 @@ -0,0 +1,349 @@ +Return-Path: <hugo@nunchuk.io> +Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 30158C000A + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 9 Apr 2021 14:54:25 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp1.osuosl.org (Postfix) with ESMTP id 2035582FDE + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 9 Apr 2021 14:54:25 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -1.233 +X-Spam-Level: +X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 + tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, + HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, + SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no +Authentication-Results: smtp1.osuosl.org (amavisd-new); + dkim=pass (2048-bit key) header.d=nunchuk-io.20150623.gappssmtp.com +Received: from smtp1.osuosl.org ([127.0.0.1]) + by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id QWwshITgj_ob + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 9 Apr 2021 14:54:23 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.8.0 +Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com + [IPv6:2607:f8b0:4864:20::629]) + by smtp1.osuosl.org (Postfix) with ESMTPS id CC47082B2F + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 9 Apr 2021 14:54:23 +0000 (UTC) +Received: by mail-pl1-x629.google.com with SMTP id v8so2870151plz.10 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 09 Apr 2021 07:54:23 -0700 (PDT) +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=DbuJ3h9AohVcP/J94Z4cgd17RxNgCQDDSICUZe7oYTc=; + b=fV++Kn1KYrVIt+DYtnvWSz2gg1JxbzDkI9RDxAjXfXG7Std33N9w6bHZHqX6OB8ngh + qv9xDEypdAmMpR6vyAlBYaRBcDhb932E8k+AOuhe6IBCNS6u93Ytrk56S5PFZ/r+7aJ7 + tT9+Lo+kTeicTGDaKMtwohFObo2+cFK7leVGLMS/766rh673Kvzyp7wLkxonxUe1uITV + vh0KNOZgScljL6WqqPWWJw/e9JYV2lxbZmCyvuSYF363MbiEwEBc29/d75XWf6RWYdR6 + XA6I+9nkeQ6Sedm9VPtr7E2Yg55Q5DuFqnZ/jT3v0yU3dQ+qHVPRN8PJUlTgGq5IVAaS + mRUw== +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=DbuJ3h9AohVcP/J94Z4cgd17RxNgCQDDSICUZe7oYTc=; + b=RvFgzqSn8A6ineilUCM4iMxEV91LQjrsNcV51SFOoAsoBveL1q+6CBJr45Pf0zbKAx + FoGb244h/2tMI8hqRshJZ8Ktr1CF89xXwUOLJELOnHvsKkn0xhT0J55aizbw23kyYvqO + kj4lfZDWsMVKdfTIJYtu+63i7lWR/wyn4T9NzkYVxixzOdfxNgQYgwVPSEHUL57rZugS + vMVm2u46dvFu8u095de4OBCR/y1A3WKcpYb0DRDNV4lIPVXcriOMNcmnvtnTFXGOU21S + Etu+hCo0MMwXUhbusIRQ8TXKg/AkK4ipD+sckxyK75PG2XMWgAtCq3l57i+1Bba0X/k0 + dYCw== +X-Gm-Message-State: AOAM531q5ngjd+fVU8YUMYU4PD+qAXtOBMXf24KT+7fc8IueD0KT0R8F + ixNR/t1yPhvBGnoBL6aPswU5uHoezwaDCBA0kJTDxQ== +X-Google-Smtp-Source: ABdhPJxvMEVTpEyIE4LLIg/0BigesSixJi2tvMITtJB5fZJiVJ7XyCUbctYH98Rz7P39IEX/KJ5TKm3w60s5MEPsXzA= +X-Received: by 2002:a17:902:b705:b029:e6:f027:adf8 with SMTP id + d5-20020a170902b705b02900e6f027adf8mr13411473pls.72.1617980063197; Fri, 09 + Apr 2021 07:54:23 -0700 (PDT) +MIME-Version: 1.0 +References: <CAPKmR9uyY70MhmVCh=C9DeyF2Tyxibux1E_bLPo00aW_h+OjLw@mail.gmail.com> + <CAPKmR9v=RK7byF0z0hKiLiA=Zm3ZZKbu3vEiuBuzQSXFwa+izw@mail.gmail.com> + <DDAD27D6-57F5-4B39-AADB-B28E04E36D29@sprovoost.nl> +In-Reply-To: <DDAD27D6-57F5-4B39-AADB-B28E04E36D29@sprovoost.nl> +From: Hugo Nguyen <hugo@nunchuk.io> +Date: Fri, 9 Apr 2021 07:54:11 -0700 +Message-ID: <CAPKmR9u8zc3C7QmJYg-vg5jcutS07PK-0wdvpzCqMGLgnhHCBA@mail.gmail.com> +To: Sjors Provoost <sjors@sprovoost.nl> +Content-Type: multipart/alternative; boundary="000000000000ebc1f005bf8b5627" +X-Mailman-Approved-At: Fri, 09 Apr 2021 15:47:30 +0000 +Cc: marko <marko@shiftcrypto.ch>, + Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>, aarondongchen@gmail.com, + Peter Gray <peter@coinkite.com> +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: Fri, 09 Apr 2021 14:54:25 -0000 + +--000000000000ebc1f005bf8b5627 +Content-Type: text/plain; charset="UTF-8" + +(Continue off last email: also keep in mind, that just like BIP174, +Coordinator and Signer are abstract roles. This means in theory a Signer +can be the Coordinator too. The same criteria for trust applies equally to +a Signer and a Coordinator.) + +The use case I personally find most interesting is not a multi-party setup, +> but rather just combining a bunch of my own devices. Those might even be in +> the same room during the setup, only to be moved to my moon base later. +> + +And that's fair. Both use cases (local and remote multisig) are valid and +currently being used. But IMO a standard should accommodate both. + + +> To the list of concerns at the top of the BIP, I would add one: losing +> multisig setup context. E.g. in the event of a fire where you only recover +> your steel engraved mnemonic(s), but no longer have the wallet descriptors. +> + +Good point. + + +> +> If you still have all devices and know (or guess) the threshold then BIP48 +> and sorted_multi descriptors will save you. But if you have a 2-of-3 setup +> and lost 1 device then without the metadata your coins are lost. In a +> future with musig(?) and miniscript increasingly the setup data is just as +> critical as the seeds. +> + +How so? Each signer device should ideally have a copy of the multisig +configuration. If you lose 1 device in a 2-of-3, you can still spend from +the wallet? Unless I'm missing something here. + + +> A future standard (or extension of this one) should recommend an +> encryption convention for the descriptor data, ideally such that with *any* +> of the seeds you can decrypt a file that contains the full setup. That file +> could then just float redundantly around the internet and pieces of paper +> in various locations, without compromising privacy. +> + +Post-wallet-creation, each Signer can apply extra encryption on top of BSMS +for the persistence of the configuration file any way it wants :) It +doesn't contradict with the current spec. + + +> The proposed encryption system doesn't help with that though, because it's +> based on entropy from the Coordinator, rather than from the signers. +> + +They are for different purposes. The TOKEN-based encryption is only needed +temporarily for the setup. + + +> Smaller suggestions: +> * link to this new mail thread in the BIP +> + +Will do. + + +> * use magic bytes so .bsms so operating systems like Android / iOs can +> open the right app for them +> * don't use separate file extensions for encrypted vs unencrypted content, +> just indicate somehow that a given field is encrypted +> * although plain text files are handy for debugging, I think a binary +> format like PSBT is much powerful. Any device that can parse and write +> binary PSBT should be able to implement a similar parser / writer for a +> binary .bsms format. +> + +Will consider these points, but I prefer plaintext for wallet +configuration. Human readability for the wallet configuration is a pro not +a con IMO. Also helps when backing up. + + +> * BIP48 and sorted_multi descriptors are useful in a loss-of-metadata +> scenario. The BIP uses both in the examples, but doesn't explictly endorse +> these derivations. It also contradicts them: "If the Signer chooses the +> path, it should try to avoid reusing XPUBs for different wallets.". Maybe +> this is out of scope. +> * one way to resolve xpub reuse would be to make the "BIP48" path a +> function of the co-signer fingerprints and wallet threshold, but this +> requires an extra communication round +> + +We discussed this in the linked PR ( +https://github.com/nunchuk-io/bips/pull/1), and decided that enforcing +against path reuse is out-of-scope. We give examples of sorted_multi and +multi because different vendors support different things. + + +> * there should be a way for signers to communicate their capabilities, +> perhaps with a different xpub for each potential scheme. E.g. there's m/48' +> native SegWit now, MuSig and/or or Tapleaf based multisig in the future, or +> even generic Miniscript support. +> + +I considered Signers signaling capabilities (for a different reason), but +opted against it because it further complicates the scheme. Also BIP48-like +proposals are made redundant with the use of output descriptors. + + +> * the idea of only storing the receive descriptor, not the change +> descriptor, is fine by me, though I'd prefer an extension to the descriptor +> format to deal with this +> + +That's not quite accurate. The spec stores the top-level descriptor +(XPUB/*) along with the path restrictions (/0/*,/1/*), not the receive +descriptor. + + The path restrictions would allow you to extend on the spec. There's also +a VERSION field. + +Best, +Hugo + + +> +> Sjors +> +> > Op 5 apr. 2021, om 09:02 heeft Hugo Nguyen via bitcoin-dev < +> bitcoin-dev@lists.linuxfoundation.org> het volgende geschreven: +> > +> > Hi all, +> > +> > Please find below the complete draft of the Bitcoin Secure Multisig +> Setup (BSMS) BIP. The spec has gone through a number of important updates +> in the last month or so. Thanks everyone who has participated in the review +> process. +> > +> > As a PR: https://github.com/bitcoin/bips/pull/1097 +> +> + +--000000000000ebc1f005bf8b5627 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div dir=3D"ltr"><br></div>(Continue off last email: also = +keep in mind, that just like BIP174, Coordinator and Signer are abstract ro= +les. This means in theory a Signer can be the Coordinator too. The same cri= +teria for trust applies equally to a Signer and a Coordinator.)<br><br><div= + class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0p= +x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Th= +e use case I personally find most interesting is not a multi-party setup, b= +ut rather just combining a bunch of my own devices. Those might even be in = +the same room during the setup, only to be moved to my moon base later.<br>= +</blockquote><div><br>And that's fair. Both use cases (local and remote= + multisig) are valid and currently being used. But IMO a standard should ac= +commodate both.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"m= +argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left= +:1ex"> +To the list of concerns at the top of the BIP, I would add one: losing mult= +isig setup context. E.g. in the event of a fire where you only recover your= + steel engraved mnemonic(s), but no longer have the wallet descriptors.<br>= +</blockquote><div><br>Good point.<br>=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"> +<br> +If you still have all devices and know (or guess) the threshold then BIP48 = +and sorted_multi descriptors will save you. But if you have a 2-of-3 setup = +and lost 1 device then without the metadata your coins are lost. In a futur= +e with musig(?) and miniscript increasingly the setup data is just as criti= +cal as the seeds.<br></blockquote><div><br>How so? Each signer device shoul= +d ideally have a copy of the multisig configuration. If you lose 1 device i= +n a 2-of-3, you can still spend from the wallet? Unless I'm missing som= +ething here.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"marg= +in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e= +x"> +A future standard (or extension of this one) should recommend an encryption= + convention for the descriptor data, ideally such that with *any* of the se= +eds you can decrypt a file that contains the full setup. That file could th= +en just float redundantly around the internet and pieces of paper in variou= +s locations, without compromising privacy.<br></blockquote><div><br>Post-wa= +llet-creation, each Signer can apply extra encryption on top of BSMS for th= +e persistence of the configuration file any way it wants :) It doesn't = +contradict with the current spec.<br>=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"> +The proposed encryption system doesn't help with that though, because i= +t's based on entropy from the Coordinator, rather than from the signers= +.<br></blockquote><div><br>They are for different purposes. The TOKEN-based= + encryption is only needed temporarily for the setup.<br>=C2=A0<br></div><b= +lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le= +ft:1px solid rgb(204,204,204);padding-left:1ex"> +Smaller suggestions:<br> +* link to this new mail thread in the BIP<br></blockquote><div><br>Will do.= +<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0= +px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> +* use magic bytes so .bsms so operating systems like Android / iOs can open= + the right app for them<br> +* don't use separate file extensions for encrypted vs unencrypted conte= +nt, just indicate somehow that a given field is encrypted<br> +* although plain text files are handy for debugging, I think a binary forma= +t like PSBT is much powerful. Any device that can parse and write binary PS= +BT should be able to implement a similar parser / writer for a binary .bsms= + format.<br></blockquote><div><br>Will consider these points, but I prefer = +plaintext for wallet configuration. Human readability for the=C2=A0wallet c= +onfiguration is a pro not a con IMO. Also helps when backing up.<br>=C2=A0<= +/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo= +rder-left:1px solid rgb(204,204,204);padding-left:1ex"> +* BIP48 and sorted_multi descriptors are useful in a loss-of-metadata scena= +rio. The BIP uses both in the examples, but doesn't explictly endorse t= +hese derivations. It also contradicts them: "If the Signer chooses the= + path, it should try to avoid reusing XPUBs for different wallets.". M= +aybe this is out of scope.<br> +=C2=A0 =C2=A0* one way to resolve xpub reuse would be to make the "BIP= +48" path a function of the co-signer fingerprints and wallet threshold= +, but this requires an extra communication round<br></blockquote><div><br>W= +e discussed this in the linked PR (<a href=3D"https://github.com/nunchuk-io= +/bips/pull/1">https://github.com/nunchuk-io/bips/pull/1</a>), and decided t= +hat enforcing against path reuse is out-of-scope. We give examples of sorte= +d_multi and multi because different vendors support different things.<br>= +=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"> +* there should be a way for signers to communicate their capabilities, perh= +aps with a different xpub for each potential scheme. E.g. there's m/48&= +#39; native SegWit now, MuSig and/or or Tapleaf based multisig in the futur= +e, or even generic Miniscript support.<br></blockquote><div>=C2=A0</div><di= +v>I considered Signers signaling capabilities (for a different reason), but= + opted against it because it further complicates the scheme. Also BIP48-lik= +e proposals are made redundant with the use of output descriptors.<br>=C2= +=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e= +x;border-left:1px solid rgb(204,204,204);padding-left:1ex"> +* the idea of only storing the receive descriptor, not the change descripto= +r, is fine by me, though I'd prefer an extension to the descriptor form= +at to deal with this<br></blockquote><div><br>That's not quite accurate= +. The spec stores the top-level descriptor (XPUB/*) along with the path res= +trictions (/0/*,/1/*), not the receive descriptor.<br><br>=C2=A0The path re= +strictions would allow you to extend on the spec. There's also a VERSIO= +N field.<br><br>Best,<br>Hugo<br>=C2=A0</div><blockquote class=3D"gmail_quo= +te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204= +);padding-left:1ex"> +<br> +Sjors<br> +<br> +> Op 5 apr. 2021, om 09:02 heeft Hugo Nguyen via bitcoin-dev <<a href= +=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin= +-dev@lists.linuxfoundation.org</a>> het volgende geschreven:<br> +> <br> +> Hi all,<br> +> <br> +> Please find below the complete draft of the Bitcoin Secure Multisig Se= +tup (BSMS) BIP. The spec has gone through a number of important updates in = +the last month or so. Thanks everyone who has participated in the review pr= +ocess.<br> +> <br> +> As a PR: <a href=3D"https://github.com/bitcoin/bips/pull/1097" rel=3D"= +noreferrer" target=3D"_blank">https://github.com/bitcoin/bips/pull/1097</a>= +<br> +<br> +</blockquote></div></div> + +--000000000000ebc1f005bf8b5627-- + |