Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id D8D5FC000A for ; Mon, 12 Apr 2021 17:55:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id C7A9383CEA for ; Mon, 12 Apr 2021 17:55:49 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 1.467 X-Spam-Level: * X-Spam-Status: No, score=1.467 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 OITyBFP7SVbd for ; Mon, 12 Apr 2021 17:55:48 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) by smtp1.osuosl.org (Postfix) with ESMTPS id D13C783CE5 for ; Mon, 12 Apr 2021 17:55:48 +0000 (UTC) Received: by mail-pf1-x42c.google.com with SMTP id o123so9684438pfb.4 for ; Mon, 12 Apr 2021 10:55:48 -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=nu5LmoDBcSVr/JlHPPS5tWTarH86NIhUCKyT/kVyjFU=; b=leGvMmO9M+c0n17VPsPdvxPmylpTpxFazR3lwPMB6eC6y5Iv4haafzClM/js6msw0D HL3OZ49V4tBQO2PIL7DKfe2bPhtsf32AWj3g12gR779qKofdy7JagafOG3oBPvB8w8m9 dPchnmM47ITYo11uuzeVKhqdDNA0Fj5Z1ozQKPxagenjc+HtUtUGe4DBh3/2gUmxYumW JIWntL5qGuy/YG29I3Y/ZcRbAquMST9z4UL8jQttI/5DDVWi5Bnw3UEyCZia21vJNO0c 4iUsp/MAkM4hWYXgbcJwiQZU4RZHbDJhM1ZMKN9g1yo6CUAsRwPXnBtwakK3AnGOx9LF 5kCA== 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=nu5LmoDBcSVr/JlHPPS5tWTarH86NIhUCKyT/kVyjFU=; b=pmnn24/nKTVzULA0IhLISp0LgtNqNhsksW8356HihKxiYt9H4rxRQCaCfJjI9aSVsh CC1AGH1zXlgq1HxDC12ZrS/3lmrqsbZXq7iba/tW0k9wfX8LEqKs+x9OpoAynpybYZsi HkindYepfMEYBRH+9hmLECLPg9jvEMd9XvPpaeMBycP7I4biHVnLLjK3ENywSbRQALCe WPMmGbG2byTZk1qxuI18ZypQEZiGiBNejtyBZjqHCttOnG+0R4dM2kaMkTbKhg+c3D+L sVa1jndwZ4rnRYbA5ki5jwplj1SAd82OoxPSbF0MEl4+WnsQQ9li/GYJtccgtUsikvIr 4hLw== X-Gm-Message-State: AOAM532odoc82DCxuwfJPmYQo8eOHvhU1ukdXo2q3BaSAq/giZhmS3E1 BVgBisYpQite8jia74815YFOicxG0qubtNNNlRfKPQ== X-Google-Smtp-Source: ABdhPJxm6QLjQb33KBJGXHYpWqTDay0wDfEWcDIDhgUirGJrVYTjesfMIHLmqIcHqDlX6ykiJZsoVWZoEZf8N76Pai8= X-Received: by 2002:a63:d43:: with SMTP id 3mr28211407pgn.5.1618250148250; Mon, 12 Apr 2021 10:55:48 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Hugo Nguyen Date: Mon, 12 Apr 2021 10:55:36 -0700 Message-ID: To: Salvatore Ingala Content-Type: multipart/alternative; boundary="0000000000003e9a0a05bfca3926" X-Mailman-Approved-At: Mon, 12 Apr 2021 18:07:04 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2021 17:55:49 -0000 --0000000000003e9a0a05bfca3926 Content-Type: text/plain; charset="UTF-8" Hello Salvatore, On Mon, Apr 12, 2021 at 8:03 AM Salvatore Ingala wrote: > Hi Hugo, > > First of all, thank you for the impressive work on leading the > standardization efforts! > > I believe one ought to more clearly distinguish the "Signer" (as in: one > of the parties in the multisig setup), from the "*Signing device*" (which > is likely a hardware wallet). > Actually, in the current spec, a "Signer" is *any software/hardware that possesses the private keys and can sign using those keys* -- it doesn't have to be hardware. "Signer" does not mean the human user. I will clarify the definition and clear up any ambiguous language in the spec. Thanks for bringing this to my attention! > BSMS defines a "Signer" as "a participating member in the multisig", > therefore a person/entity who is likely using both a hardware wallet and > some BSMS-friendly software wallet (e.g. the next version of Specter > Desktop). > As mentioned above, "Signer" does not refer to the user or any entity that does not have the private keys / signing capability. > It is therefore relevant to discuss which parts of the BSMS mechanism are > implemented in the Signer's software wallet, and which should be in the > Signer's hardware wallet. > From the discussion, it appears to me that different people might have > different expectations on what the signing device/HWW should do, so I would > like to comment on this point specifically (while I reckon that it mostly > falls within the realm of concerns #4 and #5 of the motivation paragraph, > which are explicitly left out of scope). > > I fully agree that a *Signer* must persist the full wallet's description, > and should also create physical backups which include the full descriptor > and the cosigner's information. I would disagree, however, if any standards > were to force *hardware wallets* to persist any substantial amount of > state other than the seed, as I believe that it gives no substantial > advantage over externally stored signed data for many use cases. > > The following is the *wallet registration flow* I am currently working on > (in the context of adding support to multisig wallets at Ledger). The goal > is to allow a *Signer* (the person) to persist a multisig setup in its > storage, while achieving a similar level of security you would have if you > were storing it on the hardware wallet itself (note that the following flow > would happen as part of Round 2): > > 1) The desktop wallet of the requests the HWW to register a new multisig > wallet. The request includes the full multisig wallet description, and some > extra metadata (e.g.: a name to be associated to this multisig wallet). > 2) The HWW validates the wallet and verifies it with the user with the > trusted screen (as per BSMS Round 2); on confirmation, it returns a wallet > id (which is a vendor-specific hash of all the wallet description + > metadata) and signature > 3) The desktop wallet stores the full wallet description/id/signature. > (Optionally, a backup could be stored elsewhere). > > Whenever an operation related to the multisig wallet is required > (verifying a receiving address, or signing a spending transaction), the HWW > first receives and verifies all the data stored at step 3 above (without > any user interaction). Then it proceeds exactly the same way as if it had > always stored the multisig wallet in their own storage. > Now that we're clear on definitions, then it should become obvious that redefining the "Coordinator-Signer" pair as "a Signer" does not address the underlying problem. (What you call "the desktop wallet" here is a Coordinator, not a Signer). As long as the Signer does not own up the task of storing the wallet configuration, it must rely indefinitely on others for critical data when working in a multisig wallet, as I have explained in my last email. Best, Hugo > --0000000000003e9a0a05bfca3926 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello=C2=A0Salvatore,

On Mon, Apr 12, 2021= at 8:03 AM Salvatore Ingala <salvatore.ingala@gmail.com> wrote:
Hi Hugo,

=
First of all, thank=C2=A0you for the impressive work on leading = the standardization efforts!

I believe o= ne ought to more clearly distinguish the "Signer" (as in: one of = the parties in the multisig setup), from the "Signing device&qu= ot; (which is likely a hardware wallet).

Actually, in the current spec, a "Signer" is any so= ftware/hardware that possesses the private keys and can sign using those ke= ys -- it doesn't have to be hardware. "Signer" does not m= ean the human user. I will clarify the definition and clear up any ambiguou= s language in the spec. Thanks for bringing this to my attention!
=C2=A0=
BSMS defines a "Signer" as "a participating me= mber in the multisig",=C2=A0 therefore a person/entity who is likely u= sing both a hardware wallet and some BSMS-friendly software wallet (e.g. th= e next version of Specter Desktop).

As mentioned above, "Signer" does not refer to the user or= any entity that does not have the private keys / signing capability.
= =C2=A0
It is therefore relevant to discuss which parts of the B= SMS mechanism are implemented in the Signer's software wallet, and whic= h should be in the Signer's hardware wallet.
From the discuss= ion, it appears to me that different people might have different expectatio= ns on what the signing device/HWW should do, so I would like to comment on = this point specifically (while I reckon that it mostly falls within the rea= lm of concerns #4 and #5 of the motivation paragraph, which are explicitly = left out of scope).

I fully agree that a Signer= =C2=A0must persist the full wallet's description, and should also c= reate physical backups which include the full descriptor and the cosigner&#= 39;s information. I would disagree, however, if any standards were to force= hardware wallets to persist any substantial amount of state other t= han the seed, as I believe that it gives no substantial advantage over exte= rnally stored signed data for many use cases.

The following is the wallet registration=C2=A0flow I am currently = working on (in the context of adding support to multisig wallets at Ledger)= . The goal is to allow a=C2=A0Signer=C2=A0(the person) to persist a = multisig setup in its storage, while achieving a similar=C2=A0level of secu= rity you would have if you were storing it on the hardware wallet itself (n= ote that the following flow would happen as part of Round 2):
1) The desktop wallet of the requests the HWW to register a new= multisig wallet. The request includes the full multisig wallet description= , and some extra metadata (e.g.: a name to be associated to this multisig w= allet).
2) The HWW validates the wallet and verifies it with the = user with the trusted screen (as per BSMS Round 2); on confirmation, it ret= urns a wallet id (which is a vendor-specific hash of all the wallet descrip= tion=C2=A0+ metadata) and signature
3) The desktop wallet stores = the full wallet description/id/signature. (Optionally, a backup could be st= ored elsewhere).

= Whenever an operation related to the multisig wallet is required (verifying= a receiving address, or signing a spending transaction), the HWW first rec= eives and verifies all the data stored at step 3 above (without any user in= teraction). Then it proceeds exactly the same way as if it had always store= d the multisig wallet in their own storage.
<= div>
Now that we're clear on definitions, then it should become obvi= ous that redefining the "Coordinator-Signer" pair as "a Sign= er" does not address the underlying problem. (What you call "the = desktop wallet" here is a Coordinator, not a Signer).

As long a= s the Signer does not own up the task of storing the wallet configuration, = it must rely indefinitely on others for critical data when working in a mul= tisig wallet,=C2=A0as I have explained in my last email.=C2=A0

Best,=
Hugo
=C2=A0
--0000000000003e9a0a05bfca3926--