From: Hugo Nguyen <hugo@nunchuk•io>
To: Salvatore Ingala <salvatore.ingala@gmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
Date: Mon, 12 Apr 2021 10:55:36 -0700 [thread overview]
Message-ID: <CAPKmR9uoA_tgz690GPAgYWM32UPkR5P2Nc_TigJZi-SiLYcFLw@mail.gmail.com> (raw)
In-Reply-To: <CAMhCMoGWGFOuPA4iTacCP3HVudg80L+-xmjzvcGjohMhwnzVtA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3902 bytes --]
Hello Salvatore,
On Mon, Apr 12, 2021 at 8:03 AM Salvatore Ingala <salvatore.ingala@gmail•com>
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
>
[-- Attachment #2: Type: text/html, Size: 5255 bytes --]
next prev parent reply other threads:[~2021-04-12 17:55 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-08 23:14 Hugo Nguyen
2021-02-09 9:33 ` Craig Raw
[not found] ` <CACrqygA1JRA293joYOxxpSepiuFD=uVvQQy3wpuosYyLQHff-A@mail.gmail.com>
2021-02-09 9:38 ` Christopher Allen
2021-02-09 10:05 ` Hugo Nguyen
[not found] ` <CACrqygDhuateDtJMBSWd9sGRu1yzrZBw2yZ75OyKD1Xmzix3Cw@mail.gmail.com>
2021-02-09 10:58 ` Hugo Nguyen
2021-02-11 13:25 ` Pavol Rusnak
2021-02-11 13:45 ` Hugo Nguyen
2021-02-11 16:29 ` Dmitry Petukhov
2021-02-11 19:11 ` Hugo Nguyen
2021-02-11 19:11 ` Hugo Nguyen
2021-02-11 22:29 ` Christopher Allen
2021-02-12 12:31 ` Hugo Nguyen
2021-02-12 13:48 ` Peter D. Gray
2021-02-12 16:55 ` Hugo Nguyen
2021-02-12 17:42 ` Dmitry Petukhov
2021-02-12 17:48 ` Dmitry Petukhov
2021-02-12 17:54 ` Hugo Nguyen
2021-02-14 10:37 ` Dmitry Petukhov
2021-02-14 11:28 ` Dmitry Petukhov
[not found] ` <CAPR5oBNWGLcnw97yPJBCgrj=EwoNdxz_RS9HM6EMpuX2-90JnQ@mail.gmail.com>
2021-02-09 9:45 ` Hugo Nguyen
2021-02-15 8:44 ` Hugo Nguyen
2021-02-15 13:53 ` Craig Raw
2021-02-15 14:19 ` Hugo Nguyen
2021-02-15 16:45 ` Hugo Nguyen
2021-04-05 7:02 ` Hugo Nguyen
2021-04-09 12:07 ` Sjors Provoost
2021-04-09 14:09 ` Hugo Nguyen
2021-04-09 14:54 ` Hugo Nguyen
2021-04-09 15:33 ` Sjors Provoost
2021-04-10 19:32 ` Robert Spigler
2021-04-11 2:34 ` Michael.flaxman
2021-04-11 16:45 ` Hugo Nguyen
2021-04-12 15:03 ` Salvatore Ingala
2021-04-12 17:55 ` Hugo Nguyen [this message]
2021-04-12 18:45 ` Christopher Allen
2021-04-12 20:43 ` Robert Spigler
2021-04-10 13:53 ` Erik Aronesty
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAPKmR9uoA_tgz690GPAgYWM32UPkR5P2Nc_TigJZi-SiLYcFLw@mail.gmail.com \
--to=hugo@nunchuk$(echo .)io \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=salvatore.ingala@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox