From: Luke Dashjr <luke@dashjr.org>
To: Jeremy <jlrubin@mit.edu>
Date: Mon, 15 Mar 2021 21:46:35 +0000
User-Agent: KMail/1.9.10
References: <202103151720.04687.luke@dashjr.org>
 <202103151937.38260.luke@dashjr.org>
 <CAD5xwhg7-KXysYb4sT+uvnPBZm+LanERsgyOiZOyEDjo=kRjRA@mail.gmail.com>
In-Reply-To: <CAD5xwhg7-KXysYb4sT+uvnPBZm+LanERsgyOiZOyEDjo=kRjRA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <202103152146.35961.luke@dashjr.org>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Taproot activation meeting on IRC - Tuesday 16th
	March 19:00 UTC
Precedence: list

I am referring to the timeline and recommendation from the meeting on February 
16th, which has been slowly making progress toward a release:

https://en.bitcoin.it/wiki/Taproot_activation_proposal_202102

The first period from height 693504-695520 here overlaps with the last period 
of AChow's ST pull request.

A release today is impossible of course. But 1 or 2 days late is nothing 
compared to waiting a week and not having even gotten started. :)
I expect/hope that there will be consensus to adapt around ST, shifting 
everything later, but I'm just one person.

roconnor pointed out that the best solution is probably to just enclose ST's 
timeline; something like this:

https://github.com/BitcoinActivation/BitcoinTaproot.org/pull/3/files#diff-e43ac101b32b6804209cfdf26da4d122e54b994eb7f1538d4378f6a508dab817L529

Luke


On Monday 15 March 2021 20:59:11 Jeremy wrote:
> Can you expand on the timeline issue? Which timelines are incompatible and
> why?
>
> It does seem like a release done *today* cannot happen anyways, so it
> sounds like it's already too late... or do you mean beginning the release
> process today?
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>
> <https://twitter.com/JeremyRubin>
>
> On Mon, Mar 15, 2021 at 12:38 PM Luke Dashjr <luke@dashjr.org> wrote:
> > While I agree 24 hours is too short notice, if someone wishes to insist
> > on keeping the current timeline, software supporting it should be
> > released _today_. Putting the meeting off a week would almost necessarily
> > imply rejection of any desires to stick to the original plan.
> >
> > So for that reason, I think we need to at least try to have a meeting
> > tomorrow, at least to give anyone who won't agree to such a delay a
> > chance to
> > speak up before it's too late, and have his argument fairly considered.
> >
> > We can still have a meeting next week. The idea of having one every other
> > week
> > seems like a good idea to avoid this in the future, too.
> >
> > Luke
> >
> > On Monday 15 March 2021 19:14:02 Jeremy wrote:
> > > Please announce such meetings with more than ~24 hours notice -- this
> > > has happened several times and while I recognize the pace of
> > > development on this issue I think that slotting a consensus meeting
> > > with less than 24 hours is inappropriate.
> > >
> > > I think we should proactively postpone it a week so that there isn't an
> > > arbitrary "too low turnout" measure and instead anyone who really wants
> >
> > to
> >
> > > be present for the meeting can plan to be.
> > >
> > > So as not to lose momentum on having a discussion, I propose to plan to
> > > hold a general discussion tomorrow at that time and a meeting (with the
> > > intent of resolving issues in a more binding way) next week. It may be
> > > a good idea to hold the time slot every other week for the next while
> > > so
> >
> > that
> >
> > > we can avoid this 24 hour thing altogether.
> > >
> > > It sucks to lose another week but a precedent of 24 hour notice
> > > meetings for non urgent changes is very negative.
> > >
> > > (This isn't any comment on if ST is OK or not -- the schedules proposed
> >
> > for
> >
> > > ST thus far seem acceptable to me)
> > >
> > > Best,
> > >
> > > Jeremy
> > > --
> > > @JeremyRubin <https://twitter.com/JeremyRubin>
> > > <https://twitter.com/JeremyRubin>
> > >
> > >
> > > On Mon, Mar 15, 2021 at 10:20 AM Luke Dashjr via bitcoin-dev <
> > >
> > > bitcoin-dev@lists.linuxfoundation.org> wrote:
> > > > At the previous meeting, there was consensus for BIP8 activation
> > > > parameters
> > > > except for LOT, assuming a release around this time. Since then, a
> > > > release has not occurred, and the new idea of Speedy Trial has been
> > > > proposed to preempt the original/main activation plan.
> > > >
> > > > It's probably a good idea to meet up again to discuss these things
> > > > and adjust
> > > > accordingly.
> > > >
> > > > Agenda:
> > > >
> > > > - Speedy Trial: Can we get a comparable consensus on the proposal?
> > > >   (Note: current draft conflicts with original plan timeline)
> > > >
> > > > - Main activation, post ST: Moving startheight (and timeoutheight?)
> >
> > later
> >
> > > >   is probably a good idea at this point, both because too little
> >
> > progress
> >
> > > > has
> > > >   been made on it, and to avoid the conflict with the current ST
> > > > draft.
> > > >
> > > > - Making progress: To date, too few people have been involved in
> > > > materialising
> > > >   the main activation plan. If it's going to move forward, more
> > > > people need to
> > > >   get actively involved. This should not wait for ST to complete,
> >
> > unless
> >
> > > > we want another 4-5 month slip of the timeline.
> > > >
> > > > This meeting is tentatively scheduled for *tomorrow*, March 16th at
> > > > the usual
> > > > time of 19:00 UTC, in freenode's ##Taproot-activation IRC channel. If
> > > > turnout
> > > > is too low, we can postpone it a week, but it'd be nice to get things
> > > > resolved and moving sooner.
> > > >
> > > > 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
> > > >
> > > > Luke
> > > > _______________________________________________
> > > > bitcoin-dev mailing list
> > > > bitcoin-dev@lists.linuxfoundation.org
> > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev