diff options
| author | Jorge Timón <jtimon@jtimon.cc> | 2021-03-08 13:51:50 +0100 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2021-03-08 12:52:07 +0000 |
| commit | d180b4701c0d066caf66a0f0c279a57696502425 (patch) | |
| tree | 910f49e36cfa0f66909400b43470a0c2b43e9eab /fc | |
| parent | 932e75504ccb0a6e5d434adfb2aa9177bed2089a (diff) | |
| download | pi-bitcoindev-d180b4701c0d066caf66a0f0c279a57696502425.tar.gz pi-bitcoindev-d180b4701c0d066caf66a0f0c279a57696502425.zip | |
Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation
Diffstat (limited to 'fc')
| -rw-r--r-- | fc/5dcedb28354faead90e976fdf886a73fe56413 | 430 |
1 files changed, 430 insertions, 0 deletions
diff --git a/fc/5dcedb28354faead90e976fdf886a73fe56413 b/fc/5dcedb28354faead90e976fdf886a73fe56413 new file mode 100644 index 000000000..bd072a619 --- /dev/null +++ b/fc/5dcedb28354faead90e976fdf886a73fe56413 @@ -0,0 +1,430 @@ +Return-Path: <jtimon@jtimon.cc> +Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 15FF3C0001 + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 8 Mar 2021 12:52:07 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp3.osuosl.org (Postfix) with ESMTP id F2FC96074F + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 8 Mar 2021 12:52:06 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: 0.803 +X-Spam-Level: +X-Spam-Status: No, score=0.803 tagged_above=-999 required=5 + tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, + HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, + SPF_NONE=0.001] autolearn=ham autolearn_force=no +Authentication-Results: smtp3.osuosl.org (amavisd-new); + dkim=pass (2048-bit key) header.d=jtimon-cc.20150623.gappssmtp.com +Received: from smtp3.osuosl.org ([127.0.0.1]) + by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id j1WTGiDwio_y + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 8 Mar 2021 12:52:05 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.8.0 +Received: from mail-oo1-xc2d.google.com (mail-oo1-xc2d.google.com + [IPv6:2607:f8b0:4864:20::c2d]) + by smtp3.osuosl.org (Postfix) with ESMTPS id 2DAFE6064C + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 8 Mar 2021 12:52:05 +0000 (UTC) +Received: by mail-oo1-xc2d.google.com with SMTP id p6so2157234oot.2 + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 08 Mar 2021 04:52:05 -0800 (PST) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=jtimon-cc.20150623.gappssmtp.com; s=20150623; + h=mime-version:references:in-reply-to:from:date:message-id:subject:to + :cc; bh=GTv9emXUYI42bMjXAI+PFK8yx8SrImGEU9WJyx7kRTk=; + b=eveRapoQVCbkNPoppQlq2C/SThcLHWP3jLA6SEf2kK6eJ0+95hQhEfKJP6kU1ApyNV + ZkwEF+yjjTRYdWK8b6hwr5vWQClRFWrVYsBZ1RhxNRCCfiRF8edY723/QbL+jcRLNfSm + zYFlJeoz45qhPT8AovzG2sKEkLBXlsrTOWMc8WQFVUbOODkxzwwSXqex6k+qHkH/KW14 + RXlD64cwRX2h4SL6MTQLbqTUeMbVsgvpFF8fBaHyemmCJwLeDZF+t+xLdOW6DcF2xjzW + JWBG1DQbBAR2qXRsMvTsxJCdlX6FlGNl2FWJDOQvxaC+IQHyyUrPhI8Bf4JfURLZtt6Y + MjNQ== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20161025; + h=x-gm-message-state:mime-version:references:in-reply-to:from:date + :message-id:subject:to:cc; + bh=GTv9emXUYI42bMjXAI+PFK8yx8SrImGEU9WJyx7kRTk=; + b=tU0PY5h10YWu2NA5o4hdYNH1TRdhxLCQPWqJGUorDiKt0SIzdZYx6d7ObPXF7d0LLp + SF1WjAZIk72HkZG6YC8+Inkgde0GjhlL6tGXLtwhxFAMeOpwk6Y2cQlrw5IfJwHT16YW + 78+TSc3TuTolv4poO8xcAHh9ENXvP/hQszbvyNw1B1vlBEbfnyMCNBf989L4J2A4CENr + QQ96Udl0eMFK9bKHZLbnmIBHBlJ25oSPpntBoR9hDbx8i3wpKnAPHmz8JLRkUBxWCp2b + WIvscm1avnGtglcDBRD7XO9NIcGUsmwnINOiTaT1gbyc2DmhInbLQ5azOEd54+aoW4gi + xiLw== +X-Gm-Message-State: AOAM532SloUXZOajXXCHixEg+HGwaPYykmBHwJivCtGHulVOCHhmUHh6 + r4z51mIj8oZvZaM76s4b3oNHNxA6JENdBYdBAsh4zmQPkUU= +X-Google-Smtp-Source: ABdhPJy+KkSzttJoDLoAfoCspFUS0Ll5Ym48f27dCM9rNqtokf/yuqi/MZaFltU7IqV6DJG+8wwrLk3vryAZx/eCFC4= +X-Received: by 2002:a4a:420d:: with SMTP id h13mr18375515ooj.24.1615207924124; + Mon, 08 Mar 2021 04:52:04 -0800 (PST) +MIME-Version: 1.0 +References: <c35e1761-43ca-e157-6a5c-72d27f2c6c6e@mattcorallo.com> + <20210303145902.cl4mzg6l7avjboil@erisian.com.au> + <281679eb-860b-c6cb-7e7a-5ae28b60f149@mattcorallo.com> + <20210306113326.mrftlkmmloy2dsag@erisian.com.au> +In-Reply-To: <20210306113326.mrftlkmmloy2dsag@erisian.com.au> +From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc> +Date: Mon, 8 Mar 2021 13:51:50 +0100 +Message-ID: <CABm2gDpky7W-e_Vp5bFZ-k+y40-wFsNZ_-Cj-JNxi7PjTB2nxQ@mail.gmail.com> +To: Anthony Towns <aj@erisian.com.au>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: multipart/alternative; boundary="0000000000008e5f2d05bd05e611" +Subject: Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation +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: Mon, 08 Mar 2021 12:52:07 -0000 + +--0000000000008e5f2d05bd05e611 +Content-Type: text/plain; charset="UTF-8" + +Concept nack. +This has no advantage over bip8(true). +Bip9(false) is just bip9. +Thr only reasonable argument against bip8(true) is "some people may do +bip8(false) instead", which is a stypid argument applyable to any +activation method. + +People against taproot should want code to forbid its activation rather +than limiting themselves to suport bip9/bip8(false) and hope it doesn't get +activated it. + +Some other arguments seem to be based on the wrong assumption that miners +should decide the rules. + +Thisproposal solves nothing, just adds to the noise and thus is really +disappointing. + + +On Sat, Mar 6, 2021, 12:33 Anthony Towns via bitcoin-dev < +bitcoin-dev@lists.linuxfoundation.org> wrote: + +> On Wed, Mar 03, 2021 at 11:49:57AM -0500, Matt Corallo wrote: +> > On 3/3/21 09:59, Anthony Towns wrote: +> > > A couple of days ago I would have disagreed with this; but with Luke +> > > now strongly pushing against implementing lot=false, I can at least see +> > > your point... +> > Right. It may be the case that the minority group threatening to fork off +> > onto a lot=true chain is not large enough to give a second thought to. +> > However, I'm not certain that its worth the risk, and, as Chris noted in +> his +> > post this morning, that approach is likely to include more drama. +> +> I think there's two different interpretations of what a "user-activated +> fork" means: +> +> 1) if people try to take bitcoin in a direction that risks destroying +> it, it's possible to ignore both devs and hashpower entirely and force +> a chain split to ensure it's possible to continue transacting with +> "the real bitcoin". +> +> 2) removing miners' influence over consensus rules entirely -- so that +> not only can users overcome miner objections by risking a chain split, +> but so that miners don't have any greater ability to object than +> anyone else in the ecosystem. +> +> In my opinion, bip8's optional lockinontimeout setting and must-signal +> approach is well-designed for case 1; if miners object for good reasons, +> then there is no need to override them (if there's a good reason not to do +> something, it shouldn't be done!), while still having the possibility to +> override them if they object for bad reasons. Because hashpower disagrees, +> there's always a risk of a chain split in that case, so the additional +> risk introduced by a signalling requirement is pretty minimal. That the +> lockinontimeout value is a setting means it can be switched only when +> we're sure there aren't good reasons for the objection. +> +> There is a lot of work to be done to make bitcoind have an acceptable +> chance of gracefully *surviving* a network split introduced by this sort +> of conflict; but provided no one started setting lockinontimeout=true +> until we were six or so months into an activation attempt (and hence +> had the opportunity to judge whether the reasons for not activating +> were bad), that would likely be enough time to start implementing some +> safety mechanisms. +> +> But there seems to be much more signficant support for the case 2 than I +> expected; as evidenced by the "let's do lockinontimeout=true immediately" +> advocacy, eg: +> +> I am not willing to go to war for Taproot. I'll be honest the reason +> I'm interested at all is that devs I respect spent a lot of energy and +> time on it and I was reluctant to let their marginally beneficial work +> go to waste. +> +> I am, however, willing to go to war against LOT=False. +> +> -- https://twitter.com/francispouliot_/status/1363876292169465856 +> +> I don't think bip8 is well-designed for that approach: most importantly, +> with early adoption of lockinontimeout=true, bip8 *encourages* a consensus +> split in the event that good reasons for not activating are discovered +> afterwards, because lockinontimeout=false nodes remain able to abandon +> the activation attempt. Consensus splits are terrible; they should be +> a last resort used only in the event that bitcoin's fundamental nature +> is threatened, not a standard risk if bugs happened to be discovered +> late. But additionally, if we are worried miners might not be acting +> in the interests of all bitcoin users, there are other games they could +> play, such as "if you want X activated quickly, also give us Y; otherwise +> we'll delay it as long as possible". +> +> Losing the opportunity to abandon an activation attempt, by whatever +> mechanism, also puts a lot more pressure on being absolutely sure of the +> desirability of the change at the point when it's merged; because miners, +> third-party devs, businesses, and users don't even have the option of +> attempting to influence miners, all objections needs to be raised when +> the activation parameters are merged, which raises the stakes for that +> event substantially. +> +> I think my conclusions from that are: +> +> * as it stands, people are expecting to run bip8/lot=true nodes on the +> network immediately; so deploying bip8/lot=false with compatible +> parameters risks causing consensus splits, and should not be done +> +> * David Harding's "speedy trial" approach probably doesn't suffer from +> the problems -- running a lot=true variant would require enforcing +> signalling prior to the end of July, which is an unreasonable timeframe +> to expect the majority of economic nodes to upgrade in; if bip9 is +> used, then the risk of enforcement occuring with minority hashrate +> (and thus having fewer retarget periods before the timeout is +> reached) would also make a bip148/lot=true variant difficulty +> +> * if people want a "taproot is guaranteed to activate no later than X" +> PR merged, someone needs to do a *lot* more outreach to be sure that +> that's the right outcome, and it's not just devs/maintainers making +> the call +> +> * IMO, Matt's proposed approach is both a better and simpler approach +> to avoid giving miners undue influence on consensus; as such I've +> drafted up a sample implementation: +> +> https://github.com/bitcoin/bitcoin/pull/21378 +> +> (Backporting it to 0.21 just requires backporting #19438, which is +> straightforward) +> +> So I think that means my preference is to do the "speedy trial" with +> signalling first, and if that fails, then either we've established there +> are real problems with taproot and will go back to the drawing board to +> fix them, or if we have not found problems by that time we should simply +> switch to a straight flag day activation as Matt proposes. Presumably +> we'll have established broard community consensus for activation if no +> objections are discovered during the speedy trial. +> +> Cheers, +> aj +> +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +> + +--0000000000008e5f2d05bd05e611 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"auto">Concept nack.<div dir=3D"auto">This has no advantage over= + bip8(true).</div><div dir=3D"auto">Bip9(false) is just bip9.</div><div dir= +=3D"auto">Thr only reasonable argument against bip8(true) is "some peo= +ple may do bip8(false) instead", which is a stypid argument applyable = +to any activation method.</div><div dir=3D"auto"><br></div><div dir=3D"auto= +">People against taproot should want code to forbid its activation rather t= +han limiting themselves to suport bip9/bip8(false) and hope it doesn't = +get activated it.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Some o= +ther arguments seem to be based on the wrong assumption that miners should = +decide the rules.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Thispr= +oposal solves nothing, just adds to the noise and thus is really disappoint= +ing.</div><div dir=3D"auto"><br></div></div><br><div class=3D"gmail_quote">= +<div dir=3D"ltr" class=3D"gmail_attr">On Sat, Mar 6, 2021, 12:33 Anthony To= +wns via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation= +.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></div><blockq= +uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc = +solid;padding-left:1ex">On Wed, Mar 03, 2021 at 11:49:57AM -0500, Matt Cora= +llo wrote:<br> +> On 3/3/21 09:59, Anthony Towns wrote:<br> +> > A couple of days ago I would have disagreed with this; but with L= +uke<br> +> > now strongly pushing against implementing lot=3Dfalse, I can at l= +east see<br> +> > your point...<br> +> Right. It may be the case that the minority group threatening to fork = +off<br> +> onto a lot=3Dtrue chain is not large enough to give a second thought t= +o.<br> +> However, I'm not certain that its worth the risk, and, as Chris no= +ted in his<br> +> post this morning, that approach is likely to include more drama.<br> +<br> +I think there's two different interpretations of what a "user-acti= +vated<br> +fork" means:<br> +<br> +=C2=A01) if people try to take bitcoin in a direction that risks destroying= +<br> +=C2=A0 =C2=A0 it, it's possible to ignore both devs and hashpower entir= +ely and force<br> +=C2=A0 =C2=A0 a chain split to ensure it's possible to continue transac= +ting with<br> +=C2=A0 =C2=A0 "the real bitcoin".<br> +<br> +=C2=A02) removing miners' influence over consensus rules entirely -- so= + that<br> +=C2=A0 =C2=A0 not only can users overcome miner objections by risking a cha= +in split,<br> +=C2=A0 =C2=A0 but so that miners don't have any greater ability to obje= +ct than<br> +=C2=A0 =C2=A0 anyone else in the ecosystem.<br> +<br> +In my opinion, bip8's optional lockinontimeout setting and must-signal<= +br> +approach is well-designed for case 1; if miners object for good reasons,<br= +> +then there is no need to override them (if there's a good reason not to= + do<br> +something, it shouldn't be done!), while still having the possibility t= +o<br> +override them if they object for bad reasons. Because hashpower disagrees,<= +br> +there's always a risk of a chain split in that case, so the additional<= +br> +risk introduced by a signalling requirement is pretty minimal. That the<br> +lockinontimeout value is a setting means it can be switched only when<br> +we're sure there aren't good reasons for the objection.<br> +<br> +There is a lot of work to be done to make bitcoind have an acceptable<br> +chance of gracefully *surviving* a network split introduced by this sort<br= +> +of conflict; but provided no one started setting lockinontimeout=3Dtrue<br> +until we were six or so months into an activation attempt (and hence<br> +had the opportunity to judge whether the reasons for not activating<br> +were bad), that would likely be enough time to start implementing some<br> +safety mechanisms.<br> +<br> +But there seems to be much more signficant support for the case 2 than I<br= +> +expected; as evidenced by the "let's do lockinontimeout=3Dtrue imm= +ediately"<br> +advocacy, eg:<br> +<br> +=C2=A0 I am not willing to go to war for Taproot. I'll be honest the re= +ason<br> +=C2=A0 I'm interested at all is that devs I respect spent a lot of ener= +gy and<br> +=C2=A0 time on it and I was reluctant to let their marginally beneficial wo= +rk<br> +=C2=A0 go to waste.<br> +<br> +=C2=A0 I am, however, willing to go to war against LOT=3DFalse.<br> +<br> +=C2=A0 =C2=A0-- <a href=3D"https://twitter.com/francispouliot_/status/13638= +76292169465856" rel=3D"noreferrer noreferrer" target=3D"_blank">https://twi= +tter.com/francispouliot_/status/1363876292169465856</a><br> +<br> +I don't think bip8 is well-designed for that approach: most importantly= +,<br> +with early adoption of lockinontimeout=3Dtrue, bip8 *encourages* a consensu= +s<br> +split in the event that good reasons for not activating are discovered<br> +afterwards, because lockinontimeout=3Dfalse nodes remain able to abandon<br= +> +the activation attempt. Consensus splits are terrible; they should be<br> +a last resort used only in the event that bitcoin's fundamental nature<= +br> +is threatened, not a standard risk if bugs happened to be discovered<br> +late. But additionally, if we are worried miners might not be acting<br> +in the interests of all bitcoin users, there are other games they could<br> +play, such as "if you want X activated quickly, also give us Y; otherw= +ise<br> +we'll delay it as long as possible".<br> +<br> +Losing the opportunity to abandon an activation attempt, by whatever<br> +mechanism, also puts a lot more pressure on being absolutely sure of the<br= +> +desirability of the change at the point when it's merged; because miner= +s,<br> +third-party devs, businesses, and users don't even have the option of<b= +r> +attempting to influence miners, all objections needs to be raised when<br> +the activation parameters are merged, which raises the stakes for that<br> +event substantially.<br> +<br> +I think my conclusions from that are:<br> +<br> +=C2=A0* as it stands, people are expecting to run bip8/lot=3Dtrue nodes on = +the<br> +=C2=A0 =C2=A0network immediately; so deploying bip8/lot=3Dfalse with compat= +ible<br> +=C2=A0 =C2=A0parameters risks causing consensus splits, and should not be d= +one<br> +<br> +=C2=A0* David Harding's "speedy trial" approach probably does= +n't suffer from<br> +=C2=A0 =C2=A0the problems -- running a lot=3Dtrue variant would require enf= +orcing<br> +=C2=A0 =C2=A0signalling prior to the end of July, which is an unreasonable = +timeframe<br> +=C2=A0 =C2=A0to expect the majority of economic nodes to upgrade in; if bip= +9 is<br> +=C2=A0 =C2=A0used, then the risk of enforcement occuring with minority hash= +rate<br> +=C2=A0 =C2=A0(and thus having fewer retarget periods before the timeout is<= +br> +=C2=A0 =C2=A0reached) would also make a bip148/lot=3Dtrue variant difficult= +y<br> +<br> +=C2=A0* if people want a "taproot is guaranteed to activate no later t= +han X"<br> +=C2=A0 =C2=A0PR merged, someone needs to do a *lot* more outreach to be sur= +e that<br> +=C2=A0 =C2=A0that's the right outcome, and it's not just devs/maint= +ainers making<br> +=C2=A0 =C2=A0the call<br> +<br> +=C2=A0* IMO, Matt's proposed approach is both a better and simpler appr= +oach<br> +=C2=A0 =C2=A0to avoid giving miners undue influence on consensus; as such I= +'ve<br> +=C2=A0 =C2=A0drafted up a sample implementation:<br> +<br> +=C2=A0 =C2=A0 =C2=A0<a href=3D"https://github.com/bitcoin/bitcoin/pull/2137= +8" rel=3D"noreferrer noreferrer" target=3D"_blank">https://github.com/bitco= +in/bitcoin/pull/21378</a><br> +<br> +=C2=A0 =C2=A0(Backporting it to 0.21 just requires backporting #19438, whic= +h is<br> +=C2=A0 =C2=A0straightforward)<br> +<br> +So I think that means my preference is to do the "speedy trial" w= +ith<br> +signalling first, and if that fails, then either we've established ther= +e<br> +are real problems with taproot and will go back to the drawing board to<br> +fix them, or if we have not found problems by that time we should simply<br= +> +switch to a straight flag day activation as Matt proposes. Presumably<br> +we'll have established broard community consensus for activation if no<= +br> +objections are discovered during the speedy trial.<br> +<br> +Cheers,<br> +aj<br> +<br> +_______________________________________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" = +rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati= +on.org/mailman/listinfo/bitcoin-dev</a><br> +</blockquote></div> + +--0000000000008e5f2d05bd05e611-- + |