Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id DC9B6C0001 for ; Sun, 21 Mar 2021 18:10:58 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id B5BA440245 for ; Sun, 21 Mar 2021 18:10:58 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e72xs7VRWqJl for ; Sun, 21 Mar 2021 18:10:56 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by smtp2.osuosl.org (Postfix) with ESMTPS id 53A4C40275 for ; Sun, 21 Mar 2021 18:10:56 +0000 (UTC) Received: from mail-il1-f181.google.com (mail-il1-f181.google.com [209.85.166.181]) (authenticated bits=0) (User authenticated as jlrubin@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 12LIAsC6011186 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Sun, 21 Mar 2021 14:10:54 -0400 Received: by mail-il1-f181.google.com with SMTP id y17so1167068ila.6 for ; Sun, 21 Mar 2021 11:10:54 -0700 (PDT) X-Gm-Message-State: AOAM532KwqaGK1MthgSqIdzDY/umbYuJLRV9Ba/ftvzwz5eYVTb9xweY zncjcvyCCmeqQfYUEK9LqECNMh6aGiY4Xi+CWFw= X-Google-Smtp-Source: ABdhPJwZYm8a2+N364KAifdfD8NVKIrVplgM6Wu4wKNm+jph6lTzoss7E92oDCrZGjOB8sN1iM+sB1UlOKmobd5BSRA= X-Received: by 2002:a05:6e02:20c3:: with SMTP id 3mr8889822ilq.164.1616350253832; Sun, 21 Mar 2021 11:10:53 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jeremy Date: Sun, 21 Mar 2021 11:10:42 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Jeremy Content-Type: multipart/alternative; boundary="000000000000b6631a05be0fde3c" Cc: Bitcoin development mailing list Subject: Re: [bitcoin-dev] (Recurring) Taproot activation meeting on IRC - Tuesday 23rd March 19:00 UTC + every fortnight X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Mar 2021 18:10:59 -0000 --000000000000b6631a05be0fde3c Content-Type: text/plain; charset="UTF-8" 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 On Fri, Mar 19, 2021 at 2:41 PM Jeremy 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 > > --000000000000b6631a05be0fde3c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Meeting Reminder:

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

19:00 UTC this Tuesda= y (12pm Pacific Time).

If you would like to pre-register a comment pl= ease 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 adv= ance of the meeting and ensure a productive conversation.

Best,

Jeremy



On Fri, Mar 19, 2021 at 2= :41 PM Jeremy <jlrubin@mit.edu>= ; wrote:
In response to the previous T= aproot Activation Meeting, I noted that the advance notice was insufficient= and proposed having the proposed meeting the following week, to consider t= he 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 agen= da, and host this meeting. If you plan to attend please read the entire = email as there are some specific instructions for participation that have d= iffered from past meetings.

I've attached an ICS fi= le with scheduling this meeting for 10 repetitions for your convenience. Su= bsequent meetings will hopefully be unnecessary, but scheduling them in adv= ance helps ensure a process that respects all parties desire to participate= .

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

If you cannot attend the meeting you = may per-register a comment by replying to this email. You may also pre-regi= ster 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 adjus= t agenda accordingly, I'll also request explicitly that certain categor= ies of comment described below be pre-registered. Please keep this thread l= imited to pre-registered comments rather than responses to such comments, w= hich will be addressed in the meeting.

For the meeting this co= ming Tuesday the plan is to attempt to finalize on:

1. Resolvin= g any outstanding concerns around using a Speedy Trial to attempt to activa= te Taproot that must be addressed.

There seems to be diverse c= onsensus on ST, as per https= ://gist.github.com/michaelfolkson/92899f27f1ab30aa2ebee82314f8fe7f#gistcomm= ent-3668460.

As such, please pre-register any concern ab= out any ST variant at all by responding below.

2. Selecting between start/stop h= eights and times for a speedy trial.

See https://github.com/b= itcoin/bitcoin/pull/21377 https://github.com/bitcoin/bitcoin/pull/2139= 2.

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

I= t is already a widely acknowledged preference for heights over times from a= blank slate pure technical point of view, this discussion is intended to b= e more pragmatic about safety, hitting the timelines we want to, and shippi= ng code.

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

3. Paramete= r Selection for start/stop/active points.

Short of resolving he= ight or time based start/stop, a discussion of selecting acceptable paramet= ers. We should get agreement on both sets of height or time parameters irre= spective of the resolution to 2, so that this conversation can proceed inde= pendently.

My personal pre-meeting suggestion to keep the discu= ssion moving is that we primarily discuss based on time (as it is the indep= endent variable), and simply use the next (not previous) starting signallin= g period based on a projection of 10 minute average blocks from today's= date to determine the specific height parameters. Please pre-register i= f you have a different suggestion.

4. Parameter flexibi= lity.

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

5. Simultaneous UASF.

The= re still seems to be some activity on the front of a simultaneous to ST UAS= F. 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 giv= en many participants unfamiliarity with the proposal for a UASF, I ask t= hat any issues you wish to raise in this section of the meeting or pertaini= ng to UASF in a prior section be made in a detailed pre-registered comment.=

I think it is regrettable to place this onus o= n the UASF organizers, but strong communication to the community about plan= s and intentions seem to be essential and in line with what would be requir= ed 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 t= his meeting, but I think that it is an important part of the activation dis= cussion irrespective of personal views.


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

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

Best,

Jeremy
<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ;font-size:small;color:rgb(0,0,0)">

--000000000000b6631a05be0fde3c--