š
Original date posted:2021-04-12
š Original message:Hello Salvatore,
On Mon, Apr 12, 2021 at 8:03 AM Salvatore Ingala <salvatore.ingala at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210412/d2c96113/attachment-0001.html>;
Hugo Nguyen [ARCHIVE] /
npub1jqā¦5jqeg
2023-06-07 18:31:18
in reply to nevent1qā¦0xh5
Author Public Key
npub1jqxs4ftunmm8qjyw9s80hpcayewkjfhpxund29l9qvzy7xqx4duq85jqegPublished at
2023-06-07 18:31:18Event JSON
{
"id": "d29c48769ccd9e860fd25ff96f2e9a3facf85b547c13cde442070a5eb7ad087f",
"pubkey": "900d0aa57c9ef670488e2c0efb871d265d6926e13726d517e503044f1806ab78",
"created_at": 1686162678,
"kind": 1,
"tags": [
[
"e",
"bf0fd4c050cfbbd8c844e99fac16f01900b029fd5c7c4f603215207645d9024b",
"",
"root"
],
[
"e",
"c18af0aabb68dcbe7ce1c1e51288ca591be61b8fe92e59751682b3a416274fc5",
"",
"reply"
],
[
"p",
"f86db307ea15ecf745ec5b45e86abbf9755adbc7a6508dca12443cedf6718084"
]
],
"content": "š
Original date posted:2021-04-12\nš Original message:Hello Salvatore,\n\nOn Mon, Apr 12, 2021 at 8:03 AM Salvatore Ingala \u003csalvatore.ingala at gmail.com\u003e\nwrote:\n\n\u003e Hi Hugo,\n\u003e\n\u003e First of all, thank you for the impressive work on leading the\n\u003e standardization efforts!\n\u003e\n\u003e I believe one ought to more clearly distinguish the \"Signer\" (as in: one\n\u003e of the parties in the multisig setup), from the \"*Signing device*\" (which\n\u003e is likely a hardware wallet).\n\u003e\n\nActually, in the current spec, a \"Signer\" is *any software/hardware that\npossesses the private keys and can sign using those keys* -- it doesn't\nhave to be hardware. \"Signer\" does not mean the human user. I will clarify\nthe definition and clear up any ambiguous language in the spec. Thanks for\nbringing this to my attention!\n\n\n\u003e BSMS defines a \"Signer\" as \"a participating member in the multisig\",\n\u003e therefore a person/entity who is likely using both a hardware wallet and\n\u003e some BSMS-friendly software wallet (e.g. the next version of Specter\n\u003e Desktop).\n\u003e\n\nAs mentioned above, \"Signer\" does not refer to the user or any entity that\ndoes not have the private keys / signing capability.\n\n\n\u003e It is therefore relevant to discuss which parts of the BSMS mechanism are\n\u003e implemented in the Signer's software wallet, and which should be in the\n\u003e Signer's hardware wallet.\n\u003e From the discussion, it appears to me that different people might have\n\u003e different expectations on what the signing device/HWW should do, so I would\n\u003e like to comment on this point specifically (while I reckon that it mostly\n\u003e falls within the realm of concerns #4 and #5 of the motivation paragraph,\n\u003e which are explicitly left out of scope).\n\u003e\n\u003e I fully agree that a *Signer* must persist the full wallet's description,\n\u003e and should also create physical backups which include the full descriptor\n\u003e and the cosigner's information. I would disagree, however, if any standards\n\u003e were to force *hardware wallets* to persist any substantial amount of\n\u003e state other than the seed, as I believe that it gives no substantial\n\u003e advantage over externally stored signed data for many use cases.\n\u003e\n\u003e The following is the *wallet registration flow* I am currently working on\n\u003e (in the context of adding support to multisig wallets at Ledger). The goal\n\u003e is to allow a *Signer* (the person) to persist a multisig setup in its\n\u003e storage, while achieving a similar level of security you would have if you\n\u003e were storing it on the hardware wallet itself (note that the following flow\n\u003e would happen as part of Round 2):\n\u003e\n\u003e 1) The desktop wallet of the requests the HWW to register a new multisig\n\u003e wallet. The request includes the full multisig wallet description, and some\n\u003e extra metadata (e.g.: a name to be associated to this multisig wallet).\n\u003e 2) The HWW validates the wallet and verifies it with the user with the\n\u003e trusted screen (as per BSMS Round 2); on confirmation, it returns a wallet\n\u003e id (which is a vendor-specific hash of all the wallet description +\n\u003e metadata) and signature\n\u003e 3) The desktop wallet stores the full wallet description/id/signature.\n\u003e (Optionally, a backup could be stored elsewhere).\n\u003e\n\n\u003e Whenever an operation related to the multisig wallet is required\n\u003e (verifying a receiving address, or signing a spending transaction), the HWW\n\u003e first receives and verifies all the data stored at step 3 above (without\n\u003e any user interaction). Then it proceeds exactly the same way as if it had\n\u003e always stored the multisig wallet in their own storage.\n\u003e\n\nNow that we're clear on definitions, then it should become obvious that\nredefining the \"Coordinator-Signer\" pair as \"a Signer\" does not address the\nunderlying problem. (What you call \"the desktop wallet\" here is a\nCoordinator, not a Signer).\n\nAs long as the Signer does not own up the task of storing the wallet\nconfiguration, it must rely indefinitely on others for critical data when\nworking in a multisig wallet, as I have explained in my last email.\n\nBest,\nHugo\n\n\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210412/d2c96113/attachment-0001.html\u003e",
"sig": "48a7c9a9003e1f7d8aeb7dda608645457cd38ade61933368bc6c0276c480aa2a98a1adbd0f30e70821fa8c15e0da5523eaaf80fa91aa5590f0059c9d754f17f0"
}