From: Robert Spigler <RobertSpigler@protonmail•ch>
To: Sjors Provoost <sjors@sprovoost•nl>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Cc: marko <marko@shiftcrypto•ch>,
"aarondongchen@gmail•com" <aarondongchen@gmail•com>,
Peter Gray <peter@coinkite•com>
Subject: Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
Date: Sat, 10 Apr 2021 19:32:25 +0000 [thread overview]
Message-ID: <5ATicbU2lYnPIDoWeZGXMtfpTZTWHhmt3g_xla1Ub7S6AIwReck_jZWQTsfRX-HB6v1I86gGnkkA5XLGKc7NWzsJMNCC2htbrHhVNFUFsKw=@protonmail.ch> (raw)
In-Reply-To: <FF336476-DCD2-4380-83CC-584DAF7A1D72@sprovoost.nl>
[-- Attachment #1: Type: text/plain, Size: 3021 bytes --]
Hi Sjors,
Thanks for your comments.
>Chicken-egg problem
I agree with Hugo's detailed response here.
>Losing multisig setup context (in the event of a fire where you only recover your steel engraved mnemonic(s), but no longer have the wallet descriptors.)
Devices need to persist the descriptor, if they currently can't, they don't comply with this standard and they can't be used securely for multisig. There's no reasons the master seed and descriptor both can't be backed up outside of each device. I can't see a scenario where it would be possible to recover only the seed. (I don't know yet how Core will decide how to best backup this info, seeing as BIP39 was rejected).
>BIP48
I agree with Hugo that BIP48 is redundant with descriptors, please see https://github.com/bitcoin/bips/pull/1089 for a proposed updated hierarchy for multisignature wallets.
>An encryption convention for the descriptor data
I understand this concern. Like you mentioned previously, I too often set up multisignature wallets for clients where they are actually owned by the single party. A concern is that while the backup location owners cannot spend (due to the M-of-N restriction), they can view the wallet balance/history. As Hugo mentioned, you can apply any encryption you want after the setup, so a solution may be to use Shamir Secret Sharing (Blockchain Commons has done a lot of work on that here: https://github.com/BlockchainCommons/Airgapped-Wallet-Community/discussions/37#discussioncomment-287993)
>Plain text vs binary
I too favor plain text
Robert Spigler
Personal Fingerprint: BF0D 3C08 A439 5AC6 11C1 5395 B70B 4A77 F850 548F
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, April 9, 2021 11:33 AM, Sjors Provoost via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
> Thanks for the detailed response. Just 1 thing I needed to clarify:
>
>>> 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.
>
> I was thinking about a scenario where all devices are destroyed. All you have left are the mnemonics. But indeed if at least one of your devices is still intact AND it has the configuration, you're also good.
>
> But there are plenty of devices out there that can't do this. Those devices can still be useful, even if they can't fully check everything.
>
> Sjors
[-- Attachment #2: Type: text/html, Size: 4461 bytes --]
next prev parent reply other threads:[~2021-04-10 19:32 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 [this message]
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
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='5ATicbU2lYnPIDoWeZGXMtfpTZTWHhmt3g_xla1Ub7S6AIwReck_jZWQTsfRX-HB6v1I86gGnkkA5XLGKc7NWzsJMNCC2htbrHhVNFUFsKw=@protonmail.ch' \
--to=robertspigler@protonmail$(echo .)ch \
--cc=aarondongchen@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=marko@shiftcrypto$(echo .)ch \
--cc=peter@coinkite$(echo .)com \
--cc=sjors@sprovoost$(echo .)nl \
/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