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

[Jeremy <jlrubin@mit.edu>]

[-- 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 --]