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