path: root/37/c1184023a0e696aa167c280db405a8e4f415f2

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 2BEDAC000A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 25 Mar 2021 17:35:45 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 19F5884887
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 25 Mar 2021 17:35:45 +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 TlgGomvwM3vp
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 25 Mar 2021 17:35:43 +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 30FB98487D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 25 Mar 2021 17:35:43 +0000 (UTC)
Received: from mail-io1-f43.google.com (mail-io1-f43.google.com
 [209.85.166.43]) (authenticated bits=0)
 (User authenticated as jlrubin@ATHENA.MIT.EDU)
 by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 12PHZfCs001384
 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
 for <bitcoin-dev@lists.linuxfoundation.org>; Thu, 25 Mar 2021 13:35:41 -0400
Received: by mail-io1-f43.google.com with SMTP id z3so2681488ioc.8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 25 Mar 2021 10:35:41 -0700 (PDT)
X-Gm-Message-State: AOAM531V9zkJ4BIvs8qWv0KSPIYWx9VVWSYiHw/yp6+H9IOwGXtp5xUP
 h0sbuDhBdVM63w34PRSLbnV/tqEWx4uDD/WmGqE=
X-Google-Smtp-Source: ABdhPJwXByMH7g18omdnJes1WVMoSb+8Ijv4ySHvuNGDmlASY/cgka/ljohD33LNnt1+Tp3pXxQ9QbQs4MsWut8mSZM=
X-Received: by 2002:a02:93e9:: with SMTP id z96mr8790420jah.73.1616693740763; 
 Thu, 25 Mar 2021 10:35:40 -0700 (PDT)
MIME-Version: 1.0
From: Jeremy <jlrubin@mit.edu>
Date: Thu, 25 Mar 2021 10:35:25 -0700
X-Gmail-Original-Message-ID: <CAD5xwhh=E00DVxqhZc7gDTBXtA-_HgybEaP_ysnA4n6AAVbWsA@mail.gmail.com>
Message-ID: <CAD5xwhh=E00DVxqhZc7gDTBXtA-_HgybEaP_ysnA4n6AAVbWsA@mail.gmail.com>
To: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000002103e905be5fd8cb"
Subject: [bitcoin-dev] Response to Rusty Russell from Github
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: Thu, 25 Mar 2021 17:35:45 -0000

--0000000000002103e905be5fd8cb
Content-Type: text/plain; charset="UTF-8"

In response to
https://gist.github.com/michaelfolkson/92899f27f1ab30aa2ebee82314f8fe7f#gistcomment-3679489,
reproduced below.

Rusty,

I concur with the gist of what you're saying -- Speedy Trial alone is not
the final word on activation logic. There are likely better procedures for
releasing and activating updates.

Where I disagree is that I do not believe that BIP8 with LOT configuration
is the improved long term option we should ossify around either. I
understand the triumvirate model you desire to achieve, but BIP8 with an
individually set LOT configuration does not formalize how economic nodes
send a network legible signal ahead of a chain split. A regular flag day,
with no signalling, but communally released and communicated openly most
likely better achieves the goal of providing users choice.

Where I also disagree is that we are likely to come to consensus on an
improved long term process in the immediate future (e.g., within the next
year), let alone the software for it.

Do you believe that perfecting a release mechanism is a showstopping issue
for proceeding with any upgrade at this time? Or do you just want for this
problem to actively be worked on going forward?

I think it's reasonable to want to form an open ended process to
investigate, spec, and formalize a consistent and complete activation
pathway but I don't think we should force the community to wait around for
an unknown solution to release upgrades that are waiting for takeoff.


Lastly, I'll make the case that ST *does* meet your desired triumvirate at
least as well as BIP8 with configurable LOT.

1. Developers release, but do not activate
2. Miners signal
3. Users may override by compiling and releasing a patched Bitcoin with
moderate changes that activates Taproot at a later date. While this might
*seem* more complicated a procedure than configurable LOT, here are four
reasons why it may be simpler (and safer) to just do a fresh release:

A. No time-based consensus sensitivity on when LOT must be set (e.g., what
happens if mid final signal period users decide to set LOT? Do all users
set it at the same time? Or different times and end up causing nodes to ban
each other for various reasons?)
B. No "missed window" if users don't coordinate on setting LOT before the
final period -- release whenever ready.
C. ST fails fast, permitting users ample time to prepare an alternative
release
D. If miners continue to mine without signalling, and users abandon a
LOT=true setting, their node will have already marked those blocks invalid
and they will need to figure out how to re-validate the block.

RE: point 3, is it as easy as it *could* be? No, but I don't have any
genius ideas on how to make it easier either. (Note that I've previously
argued for adding configurable LOT=true on the basis that a user-run script
could emulate LOT without any software change as a harm reduction, but I
did not advocate that particular technique be formalized as a part of the
activation process)


Best,

Jeremy


> > > Taproot could be activated by a blind monkey, [...] ST avoids the
hard questions, since it will almost certainly pass; [...] But one day, a
real crisis will return. We won't have an answer, and we won't have
practiced: this will make the crisis far worse. Instead, if we codify "devs
propose, miners activate, users override" (i.e. a LOT=true option, off by
default) we'll know exactly what the process will be when miners fail to
activate. It may still be messy, of course, but we'll have all the tools at
hand, and we'll even know the date the crisis will come to a head.
> >
> >
> > I think this argument makes two major errors:
> > ```
> > * First, it tries to artificially tie two improvements together; "if
you can't solve controversial activations, you shouldn't get taproot". That
isn't the way we should do development: just as it was a mistake to try to
tie segwit and a hard-fork to double the block size together, other
improvements should also stand or fall on their own merits. If we're tying
updates together there should be good reasons for why they're better
together (eg segwit and the witness discount; and taproot, schnorr and
tapscript).
> > ```
>
> No, this is a disagreement about how _all_ changes should be activated.
This is completely germane to the current debate. Remember, segwit wasn't
"controversial" until it suddenly was, either. I believe this is not the
case here, but then, I believed that last time as well.
>
> > ```
> > * Second, it assumes that you can usefully test a weapon when play
fighting -- if taproot can be activated by a blind monkey, then having your
bodyguards activate taproot only proves they're as good as a blind monkey,
not that they're ready to protect you from a home invasion. In particular,
bip8 isn't even as ready as bip148 for a real battle; it lacks even the
limited safeguards that were included in that client (and it's also lost
the element of surprise, which might've been bip148's biggest advantage).
> > ```
>
> "BIP 8 isn't ready" is definitely a factor, but while I prefer existing
code when there are no other major factors, there are IMHO major factors
here.
>
> > I think it also probably assumes that the bip8 approach is more ready
to go than it is -- there are (IMHO) serious unresolved objections to bip8
in every possible deployment mode (eg, just lot=true: developers are
imposing decisions on miners and users; just lot=false: miners can object;
lot=true and lot=false: unnecessary chain split risk, risk of downtime for
those running lot=true, risk of reorgs/wipeout for those running
lot=false). Maybe all those objections -- even the ones from one of the
bip8 authors -- are mistaken, but personally I think it's more likely that
significant improvements are needed.
>
> "unnecessary chainsplit risk". No, that's exactly the point: if we end up
with various significant factions fighting over the rules, there will be a
chainsplit. There are no technical workarounds for this. BIP 8 has been
revised to minimize the chance of an _unnecessary_ chainsplit, and the
entire BIP-8 lot=true mechanism was designed as an explicit mining forcing
function.
>
> I remember @pwuille saying explicitly about Segwit activation that users
must decide. That has stuck with me, and my preference for a hidden
lot=true option reflects this understanding. Without such an option,
developers are saying "you can override, but you'll have to replace us."
The result in practice that users are reduced to "beg the devs" or "beg the
miners". That kinda worked last time but damn it was messy, and such
uncertainty does not help the BItcoin ecosystem.
>
> > Personally, I can think of about half a dozen soft-forks I would
like/expect to see progress on once taproot is squared away (great
consensus cleanup, anyprevout, ctv, graftroot, annex-based block
commitments, op_cat/covenants), so it's not like there aren't other
opportunities to improve activation methodologies coming up.
>
> If this approach is good enough until there's a crisis, then why would
anyone approve anything until a crisis comes?

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

--0000000000002103e905be5fd8cb
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">In response to <a href=3D=
"https://gist.github.com/michaelfolkson/92899f27f1ab30aa2ebee82314f8fe7f#gi=
stcomment-3679489">https://gist.github.com/michaelfolkson/92899f27f1ab30aa2=
ebee82314f8fe7f#gistcomment-3679489</a>, reproduced below.<br></div><div cl=
ass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-=
size:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D"f=
ont-family:arial,helvetica,sans-serif;font-size:small;color:#000000">Rusty,=
<br></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica=
,sans-serif;font-size:small;color:#000000"><br>I concur with the gist of wh=
at you&#39;re saying -- Speedy Trial alone is not the final word on activat=
ion logic. There are likely  better procedures for releasing and activating=
 updates.<br><br>Where I disagree is that I do not believe that BIP8 with L=
OT configuration is the improved long term option we should ossify around e=
ither. I understand the triumvirate model you desire to achieve, but  BIP8 =
with an individually set LOT configuration does not formalize how economic =
nodes send a network legible signal ahead of a chain split. A regular flag =
day, with no signalling, but communally released and communicated openly mo=
st likely better achieves the goal of providing users choice.</div><div cla=
ss=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-s=
ize:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D"fo=
nt-family:arial,helvetica,sans-serif;font-size:small;color:#000000">Where I=
 also disagree is that we are likely  to come to consensus on an improved l=
ong term process in the immediate future (e.g., within the next year), let =
alone the software for it.<br><br>Do you believe that perfecting a release =
mechanism is a showstopping issue for proceeding with any upgrade at this t=
ime? Or do you just want for this problem to actively be worked on going fo=
rward?<br></div><div><br></div><div><div style=3D"font-family:arial,helveti=
ca,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">I t=
hink it&#39;s reasonable to want to form an open ended process to investiga=
te, spec, and formalize a consistent and complete activation pathway but I =
don&#39;t think we should force the community to wait around for an unknown=
 solution to release upgrades that are waiting for takeoff.</div><div style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)=
" class=3D"gmail_default"><br></div><div style=3D"font-family:arial,helveti=
ca,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><br=
></div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small=
;color:rgb(0,0,0)" class=3D"gmail_default">Lastly, I&#39;ll make the case t=
hat ST *does* meet your desired triumvirate at least as well as BIP8 with c=
onfigurable LOT.</div><div style=3D"font-family:arial,helvetica,sans-serif;=
font-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><br></div><div st=
yle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0=
,0)" class=3D"gmail_default">1. Developers release, but do not activate</di=
v><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;colo=
r:rgb(0,0,0)" class=3D"gmail_default">2. Miners signal</div><div style=3D"f=
ont-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" cla=
ss=3D"gmail_default">3. Users may override by compiling and releasing a pat=
ched Bitcoin with moderate changes that activates Taproot at a later date. =
While this might *seem* more complicated a procedure than configurable LOT,=
 here are four reasons why it may be simpler (and safer) to just do a fresh=
 release:</div><div style=3D"font-family:arial,helvetica,sans-serif;font-si=
ze:small;color:rgb(0,0,0)" class=3D"gmail_default"><br></div><div style=3D"=
font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" cl=
ass=3D"gmail_default">A. No time-based consensus sensitivity on when LOT mu=
st be set (e.g., what happens if mid final signal period users decide to se=
t LOT? Do all users set it at the same time? Or different times and end up =
causing nodes to ban each other for various reasons?)<br></div><div style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)=
" class=3D"gmail_default">B. No &quot;missed window&quot; if users don&#39;=
t coordinate on setting LOT before the final period -- release whenever rea=
dy.<br></div><div style=3D"font-family:arial,helvetica,sans-serif;font-size=
:small;color:rgb(0,0,0)" class=3D"gmail_default">C. ST fails fast, permitti=
ng users ample time to prepare an alternative release</div><div style=3D"fo=
nt-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" clas=
s=3D"gmail_default">D. If miners continue to mine without signalling, and u=
sers abandon a LOT=3Dtrue setting, their node will have already marked thos=
e blocks invalid and they will need to figure out how to re-validate the bl=
ock.<br></div><br></div><div><div style=3D"font-family:arial,helvetica,sans=
-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">RE: point =
3, is it as easy as it *could* be? No, but I don&#39;t have any genius idea=
s on how to make it easier either. (Note that I&#39;ve previously argued fo=
r adding configurable LOT=3Dtrue on the basis that a user-run script could =
emulate LOT without any software change as a harm reduction, but I did not =
advocate that particular technique be formalized as a part of the activatio=
n process)<br></div><br></div><div><br></div><div><div style=3D"font-family=
:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmai=
l_default">Best,</div><div style=3D"font-family:arial,helvetica,sans-serif;=
font-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><br></div><div st=
yle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0=
,0)" class=3D"gmail_default">Jeremy</div><br></div><div><br></div><div><div=
 style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(=
0,0,0)" class=3D"gmail_default">&gt; &gt; &gt; Taproot could be activated b=
y a blind monkey, [...] ST avoids the hard questions, since it will almost =
certainly pass; [...] But one day, a real crisis will return. We won&#39;t =
have an answer, and we won&#39;t have practiced: this will make the crisis =
far worse. Instead, if we codify &quot;devs propose, miners activate, users=
 override&quot; (i.e. a LOT=3Dtrue option, off by default) we&#39;ll know e=
xactly what the process will be when miners fail to activate. It may still =
be messy, of course, but we&#39;ll have all the tools at hand, and we&#39;l=
l even know the date the crisis will come to a head.<br>&gt; &gt; <br>&gt; =
&gt; <br>&gt; &gt; I think this argument makes two major errors:<br>&gt; &g=
t; ```<br>&gt; &gt; * First, it tries to artificially tie two improvements =
together; &quot;if you can&#39;t solve controversial activations, you shoul=
dn&#39;t get taproot&quot;. That isn&#39;t the way we should do development=
: just as it was a mistake to try to tie segwit and a hard-fork to double t=
he block size together, other improvements should also stand or fall on the=
ir own merits. If we&#39;re tying updates together there should be good rea=
sons for why they&#39;re better together (eg segwit and the witness discoun=
t; and taproot, schnorr and tapscript).<br>&gt; &gt; ```<br>&gt; <br>&gt; N=
o, this is a disagreement about how _all_ changes should be activated. This=
 is completely germane to the current debate. Remember, segwit wasn&#39;t &=
quot;controversial&quot; until it suddenly was, either. I believe this is n=
ot the case here, but then, I believed that last time as well.<br>&gt; <br>=
&gt; &gt; ```<br>&gt; &gt; * Second, it assumes that you can usefully test =
a weapon when play fighting -- if taproot can be activated by a blind monke=
y, then having your bodyguards activate taproot only proves they&#39;re as =
good as a blind monkey, not that they&#39;re ready to protect you from a ho=
me invasion. In particular, bip8 isn&#39;t even as ready as bip148 for a re=
al battle; it lacks even the limited safeguards that were included in that =
client (and it&#39;s also lost the element of surprise, which might&#39;ve =
been bip148&#39;s biggest advantage).<br>&gt; &gt; ```<br>&gt; <br>&gt; &qu=
ot;BIP 8 isn&#39;t ready&quot; is definitely a factor, but while I prefer e=
xisting code when there are no other major factors, there are IMHO major fa=
ctors here.<br>&gt; <br>&gt; &gt; I think it also probably assumes that the=
 bip8 approach is more ready to go than it is -- there are (IMHO) serious u=
nresolved objections to bip8 in every possible deployment mode (eg, just lo=
t=3Dtrue: developers are imposing decisions on miners and users; just lot=
=3Dfalse: miners can object; lot=3Dtrue and lot=3Dfalse: unnecessary chain =
split risk, risk of downtime for those running lot=3Dtrue, risk of reorgs/w=
ipeout for those running lot=3Dfalse). Maybe all those objections -- even t=
he ones from one of the bip8 authors -- are mistaken, but personally I thin=
k it&#39;s more likely that significant improvements are needed.<br>&gt; <b=
r>&gt; &quot;unnecessary chainsplit risk&quot;. No, that&#39;s exactly the =
point: if we end up with various significant factions fighting over the rul=
es, there will be a chainsplit. There are no technical workarounds for this=
. BIP 8 has been revised to minimize the chance of an _unnecessary_ chainsp=
lit, and the entire BIP-8 lot=3Dtrue mechanism was designed as an explicit =
mining forcing function.<br>&gt; <br>&gt; I remember @pwuille saying explic=
itly about Segwit activation that users must decide. That has stuck with me=
, and my preference for a hidden lot=3Dtrue option reflects this understand=
ing. Without such an option, developers are saying &quot;you can override, =
but you&#39;ll have to replace us.&quot; The result in practice that users =
are reduced to &quot;beg the devs&quot; or &quot;beg the miners&quot;. That=
 kinda worked last time but damn it was messy, and such uncertainty does no=
t help the BItcoin ecosystem.<br>&gt; <br>&gt; &gt; Personally, I can think=
 of about half a dozen soft-forks I would like/expect to see progress on on=
ce taproot is squared away (great consensus cleanup, anyprevout, ctv, graft=
root, annex-based block commitments, op_cat/covenants), so it&#39;s not lik=
e there aren&#39;t other opportunities to improve activation methodologies =
coming up.<br>&gt; <br>&gt; If this approach is good enough until there&#39=
;s a crisis, then why would anyone approve anything until a crisis comes?<b=
r></div><br></div><div><div dir=3D"ltr" class=3D"gmail_signature" data-smar=
tmail=3D"gmail_signature"><div dir=3D"ltr">--<br><a href=3D"https://twitter=
.com/JeremyRubin" target=3D"_blank">@JeremyRubin</a><a href=3D"https://twit=
ter.com/JeremyRubin" target=3D"_blank"></a></div></div></div></div>

--0000000000002103e905be5fd8cb--