Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup

[Robert Spigler via bitcoin-dev]

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 
 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___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Taproot activation meeting on IRC - Tuesday 13th April 19:00 UTC

[Jeremy via bitcoin-dev]

I concur that reviewing #21377 is the best path at this time.

However, I want to draw attention to the middle road here:

If Core chooses to not release activation params (which has been discussed
as a general concept previously), #21377 can also be used to safely issue a
community release.

It's a false dichotomy between ST released by Core and a BIP8 UASF.
--
@JeremyRubin 



On Sat, Apr 10, 2021 at 9:48 AM Michael Folkson via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Bitcoin Mechanic
>
> I will attend but I will be looking at Core PR #21377 over the next
> couple of days and I would encourage other reviewers to review that PR
> too. If that PR is merged into Core I would strongly recommend any
> alternative release be fully compatible with the activation parameters
> in Core.
>
> We can discuss in the meeting what we think the cut off date should be
> for when Core should no longer be a consideration. Personally I think
> (and hope) we will see progress on #21377 in the coming days.
>
> For the sake of the mailing list Bitcoin Mechanic has set up a meeting
> to discuss an alternative release to Core with Taproot activation
> code.
>
> Thanks
> Michael
>
> > Taproot activation meeting on IRC - Tuesday 13th April 19:00 UTC
>
> > The focus of the meeting will be ratifying the Taproot activation plan
> previously discussed at the March 16th meeting (aka 2021-03 Plan Y as
> summarized here):
>
>
> https://docs.google.com/spreadsheets/d/1K3pmH09yXLTHGV3wqFZGR3ei7QVwtdEwo0PjI2NHD3w/edit#gid=0
>
> > While there was never any consensus reached on the LOT parameter, there
> appears to be consensus on BIP8 and the remaining parameters, and more than
> sufficient support for LOT=True to proceed safely.
>
> > Miners will have 18 months in which to signal and accelerate activation.
> If not, taproot will activate regardless.
>
> > With a majority of the economy running this it will guarantee eventual
> lock-in of taproot with the smallest chance of a chain split.
>
> > As a reminder, the channel is also open for ongoing discussion 24/7, and
> there is a web chat client here:
>
> > https://webchat.freenode.net/?channel=##taproot-activation
>
> > Best,
>
> > Bitcoin Mechanic
>
> > Sent with [ProtonMail](https://protonmail.com/) Secure Email.
>
>
> --
> Michael Folkson
> Email: michaelfolk...@gmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Taproot activation meeting on IRC - Tuesday 13th April 19:00 UTC

[Michael Folkson via bitcoin-dev]

Hi Bitcoin Mechanic

I will attend but I will be looking at Core PR #21377 over the next
couple of days and I would encourage other reviewers to review that PR
too. If that PR is merged into Core I would strongly recommend any
alternative release be fully compatible with the activation parameters
in Core.

We can discuss in the meeting what we think the cut off date should be
for when Core should no longer be a consideration. Personally I think
(and hope) we will see progress on #21377 in the coming days.

For the sake of the mailing list Bitcoin Mechanic has set up a meeting
to discuss an alternative release to Core with Taproot activation
code.

Thanks
Michael

> Taproot activation meeting on IRC - Tuesday 13th April 19:00 UTC

> The focus of the meeting will be ratifying the Taproot activation plan 
> previously discussed at the March 16th meeting (aka 2021-03 Plan Y as 
> summarized here):

https://docs.google.com/spreadsheets/d/1K3pmH09yXLTHGV3wqFZGR3ei7QVwtdEwo0PjI2NHD3w/edit#gid=0

> While there was never any consensus reached on the LOT parameter, there 
> appears to be consensus on BIP8 and the remaining parameters, and more than 
> sufficient support for LOT=True to proceed safely.

> Miners will have 18 months in which to signal and accelerate activation. If 
> not, taproot will activate regardless.

> With a majority of the economy running this it will guarantee eventual 
> lock-in of taproot with the smallest chance of a chain split.

> As a reminder, the channel is also open for ongoing discussion 24/7, and 
> there is a web chat client here:

> https://webchat.freenode.net/?channel=##taproot-activation

> Best,

> Bitcoin Mechanic

> Sent with [ProtonMail](https://protonmail.com/) Secure Email.


-- 
Michael Folkson
Email: michaelfolk...@gmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Update on "Speedy" Trial: The circus rolls on

[Michael Folkson via bitcoin-dev]

In my previous email in response to David Harding I said:
"I think you have consistently said it doesn't matter too much
although you did previously express a preference for block height."

This was based on:
"My preference would be for whatever solution is most preferred by
reviewers." March 7th
https://github.com/bitcoin/bitcoin/pull/21377#issuecomment-792220340

With a greater number of PR comments preferring block height at this
point I concluded that this equated to a preference for block height.
I'm happy to correct my previous statement having spoken to David.
This did not equate to a preference and David was entirely neutral.

For the sake of the mailing list (even though David didn't do so)
expressing preferences on a PR is absolutely fine. It is fine to say
"This is my preference" without NACKing a PR or NACKing a technical
decision. I (and many others) have done this. Maintainers can look
through the PR, read the rationales for the preferences and still
consider merging the PR. However, well reasoned NACKs (e.g. Concept,
Approach NACKs) make it difficult for maintainers to merge a PR
especially if they are from long term contributors. If you oscillate
from a preference one way to a full on NACK the other way to "Let's
coin flip it" with minimal rationale you are making maintainers' jobs
even more difficult. You are also wasting the time of reviewers who
don't know which PR to review and which PR stands a better chance of
being merged. You are also (unintentionally) increasing the risk of
bugs not being caught because the PR that eventually gets merged
hasn't received the review it could have.

I have been criticized on IRC for the tone of my emails. To be clear I
take Taproot activation seriously, I take the Core review process
seriously and I take keeping the community informed of the likely
timetable seriously. I'm not impressed by people wasting my time and
I'm doubly not impressed by people wasting other Core reviewers' time
and maintainers' time. If that informs my tone so be it. This is not
directed towards David who has worked hard to make progress with
Taproot activation, hasn't wasted anyone's time and I have a huge
amount of respect for.

In terms of the latest state of play with Core, there is an open Core
PR for Speedy Trial (#21377) that appears to be our best chance of
getting activation code merged into Core. The more testing and code
review this Core PR receives the better. If it continues to make
progress the discussion will then need to move onto a timetable.

On Fri, Apr 9, 2021 at 12:19 PM Michael Folkson
 wrote:
>
> I have no problem with coin tosses to decide for example shed colors
> (an illustrative example discussed by copumpkin, roasbeef on IRC). In
> this kind of example everyone should recognize it doesn't matter and
> Approach ACK two competing PRs. No one should be NACKing or Approach
> NACKing a PR based on shed color. If the maintainers don't care about
> the shed color either then they are free to use a coin toss to decide
> which PR to merge. In this example there shouldn't be any NACKs,
> Approach NACKs or technical opposition from regular Core reviewers.
> NACKs are not meant to be used for shed colors.
>
> However, in this example the organizer of the coin toss had previously
> NACKed one of the options (block height, though his position seems to
> change by the day) and others have NACKed MTP. I think you have
> consistently said it doesn't matter too much although you did
> previously express a preference for block height.
>
> I don't want to belabor the point but can we avoid even suggesting
> using coin tosses on consensus code decisions in future please? It
> makes a mockery of those who spent time understanding the technical
> considerations and have spent months or years working on soft fork
> activations. Even in the shed color example, leave it to the
> maintainers to decide whether a coin toss is appropriate rather than
> creating a circus around a coin toss in a public meeting where the PR
> authors weren't present and no Core maintainers were present.
>
> I understand the frustration and I understand the desire to break
> deadlocks. But if the coin toss organizer hadn't previously NACKed one
> of the options (block height) we may have avoided getting into this
> deadlock in the first place.
>
> Your recent review notes of PR #21377 look great and are proving very
> helpful to me as I look at the PR.
> https://gist.github.com/harding/e622323eaf80d620826a7cb74ab3fb40
>
> Thanks
> Michael
>
> On Thu, Apr 8, 2021 at 10:57 PM David A. Harding  wrote:
> >
> > On Thu, Apr 08, 2021 at 12:40:42PM +0100, Michael Folkson via bitcoin-dev 
> > wrote:
> > > So the latest circus act is apparently a technical decision made by a
> > > coin toss [organized by] Jeremy Rubin
> >
> > Actually, the coin toss was my idea[1], used a bash oneliner I wrote[2],
> > and is the same method I've been using in Bitcoin-related discussions
> > for over seven years[3] to help 

Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup

[Erik Aronesty via bitcoin-dev]

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
- multi-round DKG is used with appropriate commitments and
verification of components  (nice article:
https://link.springer.com/content/pdf/10.1007/s00145-006-0347-3.pdf)

without that, there's simply no guarantee that you're not
communicating with an attacker during setup.

On Tue, Feb 9, 2021 at 2:53 AM Hugo Nguyen via bitcoin-dev
 wrote:
>
> Hi all,
> I would like to propose a new BIP for Secure Multisig Setup.
> This proposal has taken inputs from folks at Coldcard, Shift Crypto and Cobo 
> -- listed below as co-authors.
>
> This was inspired by my own experience working with hardware wallets on the 
> market, as well as existing research into the challenges of multisig.
>
> Cheers,
> Hugo
>
> 
>   BIP: To be determined
>   Layer: Applications
>   Title: Bitcoin Secure Multisig Setup (BSMS)
>   Author: Hugo Nguyen , Peter Gray , 
> Marko Bencun , Aaron Chen , 
> Rodolfo Novak 
>   Comments-Summary: No comments yet.
>   Comments-URI:
>   Status: Proposed
>   Type: Standards Track
>   Created: 2020-11-10
>   License: BSD-2-Clause
> 
>
> ==Introduction==
>
> ===Abstract===
>
> This document proposes a mechanism to set up multisig wallets securely.
>
> ===Copyright===
>
> This BIP is licensed under the 2-clause BSD license.
>
> ===Motivation===
>
> The Bitcoin multisig experience has been greatly streamlined under 
> [https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki BIP-0174 
> (Partially Signed Bitcoin Transaction)]. However, what is still missing is a 
> standardized process for setting up multisig wallets securely across 
> different vendors.
>
> There are a number of concerns when it comes to setting up a multisig wallet:
>
> # Whether the multisig configuration, such as Signer membership, script type, 
> derivation paths and number of signatures required, is correct and not 
> tampered with.
> # Whether Signer persists the multisig configuration in their respective 
> storage, and under what format.
> # Whether Signer's storage is tamper-proof.
> # Whether Signer subsequently uses the multisig configuration to generate and 
> verify receive and change addresses.
>
> An attacker who can modify the multisig configuration can steal or hold funds 
> to ransom by duping the user into sending funds to the wrong address.
>
> This proposal seeks to address concerns #1 and #2: to mitigate the risk of 
> tampering during the initial setup phase, and to define an interoperable 
> multisig configuration format.
>
> Concerns #3 and #4 should be handled by Signers and is out of scope of this 
> proposal.
>
> ==Specification==
>
> ===Prerequisites===
> This proposal assumes the parties in the multisig support 
> [https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki BIP32], 
> [https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md the 
> descriptor language] and encryption.
>
> ==Roles==
> ===Coordinator===
>
> The Coordinator initiates the multisig setup. The Coordinator determines what 
> type of multisig is used and how many members and signatures are needed. If 
> encryption is enabled, the Coordinator generates a secret token, to be shared 
> among the parties for secure communication. The Coordinator gathers 
> information from the Signers to generate a descriptor record. The Coordinator 
> distributes the descriptor record back to the Signers.
>
> ===Signer===
>
> The Signer is a participating member in the multisig. Its responsibilities 
> include providing its XPUB to the Coordinator, verifying that its XPUB is 
> included in the descriptor record and persisting the descriptor record in its 
> storage.
>
> ==Setup Process==
>
> ===Round 1===
>
> Coordinator
>
> * The Coordinator creates a multisig wallet creation session. The Coordinator 
> determines the type of multisig script used and the signing configuration 
> (M and N).
> * If encryption is enabled, the Coordinator also generates a secret token, 
> hereby denoted TOKEN.
> * TOKEN is in ASCII format and must have a minimum of 8 characters. TOKEN 
> should expire after some time period determined by the Coordinator, e.g., 24 
> hours.
> * TOKEN acts as an encryption key among the parties. The method of encryption 
> is AES, CTR mode. The encryption key can be calculated by performing a double 
> hash operation on the TOKEN: ENCRYPTION_KEY = SHA256(SHA256(TOKEN)).
> * A TOKEN value of -1 means that encryption is disabled and all the 
> encryption/decryption steps below can be skipped.
> * The Coordinator shares the TOKEN with all participating Signers over a 
> secure channel.
>
> Signer
>
> * The Signer generates a key record by prompting the user for the TOKEN and a 
> derivation path.
> * The first line in the 

[bitcoin-dev] Taproot activation meeting on IRC - Tuesday 13th April 19:00 UTC

[BitcoinMechanic via bitcoin-dev]

Taproot activation meeting on IRC - Tuesday 13th April 19:00 UTC

The focus of the meeting will be ratifying the Taproot activation plan 
previously discussed at the March 16th meeting (aka 2021-03 Plan Y as 
summarized here):

https://docs.google.com/spreadsheets/d/1K3pmH09yXLTHGV3wqFZGR3ei7QVwtdEwo0PjI2NHD3w/edit#gid=0

While there was never any consensus reached on the LOT parameter, there appears 
to be consensus on BIP8 and the remaining parameters, and more than sufficient 
support for LOT=True to proceed safely.

Miners will have 18 months in which to signal and accelerate activation. If 
not, taproot will activate regardless.

With a majority of the economy running this it will guarantee eventual lock-in 
of taproot with the smallest chance of a chain split.

As a reminder, the channel is also open for ongoing discussion 24/7, and there 
is a web chat client here:

https://webchat.freenode.net/?channel=##taproot-activation

Best,

Bitcoin Mechanic

Sent with [ProtonMail](https://protonmail.com/) Secure Email.___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev