path: root/77/fe28ad2d3b407114ba62d505d0814a6e94dabc

Return-Path: <jlrubin@mit.edu>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id E1A04C000A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 24 Mar 2021 03:47:09 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id CFD4D84923
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 24 Mar 2021 03:47:09 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.497
X-Spam-Level: 
X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5
 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3,
 RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id I3la80pDWD0S
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 24 Mar 2021 03:47:08 +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 smtp1.osuosl.org (Postfix) with ESMTPS id 8FE4B84922
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 24 Mar 2021 03:47:08 +0000 (UTC)
Received: from mail-io1-f42.google.com (mail-io1-f42.google.com
 [209.85.166.42]) (authenticated bits=0)
 (User authenticated as jlrubin@ATHENA.MIT.EDU)
 by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 12O3l6NF032666
 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
 for <bitcoin-dev@lists.linuxfoundation.org>; Tue, 23 Mar 2021 23:47:07 -0400
Received: by mail-io1-f42.google.com with SMTP id x16so20078456iob.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 23 Mar 2021 20:47:06 -0700 (PDT)
X-Gm-Message-State: AOAM532rozqKN+Fb06TZNVy8KX4G3Dx+1pCfSFE1xBDtMbsHRJou/I6i
 6xLlklGlWbt4EHlL0i0ocj5lL6DamEhtLLbN0Y4=
X-Google-Smtp-Source: ABdhPJx1gkgrJU30tJHO/fa7TT/L2hD6yW1wM18g5dxmrZxmmx4/M+ojIAwkLPdU5B052cQdLptPmjLagxCGAotXrBo=
X-Received: by 2002:a02:ccb2:: with SMTP id t18mr1037373jap.123.1616557626185; 
 Tue, 23 Mar 2021 20:47:06 -0700 (PDT)
MIME-Version: 1.0
From: Jeremy <jlrubin@mit.edu>
Date: Tue, 23 Mar 2021 20:46:54 -0700
X-Gmail-Original-Message-ID: <CAD5xwhiXE=yJFi+9aZQqMOCaiUrJ_UEvcESR3E0j2SA1RnbqmA@mail.gmail.com>
Message-ID: <CAD5xwhiXE=yJFi+9aZQqMOCaiUrJ_UEvcESR3E0j2SA1RnbqmA@mail.gmail.com>
To: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000115e4b05be4027ae"
Subject: [bitcoin-dev] March 23rd 2021 Taproot Activation Meeting Notes
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Mar 2021 03:47:10 -0000

--000000000000115e4b05be4027ae
Content-Type: text/plain; charset="UTF-8"

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>

--000000000000115e4b05be4027ae
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:#000000">We had a very productive =
meeting today. Here is a summary of the meeting -- I&#39;ve done my best to=
<br>summarize in an unbiased way. Thank you to everyone who attended.<br><b=
r>1. On the use of a speedy trial variant:<br><br>- There are no new object=
ions to speedy trial generally.<br>- There is desire to know if Rusty retra=
cts or reaffirms his NACK in light of the responses.<br>- There is an open =
question of if Rusty&#39;s NACK remains if it is sufficiently addressed.<br=
>- There is no desire to wait for Rusty&#39;s response if he does not respo=
nd (but please don&#39;t leave us in suspense).<br><br><br>2. Selecting bet=
ween heights and MTP:<br><br>- There is not robust consensus on either<br>-=
 There are two NACKs, one (luke-jr) against MTP, one (jeremyrubin) against =
height. More on this in<br>=C2=A0agenda item 5.<br>- No one has an issue wi=
th the technical safety of MTP/heights on their own.<br>- There is an open =
question of the additional review required to ensure height based activatio=
n is<br>=C2=A0safe.<br><br>3. Parameter Selection<br><br>- There is broad a=
greement that we should target something like a May 1st release, with 1 wee=
k from rc1<br>=C2=A0starttime/startheight, and 3 months + delta stoptime/st=
opheight (6 retargetting periods), and an<br>=C2=A0activation time of aroun=
d Nov 15th.<br>- If we select heights, it looks like the first signalling p=
eriod would be 683424, the stop height<br>=C2=A0would be 695520.<br>- If we=
 select times, we should target a mid-period MTP. We can shift this closer =
to release, but<br>=C2=A0currently it looks like a 1300 UTC May 7th start t=
ime and stop time would be 1300 UTC August 13th.<br>- The activation height=
 should be 707616 (about Nov 15th) for either proposal.<br><br>(please chec=
k my math, if anyone is superstitious we can add a day to times...)<br><br>=
4. Parameter Flexibility<br><br>- We may wish to adjust the schedule a litt=
le bit -- either back 1 signal, or up 1 signal.<br>- There&#39;s concurrenc=
e that regardless of pushing the start or stop dates, we should hold the<br=
>=C2=A0November 15th date steady as slipping past Thanksgiving turns to Chr=
istmas turns to New Years<br>=C2=A0turns to Chinese New Year and we&#39;re =
looking at March as the next date people would want to<br>=C2=A0schedule.<b=
r>- There&#39;s concurrence that as long as we&#39;re getting to a release =
sometime in May (with a very strong<br>=C2=A0preference for Mid-May as oppo=
sed to End of May) that we don&#39;t need to re-evaluate. There&#39;s<br>=
=C2=A0limited belief that we could stretch this into June if needed.<br>- T=
here&#39;s belief that we should be able to get a release with ST Taproot o=
n the timeline suggested<br>=C2=A0by topic 3.<br><br>5. Simultaneous UASF*<=
br><br>- luke-jr believes that a UASF client must be able to release before=
 the ST client releases in<br>=C2=A0order for people to use it<br>- no one =
else in attendance seemed to share this sentiment, a UASF can proceed indep=
endently of ST.<br>- UASF is compatible with a MTP based ST by selecting wh=
atever height the ST MTP started at<br>=C2=A0(and a stop height farther in =
the future with LOT).<br>- luke-jr NACK of ST MTP: ST with MTP means that U=
ASF must release after ST releases, which limits<br>=C2=A0UASF adoption.<br=
>- jeremyrubin NACK of ST Height: if using height means that we&#39;d see a=
 marketed push to launch a<br>=C2=A0UASF client before ST is given a chance=
, ST fails its goal for avoiding contentious forks.<br><br>* For the avoida=
nce of doubt, theUASF client would include logic to be compatible with ST&#=
39;s minimum<br>=C2=A0activation height and may be variously called a &quot=
;UASF&quot;, &quot;BIP8 LOT=3Dtrue w/ minactiveheight for ST<br>=C2=A0compa=
tibility&quot;, &quot;ST + BIP8&quot;, or some other combination of phrases=
 in different places<br><br>Best,<br><br>Jeremy</div><div><div dir=3D"ltr" =
class=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"lt=
r">--<br><a href=3D"https://twitter.com/JeremyRubin" target=3D"_blank">@Jer=
emyRubin</a><a href=3D"https://twitter.com/JeremyRubin" target=3D"_blank"><=
/a></div></div></div></div>

--000000000000115e4b05be4027ae--