Salvatore Ingala [ARCHIVE] on Nostr: 📅 Original date posted:2021-04-12 📝 Original message:Hi Hugo, First of all, ...
📅 Original date posted:2021-04-12
📝 Original message: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). 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). 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. I think this is basically
the same flow Michael Flaxman is suggesting here:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018775.html
(Note that none of this is flow specific to Multisig wallet, as the same
flow would be unchanged for any arbitrary supported script that needs to be
"registered" on a stateless device, and can be generalized for MPC
protocols)
The only caveat I can think of is that the script registration is never
revocable if a signing key derived from the seed is used in step (2), which
might or might not be desirable. One could instead prefer to use a
different signing key that is destroyed if the device is wiped, which would
therefore need to be stored on the device. Note that the only thing that is
lost is the on-device multisig wallet registration, which could easily be
repeated from a backup.
On Sun, 11 Apr 2021 at 19:11, Hugo Nguyen via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I reiterate that I strongly disagree that going stateless is the direction
> we want to pursue when it comes to multisig.
>
> In a multisig or any type of MPC smart contract, any Signer in the
> contract must know who the other co-Signers are at all times. You can
> choose to do this verification once at setup and persist this info on the
> Signer, or you'd have to re-do the verification for every single
> transaction. There is no other choice.
>
>
Signing the descriptor record is insufficient, while also introducing a
> great deal of complexity. Here are the problems:
> 1) The signature needs to be stored somewhere. Who stores it if it's not
> the Signer itself? What if it gets lost? (If the Signer stores its own
> signature, then the scheme is no longer stateless. You might as well store
> the full descriptor).
>
In the flow I describe above, the desktop wallet would indeed store the
signed descriptor record and wallet metadata. So yes, the *Signer* as in *the
party in the protocol* stores it, but not the signing device*. *The same
method could be used to store state temporarily between round 1 and 2,
where the only *state* on the hardware wallet would be the TOKEN, while
everything else is stored (encrypted and signed) on the Signer's desktop.
> 2) When the signature is "played back" to the Signer, a copy of the
> original descriptor must be included. Who stores the descriptor? What if it
> gets lost? This is an under-appreciated aspect of the stateful approach:
> every participant in the multisig has a full copy of the original contract,
> which adds resilience to the wallet backup / recovery process.
>
"Playing back" the signature and wallet's setup data to the hardware wallet
would indeed happen transparently from the Signer's wallet software. If the
Signer lost this data due to malware, faulty hardware, etc., the user would
indeed have to recover from backup, which seems ok to me.
> 3) Because the full descriptor must be "played back" for every single
> transaction, this means every detail of the contract must be shared again
> and again, indefinitely. Not only does this add overhead (engineering and
> cognitive) to the spending process, it has massive privacy implications,
> since the descriptor contains everything you need to know about the wallets
> and its participants.
>
I agree with some of these concerns, but I observe:
- The engineering overhead in handling externally-stored-signed-data is
paid once, and would mostly fall on the hardware wallet vendor. External
software only cares about storing certain data and sending it back later.
- Storing xpubs/descriptors in the desktop software that interacts with
the HWW is already common practice, and necessary for using any watch-only
wallet.
Summarizing, I argue that the stateful/stateless characteristic of a
hardware wallet does not really affect (modulo some extra work) the ability
to participate in the BSMS ceremony, whose *Signers* should indeed be
stateful.
Some more clarifications on the trust assumptions might help at clarifying
the best possible software/hardware implementation tradeoffs, either in
this or a follow-up BIP.
Best,
Salvatore Ingala
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210412/0e23254c/attachment.html>;
📝 Original message: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). 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). 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. I think this is basically
the same flow Michael Flaxman is suggesting here:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018775.html
(Note that none of this is flow specific to Multisig wallet, as the same
flow would be unchanged for any arbitrary supported script that needs to be
"registered" on a stateless device, and can be generalized for MPC
protocols)
The only caveat I can think of is that the script registration is never
revocable if a signing key derived from the seed is used in step (2), which
might or might not be desirable. One could instead prefer to use a
different signing key that is destroyed if the device is wiped, which would
therefore need to be stored on the device. Note that the only thing that is
lost is the on-device multisig wallet registration, which could easily be
repeated from a backup.
On Sun, 11 Apr 2021 at 19:11, Hugo Nguyen via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I reiterate that I strongly disagree that going stateless is the direction
> we want to pursue when it comes to multisig.
>
> In a multisig or any type of MPC smart contract, any Signer in the
> contract must know who the other co-Signers are at all times. You can
> choose to do this verification once at setup and persist this info on the
> Signer, or you'd have to re-do the verification for every single
> transaction. There is no other choice.
>
>
Signing the descriptor record is insufficient, while also introducing a
> great deal of complexity. Here are the problems:
> 1) The signature needs to be stored somewhere. Who stores it if it's not
> the Signer itself? What if it gets lost? (If the Signer stores its own
> signature, then the scheme is no longer stateless. You might as well store
> the full descriptor).
>
In the flow I describe above, the desktop wallet would indeed store the
signed descriptor record and wallet metadata. So yes, the *Signer* as in *the
party in the protocol* stores it, but not the signing device*. *The same
method could be used to store state temporarily between round 1 and 2,
where the only *state* on the hardware wallet would be the TOKEN, while
everything else is stored (encrypted and signed) on the Signer's desktop.
> 2) When the signature is "played back" to the Signer, a copy of the
> original descriptor must be included. Who stores the descriptor? What if it
> gets lost? This is an under-appreciated aspect of the stateful approach:
> every participant in the multisig has a full copy of the original contract,
> which adds resilience to the wallet backup / recovery process.
>
"Playing back" the signature and wallet's setup data to the hardware wallet
would indeed happen transparently from the Signer's wallet software. If the
Signer lost this data due to malware, faulty hardware, etc., the user would
indeed have to recover from backup, which seems ok to me.
> 3) Because the full descriptor must be "played back" for every single
> transaction, this means every detail of the contract must be shared again
> and again, indefinitely. Not only does this add overhead (engineering and
> cognitive) to the spending process, it has massive privacy implications,
> since the descriptor contains everything you need to know about the wallets
> and its participants.
>
I agree with some of these concerns, but I observe:
- The engineering overhead in handling externally-stored-signed-data is
paid once, and would mostly fall on the hardware wallet vendor. External
software only cares about storing certain data and sending it back later.
- Storing xpubs/descriptors in the desktop software that interacts with
the HWW is already common practice, and necessary for using any watch-only
wallet.
Summarizing, I argue that the stateful/stateless characteristic of a
hardware wallet does not really affect (modulo some extra work) the ability
to participate in the BSMS ceremony, whose *Signers* should indeed be
stateful.
Some more clarifications on the trust assumptions might help at clarifying
the best possible software/hardware implementation tradeoffs, either in
this or a follow-up BIP.
Best,
Salvatore Ingala
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210412/0e23254c/attachment.html>;