public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* Re: [bitcoin-dev] March 23rd 2021 Taproot Activation Meeting Notes
@ 2021-03-24 11:23 Michael Folkson
  2021-03-24 18:10 ` Jeremy
  0 siblings, 1 reply; 13+ messages in thread
From: Michael Folkson @ 2021-03-24 11:23 UTC (permalink / raw)
  To: jlrubin, Bitcoin Protocol Discussion

Thanks for this Jeremy. I agree with the vast majority of this.

For those that missed yesterday's meeting the meeting log is here:
http://gnusha.org/taproot-activation/2021-03-23.log

Jeremy also livestreamed the meeting on his Twitch channel:
https://www.twitch.tv/videos/960346848

On the choice between using block heights consistently or using a
weird mix of both block heights and MTP in the same activation
mechanism you can put me down for a NACK for the latter also.

In addition I documented here the preferences for a consistent use of
block height:
https://github.com/bitcoin/bitcoin/pull/21377#issuecomment-802336038

If it was a direct choice between entirely block height or entirely
MTP then I probably wouldn't NACK either. But using a mix of both
makes no sense to me.

The two arguments in favor of using a weird mix of block heights and
MTP appear to be:
1) "additional review required to ensure height based activation"
2) To prevent a "marketed push to launch a UASF client."

On 1) I would argue that the additional review required is not
excessive by any means and we have the time to review a consistent use
of block height (especially if people spent their time reviewing a PR
with a consistent use of block height rather than arguing for a mix).
On 2) if we are making technical decisions based on speculating on the
marketing strategies of other projects Bitcoin Core is a very
different project to the project I thought it was.

I personally would find it much easier to reason about timings and
time intervals of the different activation phases if block heights are
used consistently across the activation mechanism rather than a weird
mix of both block heights and MTP.

Other than that, I agree it was an excellent meeting and thanks for
your efforts organizing and hosting the meeting.

-- 
Michael Folkson
Email: michaelfolkson@gmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3


^ permalink raw reply	[flat|nested] 13+ messages in thread
* [bitcoin-dev] March 23rd 2021 Taproot Activation Meeting Notes
@ 2021-03-24  3:46 Jeremy
  2021-03-25  7:02 ` Anthony Towns
  2021-04-06  4:25 ` Rusty Russell
  0 siblings, 2 replies; 13+ messages in thread
From: Jeremy @ 2021-03-24  3:46 UTC (permalink / raw)
  To: Bitcoin development mailing list

[-- Attachment #1: Type: text/plain, Size: 3539 bytes --]

We had a very productive meeting today. Here is a summary of the meeting --
I've done my best to
summarize in an unbiased way. Thank you to everyone who attended.

1. On the use of a speedy trial variant:

- There are no new objections to speedy trial generally.
- There is desire to know if Rusty retracts or reaffirms his NACK in light
of the responses.
- There is an open question of if Rusty's NACK remains if it is
sufficiently addressed.
- There is no desire to wait for Rusty's response if he does not respond
(but please don't leave us in suspense).


2. Selecting between heights and MTP:

- There is not robust consensus on either
- There are two NACKs, one (luke-jr) against MTP, one (jeremyrubin) against
height. More on this in
 agenda item 5.
- No one has an issue with the technical safety of MTP/heights on their own.
- There is an open question of the additional review required to ensure
height based activation is
 safe.

3. Parameter Selection

- There is broad agreement that we should target something like a May 1st
release, with 1 week from rc1
 starttime/startheight, and 3 months + delta stoptime/stopheight (6
retargetting periods), and an
 activation time of around Nov 15th.
- If we select heights, it looks like the first signalling period would be
683424, the stop height
 would be 695520.
- If we select times, we should target a mid-period MTP. We can shift this
closer to release, but
 currently it looks like a 1300 UTC May 7th start time and stop time would
be 1300 UTC August 13th.
- The activation height should be 707616 (about Nov 15th) for either
proposal.

(please check my math, if anyone is superstitious we can add a day to
times...)

4. Parameter Flexibility

- We may wish to adjust the schedule a little bit -- either back 1 signal,
or up 1 signal.
- There's concurrence that regardless of pushing the start or stop dates,
we should hold the
 November 15th date steady as slipping past Thanksgiving turns to Christmas
turns to New Years
 turns to Chinese New Year and we're looking at March as the next date
people would want to
 schedule.
- There's concurrence that as long as we're getting to a release sometime
in May (with a very strong
 preference for Mid-May as opposed to End of May) that we don't need to
re-evaluate. There's
 limited belief that we could stretch this into June if needed.
- There's belief that we should be able to get a release with ST Taproot on
the timeline suggested
 by topic 3.

5. Simultaneous UASF*

- luke-jr believes that a UASF client must be able to release before the ST
client releases in
 order for people to use it
- no one else in attendance seemed to share this sentiment, a UASF can
proceed independently of ST.
- UASF is compatible with a MTP based ST by selecting whatever height the
ST MTP started at
 (and a stop height farther in the future with LOT).
- luke-jr NACK of ST MTP: ST with MTP means that UASF must release after ST
releases, which limits
 UASF adoption.
- jeremyrubin NACK of ST Height: if using height means that we'd see a
marketed push to launch a
 UASF client before ST is given a chance, ST fails its goal for avoiding
contentious forks.

* For the avoidance of doubt, theUASF client would include logic to be
compatible with ST's minimum
 activation height and may be variously called a "UASF", "BIP8 LOT=true w/
minactiveheight for ST
 compatibility", "ST + BIP8", or some other combination of phrases in
different places

Best,

Jeremy
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>

[-- Attachment #2: Type: text/html, Size: 4131 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2021-04-08 11:11 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-24 11:23 [bitcoin-dev] March 23rd 2021 Taproot Activation Meeting Notes Michael Folkson
2021-03-24 18:10 ` Jeremy
2021-03-24 19:14   ` Michael Folkson
  -- strict thread matches above, loose matches on Subject: below --
2021-03-24  3:46 Jeremy
2021-03-25  7:02 ` Anthony Towns
2021-03-25 14:30   ` Jeremy
2021-04-06  4:25 ` Rusty Russell
2021-04-07  1:20   ` Ryan Grant
2021-04-07  5:01     ` Rusty Russell
2021-04-07 13:42       ` Claus Ehrenberg
2021-04-07 15:25         ` eric
2021-04-07 17:13       ` Matt Corallo
2021-04-08 11:11       ` Anthony Towns

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox