I don't quite understand your NACK.
The following are measures you say we should take as best practices, which I
believe are all implemented:
>A) We should accept that users must to backup their multisig account maps
>(descriptor with only xpubs) along with their cosigner key material to be
Though I am ACK on that we need to solve the problem of xpub privacy and
reuse, I'm NACK on this solution. It is currently too complex and doesn't
really solve the problem.
I believe that the ultimate solution will be some form of multi-round
cryptographic commitment scheme, and as musig
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),
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
Hi Michael,
Comments inline.
On Sat, Apr 10, 2021 at 7:34 PM Michael.flaxman <
michael.flax...@protonmail.com> wrote:
> Hi Hugo,
>
> I appreciate the effort you and everyone else is making to improve
> multisig in bitcoin!
>
Thanks.
> I like that this BIP gets rid of SLIP132 version bytes, as
Hi Hugo,
I appreciate the effort you and everyone else is making to improve multisig in
bitcoin!
I like that this BIP gets rid of SLIP132 version bytes, as those have been
de-facto deprecated in favor of output descriptors for some time. Having a
standard for how to communicate descriptor
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
here's what we do for multisig:
- each member generates their own public/private key pair first and
publishes the pair to all other members
- members are then verified using a secondary channel, like a phone
call ... where the H128(pubk) is turned into BIP-words for
manual/visual verification
-
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.
(Continue off last email: also keep in mind, that just like BIP174,
Coordinator and Signer are abstract roles. This means in theory a Signer
can be the Coordinator too. The same criteria for trust applies equally to
a Signer and a Coordinator.)
The use case I personally find most interesting is
Hi Sjors
Thanks for the feedback!
The first step is for the Coordinator to generate a TOKEN, presumably using
> its own entropy. But IIUC anyone who intercepts that token can decrypt any
> future step in the setup process. This suggests a chicken-egg problem where
> you need some pre-existing
Hi all,
First of all thanks for your continued work on standardising multisig setup.
The use case I personally find most interesting is not a multi-party setup, but
rather just combining a bunch of my own devices. Those might even be in the
same room during the setup, only to be moved to my
Hi all,
Please find below the complete draft of the Bitcoin Secure Multisig Setup
(BSMS) BIP. The spec has gone through a number of important updates in the
last month or so. Thanks everyone who has participated in the review
process.
As a PR: https://github.com/bitcoin/bips/pull/1097
A few
I would also like to add 2 notes for those who are concerned about the
potential complexity that comes with encryption - which is understandable:
1. As mentioned elsewhere in the thread, I've made the encryption aspect
entirely optional. In scenarios where encryption is an overkill -- such as
Hi Craig,
Thanks for the feedback! Sharing my comments inline.
On Mon, Feb 15, 2021 at 5:53 AM Craig Raw wrote:
> Hi all,
>
> Hugo and I have discussed off-list, and I have two concerns with this
> proposal:
>
> 1. I believe adding the TOKEN and encryption to the exchange adds
> complexity to
Hi all,
Hugo and I have discussed off-list, and I have two concerns with this
proposal:
1. I believe adding the TOKEN and encryption to the exchange adds
complexity to already notoriously complex multisig, without adding much in
the way of security. This is because the shared secret (TOKEN) must
Hi all,
I have updated the proposal based on further feedback. The new spec is
included at the bottom.
I have also created a public Github PR to make it easier to comment on the
text of the spec itself: https://github.com/nunchuk-io/bips/pull/1 .
Could someone please let me know what else needs
After off-list discussion with Hugo, I'm convinced that
adding a requirement for signers to derive participant ids is
unnecessary complication that only buys slight convenience for
coordinator, and this is not a net positive tradeoff.
And since the coordinator can choose to generate unique TOKEN
I think that it is better to issue individual TOKEN for each
participant. Otherwise it will be possible for one participant to
attack another (intercept and replace their xpub sent to the
coordinator).
It will also be convenient to have a public 'participant id', derived
from the token. It can be
On Fri, Feb 12, 2021 at 9:36 AM Dmitry Petukhov wrote:
> If HUMAN_READABLE_TITLE is the additional secret, the user would need
> to enter it on the device in addition to the nonce, wouldn't it defeat
> the advantage in UX that was gained by using (relatively) short nonce ?
>
> Is 64 bit nonce
If HUMAN_READABLE_TITLE is the additional secret, the user would need
to enter it on the device in addition to the nonce, wouldn't it defeat
the advantage in UX that was gained by using (relatively) short nonce ?
Is 64 bit nonce not enough ?
It seems that to crack this with fixed Pwd and 64 bit
В Fri, 12 Feb 2021 18:42:31 +0100
Dmitry Petukhov wrote:
> Maybe for the UX it would be better to choose the number of rounds to
> use in PBKDF2, instead of using variable Pwd. Number of rounds will be
> easier to enter on the device (or just choose it from a set of
> pre-defined values). The
Thanks everyone who has provided inputs so far!
This is the new proposal for the encryption aspect of the scheme, based on
all the feedback.
The key derivation function would be PBKDF2, with PRF = SHA512. This should
be readily available on today's hardware already, as they are used for
BIP39.
Hard no to this idea:
On Thu, Feb 11, 2021 at 02:29:46PM -0800, Christopher Allen proposed:
...
> /48'/0'/0'/3'/PBKDF(complex string)'
As someone who has helped people find UTXO at key paths they didn't
know/want, this is a terrible idea. Key derivation paths should be
small, sequential
On Thu, Feb 11, 2021 at 3:05 PM Christopher Allen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> What Blockchain Commons (and the Airgapped Wallet Community) call a policy
> map would be
>
> ```
> wsh(sortedmulti(1,,,))
> ```
>
> A PBKDF of that as would be unique for all 2 of
I think the key issue here is avoiding xpub key reuse in multisig. Not only
in the future with Schnorr, but we need it today!
Current common practice by hardware wallets is the 48'/0'/0'/2' derivation
for segwit multsig ( e.g.
*BIP39 seed words list.
On Thu, Feb 11, 2021 at 11:11 AM Hugo Nguyen wrote:
> Hi Pavol,
>
> On Thu, Feb 11, 2021 at 8:25 AM Dmitry Petukhov via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> В Thu, 11 Feb 2021 05:45:33 -0800
>> Hugo Nguyen via bitcoin-dev
>> wrote:
>>
>> >
Hi Pavol,
On Thu, Feb 11, 2021 at 8:25 AM Dmitry Petukhov via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> В Thu, 11 Feb 2021 05:45:33 -0800
> Hugo Nguyen via bitcoin-dev
> wrote:
>
> > > > ENCRYPTION_KEY = SHA256(SHA256(TOKEN))
> > >
> > > This scheme might be vulnerable to
В Thu, 11 Feb 2021 05:45:33 -0800
Hugo Nguyen via bitcoin-dev
wrote:
> > > ENCRYPTION_KEY = SHA256(SHA256(TOKEN))
> >
> > This scheme might be vulnerable to rainbow table attack.
> >
>
> Thank you for pointing this out! Incidentally, Dmitry Petukhov also
> told me the same privately.
My
Hi Pavol,
On Thu, Feb 11, 2021 at 5:25 AM Pavol Rusnak wrote:
> > ENCRYPTION_KEY = SHA256(SHA256(TOKEN))
>
> This scheme might be vulnerable to rainbow table attack.
>
Thank you for pointing this out! Incidentally, Dmitry Petukhov also told me
the same privately.
>
> The following scheme
> ENCRYPTION_KEY = SHA256(SHA256(TOKEN))
This scheme might be vulnerable to rainbow table attack.
The following scheme might be more secure:
DESCRIPTION = ASCII description provided by user
NONCE = 256-bit random number
ENCRYPTION_KEY = hmac-sha256(key=NONCE, msg=DESCRIPTION)
Coordinator
Hi Craig,
Comments inline.
On Tue, Feb 9, 2021 at 1:17 AM Craig Raw wrote:
> Hi Hugo,
>
> Thanks for raising this again - I'll note there has already been much
> discussion on this topic. With respect to your "two layers of protection":
>
> > The Coordinator shares the TOKEN with all
On Tue, Feb 9, 2021 at 2:19 AM Christopher Allen <
christoph...@lifewithalacrity.com> wrote:
>
>
> On Tue, Feb 9, 2021 at 2:06 AM Hugo Nguyen wrote:
>
>>
>> I don't think reusing XPUBs inside different multisig wallets is a good
>> idea... For starters, loss of privacy in one wallet will
Hi Christopher,
Comments inline.
On Tue, Feb 9, 2021 at 1:31 AM Christopher Allen <
christoph...@lifewithalacrity.com> wrote:
> In the Airgapped Wallet Community we also have been investigating
> solutions, in particular as current common practice is is reuse the same
> xpub for all multisigs,
In the Airgapped Wallet Community we also have been investigating
solutions, in particular as current common practice is is reuse the same
xpub for all multisigs, for instance [90081696/48'/0'/0'/2']
Hi Hugo,
Thanks for raising this again - I'll note there has already been much
discussion on this topic. With respect to your "two layers of protection":
> The Coordinator shares the TOKEN with all participating Signers over a
secure channel.
What secure channel do you propose? Currently, with
36 matches
Mail list logo
