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 descript
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
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
i
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
h
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
- mu
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/1K3pmH09yXLTHGV3wqFZGR3ei7QVwtdE
