Re: [bitcoin-dev] (Recurring) Taproot activation meeting on IRC - Tuesday 23rd March 19:00 UTC + every fortnight

Re: [bitcoin-dev] (Recurring) Taproot activation meeting on IRC - Tuesday 23rd March 19:00 UTC + every fortnight

[Michael Folkson]

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

Thanks for organizing this Jeremy, agenda looks great. I do think we are
now at the time where Taproot activation becomes a priority for all those
with a stake in Taproot activation.

Although these parameters haven't yet been finalized the proposed
(approximate) startheight is May 1st which is less than 6 weeks away.

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018594.html

Therefore I encourage everyone with a stake in Taproot activation to attend
this meeting tomorrow (Tuesday 19:00 UTC) and raise any specific concerns
with block height vs MTP and proposed timetables as Jeremy suggests before
the meeting.

Personally I think we should avoid the min activation height dragging into
December. November (current proposed is November 13th) seems ideal as to
avoid (admittedly Western) holidays in December and January. Other than
that I think we have some (limited) wiggle room with regards to the exact
timetable to ensure the optimal code is merged.

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

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

[bitcoin-dev] (Recurring) Taproot activation meeting on IRC - Tuesday 23rd March 19:00 UTC + every fortnight

[Jeremy]

[-- Attachment #1.1: Type: text/plain, Size: 5149 bytes --]

In response to the previous Taproot Activation Meeting, I noted that the
advance notice was insufficient and proposed having the proposed meeting
the following week, to consider the meeting last week as a "discussion",
and thereafter reserving a meeting slot fortnightly reserved. I've been
asked/volunteered in the ##taproot-activation IRC channel on freenode to
announce, assemble an agenda, and host this meeting. *If you plan to attend
please read the entire email as there are some specific instructions for
participation that have differed from past meetings.*

I've attached an ICS file with scheduling this meeting for 10 repetitions
for your convenience. Subsequent meetings will hopefully be unnecessary,
but scheduling them in advance helps ensure a process that respects all
parties desire to participate.

The purpose of this meeting is to serve as a checkpoint to raise any
blocking issues and to attempt to finalize parameter selection. As such,
I've attempted to make a guided agenda that should move towards
finalization rather than continuation of debate and makes the best use of
everyone's time. If there are topics missing or if I didn't accurately
capture the zeitgeist of discussion, please chime in with suggested changes
to the agenda.

If you cannot attend the meeting you may per-register a comment by replying
to this email. You may also pre-register a comment here for any reason for
ease of reference during the meeting, but it is not required. So that we
can keep the meeting focused and adjust agenda accordingly, I'll also
request explicitly that certain categories of comment described below be
pre-registered. Please keep this thread limited to pre-registered comments
rather than responses to such comments, which will be addressed in the
meeting.

For the meeting this coming Tuesday the plan is to attempt to finalize on:

1. Resolving any outstanding concerns around using a Speedy Trial to
attempt to activate Taproot that must be addressed.

There seems to be diverse consensus on ST, as per
https://gist.github.com/michaelfolkson/92899f27f1ab30aa2ebee82314f8fe7f#gistcomment-3668460
.

*As such, please pre-register any concern about any ST variant at all by
responding below.*

2. Selecting between start/stop heights and times for a speedy trial.

See https://github.com/bitcoin/bitcoin/pull/21377
https://github.com/bitcoin/bitcoin/pull/21392.

The focus of this discussion should be focused on blocking reasons to not
use time based parameters, the code review process, and timelines for being
able to utilize either activation method.

It is already a widely acknowledged preference for heights over times from
a blank slate pure technical point of view, this discussion is intended to
be more pragmatic about safety, hitting the timelines we want to, and
shipping code.

*As such, If you wish to advocate for MTP from a blank slate pure technical
point of view, please pre-register a comment below so we can adjust the
agenda ahead of time. *

3. Parameter Selection for start/stop/active points.

Short of resolving height or time based start/stop, a discussion of
selecting acceptable parameters. We should get agreement on both sets of
height or time parameters irrespective of the resolution to 2, so that this
conversation can proceed independently.

My personal pre-meeting suggestion to keep the discussion moving is that we
primarily discuss based on time (as it is the independent variable), and
simply use the next (not previous) starting signalling period based on a
projection of 10 minute average blocks from today's date to determine the
specific height parameters. *Please pre-register if you have a different
suggestion.*

4. Parameter flexibility.

If we select parameters but, for some reason, need to adjust by a week or
two, does this invalidate all ACKs on parameter selection? Or can we agree
upon some slack in the timeline to accommodate unforeseen development
issues.

5. Simultaneous UASF.

There still seems to be some activity on the front of a simultaneous to ST
UASF. As this has the potential to derail the meeting if there should be
UASF at all (which I think is orthogonal to the goals of this meeting), and
given many participants unfamiliarity with the proposal for a UASF,
*I ask that any issues you wish to raise in this section of the meeting or
pertaining to UASF in a prior section be made in a detailed pre-registered
comment. *

I think it is regrettable to place this onus on the UASF organizers, but
strong communication to the community about plans and intentions seem to be
essential and in line with what would be required for a UASF to be safe and
successful in any case. I also recognize that some participants (on either
side) may not wish to discuss UASF at all in this meeting, but I think that
it is an important part of the activation discussion irrespective of
personal views.


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,

Jeremy


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

[-- Attachment #1.2: Type: text/html, Size: 11254 bytes --]

[-- Attachment #1.3: Type: text/calendar, Size: 968 bytes --]

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:PUBLISH
X-WR-CALNAME:Bitcoin
X-WR-TIMEZONE:America/Los_Angeles
BEGIN:VTIMEZONE
TZID:America/Los_Angeles
X-LIC-LOCATION:America/Los_Angeles
BEGIN:DAYLIGHT
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
TZNAME:PDT
DTSTART:19700308T020000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
TZNAME:PST
DTSTART:19701101T020000
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;TZID=America/Los_Angeles:20210323T120000
DTEND;TZID=America/Los_Angeles:20210323T130000
RRULE:FREQ=WEEKLY;WKST=MO;COUNT=10;INTERVAL=2;BYDAY=TU
DTSTAMP:20210319T193653Z
UID:24bm0kbce0g37qveuua09bas01@google.com
CREATED:20210319T193621Z
DESCRIPTION:
LAST-MODIFIED:20210319T193621Z
LOCATION:IRC ##taproot-activation
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:Taproot Activation Meeting
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR

[-- Attachment #2: taproot-meeting.ics --]
[-- Type: text/calendar, Size: 1009 bytes --]

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:PUBLISH
X-WR-CALNAME:Bitcoin
X-WR-TIMEZONE:America/Los_Angeles
BEGIN:VTIMEZONE
TZID:America/Los_Angeles
X-LIC-LOCATION:America/Los_Angeles
BEGIN:DAYLIGHT
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
TZNAME:PDT
DTSTART:19700308T020000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
TZNAME:PST
DTSTART:19701101T020000
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;TZID=America/Los_Angeles:20210323T120000
DTEND;TZID=America/Los_Angeles:20210323T130000
RRULE:FREQ=WEEKLY;WKST=MO;COUNT=10;INTERVAL=2;BYDAY=TU
DTSTAMP:20210319T193653Z
UID:24bm0kbce0g37qveuua09bas01@google.com
CREATED:20210319T193621Z
DESCRIPTION:
LAST-MODIFIED:20210319T193621Z
LOCATION:IRC ##taproot-activation
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:Taproot Activation Meeting
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR

Re: [bitcoin-dev] (Recurring) Taproot activation meeting on IRC - Tuesday 23rd March 19:00 UTC + every fortnight

[Jeremy]

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

Meeting Reminder:

A few people have pinged me asking when the meeting is. It is in the title
of the email, apologies if that was unclear.

19:00 UTC this Tuesday (12pm Pacific Time).

If you would like to pre-register a comment please try to send it to the
list today or tomorrow if possible, it will help with giving participants a
chance to review any longer form content in advance of the meeting and
ensure a productive conversation.

Best,

Jeremy

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


On Fri, Mar 19, 2021 at 2:41 PM Jeremy <jlrubin@mit.edu> wrote:

> In response to the previous Taproot Activation Meeting, I noted that the
> advance notice was insufficient and proposed having the proposed meeting
> the following week, to consider the meeting last week as a "discussion",
> and thereafter reserving a meeting slot fortnightly reserved. I've been
> asked/volunteered in the ##taproot-activation IRC channel on freenode to
> announce, assemble an agenda, and host this meeting. *If you plan to
> attend please read the entire email as there are some specific instructions
> for participation that have differed from past meetings.*
>
> I've attached an ICS file with scheduling this meeting for 10 repetitions
> for your convenience. Subsequent meetings will hopefully be unnecessary,
> but scheduling them in advance helps ensure a process that respects all
> parties desire to participate.
>
> The purpose of this meeting is to serve as a checkpoint to raise any
> blocking issues and to attempt to finalize parameter selection. As such,
> I've attempted to make a guided agenda that should move towards
> finalization rather than continuation of debate and makes the best use of
> everyone's time. If there are topics missing or if I didn't accurately
> capture the zeitgeist of discussion, please chime in with suggested changes
> to the agenda.
>
> If you cannot attend the meeting you may per-register a comment by
> replying to this email. You may also pre-register a comment here for any
> reason for ease of reference during the meeting, but it is not required. So
> that we can keep the meeting focused and adjust agenda accordingly, I'll
> also request explicitly that certain categories of comment described below
> be pre-registered. Please keep this thread limited to pre-registered
> comments rather than responses to such comments, which will be addressed in
> the meeting.
>
> For the meeting this coming Tuesday the plan is to attempt to finalize on:
>
> 1. Resolving any outstanding concerns around using a Speedy Trial to
> attempt to activate Taproot that must be addressed.
>
> There seems to be diverse consensus on ST, as per
> https://gist.github.com/michaelfolkson/92899f27f1ab30aa2ebee82314f8fe7f#gistcomment-3668460
> .
>
> *As such, please pre-register any concern about any ST variant at all by
> responding below.*
>
> 2. Selecting between start/stop heights and times for a speedy trial.
>
> See https://github.com/bitcoin/bitcoin/pull/21377
> https://github.com/bitcoin/bitcoin/pull/21392.
>
> The focus of this discussion should be focused on blocking reasons to not
> use time based parameters, the code review process, and timelines for being
> able to utilize either activation method.
>
> It is already a widely acknowledged preference for heights over times from
> a blank slate pure technical point of view, this discussion is intended to
> be more pragmatic about safety, hitting the timelines we want to, and
> shipping code.
>
> *As such, If you wish to advocate for MTP from a blank slate pure
> technical point of view, please pre-register a comment below so we can
> adjust the agenda ahead of time. *
>
> 3. Parameter Selection for start/stop/active points.
>
> Short of resolving height or time based start/stop, a discussion of
> selecting acceptable parameters. We should get agreement on both sets of
> height or time parameters irrespective of the resolution to 2, so that this
> conversation can proceed independently.
>
> My personal pre-meeting suggestion to keep the discussion moving is that
> we primarily discuss based on time (as it is the independent variable), and
> simply use the next (not previous) starting signalling period based on a
> projection of 10 minute average blocks from today's date to determine the
> specific height parameters. *Please pre-register if you have a different
> suggestion.*
>
> 4. Parameter flexibility.
>
> If we select parameters but, for some reason, need to adjust by a week or
> two, does this invalidate all ACKs on parameter selection? Or can we agree
> upon some slack in the timeline to accommodate unforeseen development
> issues.
>
> 5. Simultaneous UASF.
>
> There still seems to be some activity on the front of a simultaneous to ST
> UASF. As this has the potential to derail the meeting if there should be
> UASF at all (which I think is orthogonal to the goals of this meeting), and
> given many participants unfamiliarity with the proposal for a UASF,
> *I ask that any issues you wish to raise in this section of the meeting or
> pertaining to UASF in a prior section be made in a detailed pre-registered
> comment. *
>
> I think it is regrettable to place this onus on the UASF organizers, but
> strong communication to the community about plans and intentions seem to be
> essential and in line with what would be required for a UASF to be safe and
> successful in any case. I also recognize that some participants (on either
> side) may not wish to discuss UASF at all in this meeting, but I think that
> it is an important part of the activation discussion irrespective of
> personal views.
>
>
> 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,
>
> Jeremy
>
>
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>
> <https://twitter.com/JeremyRubin>
>

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