diff options
author | Billy Tetrud <billy.tetrud@gmail.com> | 2022-03-11 10:26:21 -0600 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2022-03-11 16:26:41 +0000 |
commit | dbfeaa99e127a0638980e0080558d122b1f1f8da (patch) | |
tree | ff2c84b845633475f3e8eb9c0f34e4beb6dff4e8 | |
parent | 47cded49c710e6fabd351b2dbae3b3cde33fbb58 (diff) | |
download | pi-bitcoindev-dbfeaa99e127a0638980e0080558d122b1f1f8da.tar.gz pi-bitcoindev-dbfeaa99e127a0638980e0080558d122b1f1f8da.zip |
Re: [bitcoin-dev] Speedy Trial
-rw-r--r-- | 19/b90691a344352b378af34c32cd8cc12e3d9a60 | 345 |
1 files changed, 345 insertions, 0 deletions
diff --git a/19/b90691a344352b378af34c32cd8cc12e3d9a60 b/19/b90691a344352b378af34c32cd8cc12e3d9a60 new file mode 100644 index 000000000..e3e565297 --- /dev/null +++ b/19/b90691a344352b378af34c32cd8cc12e3d9a60 @@ -0,0 +1,345 @@ +Return-Path: <fresheneesz@gmail.com> +Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 83384C000B + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 11 Mar 2022 16:26:41 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp3.osuosl.org (Postfix) with ESMTP id 80CF360A8B + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 11 Mar 2022 16:26:41 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -2.098 +X-Spam-Level: +X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 + tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, + DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, + HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, + SPF_PASS=-0.001] autolearn=ham autolearn_force=no +Authentication-Results: smtp3.osuosl.org (amavisd-new); + dkim=pass (2048-bit key) header.d=gmail.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 XqsybBE9p6QN + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 11 Mar 2022 16:26:40 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.8.0 +Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com + [IPv6:2a00:1450:4864:20::632]) + by smtp3.osuosl.org (Postfix) with ESMTPS id D6A2360A75 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 11 Mar 2022 16:26:39 +0000 (UTC) +Received: by mail-ej1-x632.google.com with SMTP id qt6so20161499ejb.11 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 11 Mar 2022 08:26:39 -0800 (PST) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; + h=mime-version:references:in-reply-to:from:date:message-id:subject:to; + bh=NiU2i34WiE+NiP+APfmYFe0DYfFPM2/qfuSlNsh0sto=; + b=OwdR8zKYMrkgrTeG2LWX0x7sSNrUeo1UL56s7nZGEPVpZMJ2OsQ+py82fTo3d8LG02 + ZTZ1W5oneh8EdKR1Upg6yDg8Kmf+04iRVX42bY5UdlELOYfS6v/9V8K+A+mBAlM9vuNT + uUa0UdIo2HjxlJ36IudxR3xBNqutoT7BBters166HafVQJ4fZKEsoTCFUn3hrPwSJTX9 + 9/cjWUO4kzzEdCceGfvazM2FeXtYXz0h0wxOvKt41cfRJSoosxAJ/fnkSzaFx5grMj7p + x5+jpJJFRLt8nAuhckMcGW7/w/4Y/SNAcJZVMPIudWhNsXDWYK4Qhhrn+DB7m/QdFwtv + OeAQ== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20210112; + h=x-gm-message-state:mime-version:references:in-reply-to:from:date + :message-id:subject:to; + bh=NiU2i34WiE+NiP+APfmYFe0DYfFPM2/qfuSlNsh0sto=; + b=56l1Wx8AqO1AvxNUKapef3FC/GZtVKWdjZWXTJVnMSXBvRjuYIbuidYPOEGWw477eY + VZ1ExN+4f0DqSpb/lDBAzMdc0vugOXCwzbwMM19mVzO2JYZgLpkmf5eDi8FD1Hze04n+ + Vg9fRD4tYuDeOHov62BVusKcPvjbBXYcDTAzgd3dVKhy1nvWh35iK/xsMdOSCVu7dcTP + XnP2chhwoiAY3oHlpfptOADB9/siv7Q/fNkz9STm9nohagwlWoAZyIFFnaZ3oG5zGIkN + RpaihSjf+rMthJDqGngT4gH+bZKcTyMxQTyXbVmK6iM1chbfdx7fy5dMmq9FSAM8/a0+ + 6oCA== +X-Gm-Message-State: AOAM532+u7JVxceaXNs6UK7VrZmtWobIusq5YM2JgpUFU4XXb73hkA9e + 6bsMUHw5O5M3MIedRUU4uLdVfDrUseJJacXDLyXebyM8 +X-Google-Smtp-Source: ABdhPJwgcG+s+7ofW2SaR+lV7aaoey5fpkRrbl+B6q5DQKX/JTVy0KjA0gfBX7FUF4dbiaP7/6WQuSIZNeE+8PBGMm0= +X-Received: by 2002:a17:906:9741:b0:6da:c274:6b18 with SMTP id + o1-20020a170906974100b006dac2746b18mr9095399ejy.207.1647015997822; Fri, 11 + Mar 2022 08:26:37 -0800 (PST) +MIME-Version: 1.0 +References: <CAMZUoKkTDjDSgnqhYio8Lnh-yTdsNAdXbDC9RQwnN00RdbbL6w@mail.gmail.com> + <CABm2gDrdoD3QZ=gZ_nd7Q+AZpetX32dLON7pfdC4aAwpLRd4xA@mail.gmail.com> + <CAMZUoK=kpZZw++WmdRM0KTkj6dQhmtsanm9eH1TksNwypKS8Zw@mail.gmail.com> +In-Reply-To: <CAMZUoK=kpZZw++WmdRM0KTkj6dQhmtsanm9eH1TksNwypKS8Zw@mail.gmail.com> +From: Billy Tetrud <billy.tetrud@gmail.com> +Date: Fri, 11 Mar 2022 10:26:21 -0600 +Message-ID: <CAGpPWDZWKF=r4fQP8+JSBaUHT9ZTFYn7RKUgApMx4sys6Cx7Xg@mail.gmail.com> +To: "Russell O'Connor" <roconnor@blockstream.com>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: multipart/alternative; boundary="0000000000007d5d5b05d9f3cb15" +X-Mailman-Approved-At: Fri, 11 Mar 2022 16:32:18 +0000 +Subject: Re: [bitcoin-dev] Speedy Trial +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: Fri, 11 Mar 2022 16:26:41 -0000 + +--0000000000007d5d5b05d9f3cb15 +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +Thanks for pointing out that PR @pushd. Looks like pretty good evidence for +what the status of consensus was around BIP8 in the last 2 years. + +@Jorge, I tried to engage with you on the topic of activation rules last +year. This is where we left it +<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019172.h= +tml>. +If I'm being frank, you were not clear about what you advocated for, you +didn't seem to take the time to understand what I was advocating for and +what I was asking you and trying to discuss with you, and you ghosted some +of my questions to you. I think you have some ideas that are important to +consider, but you're quite a bit more difficult to communicate with than +the average bitcoin-dev user, and I'd suggest that if you want your +concerns addressed, you figure out how to interact more constructively with +people on here. You're being very defensive and adversarial. Please take a +step back and try to be more objective. That is IHMO the best way for your +thoughts to be heard and understood. + +I think involving users more in activation is a good avenue of thought for +improving how bitcoin does soft forks. I also think the idea you brought up +of some way for people to signal opposition is a good idea. I've suggested +a mechanism for signature-based user polling +<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/019022.ht= +ml>, +I've also suggested a mechanism +<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019117.h= +tml> +where miners can actively signal for opposing a soft fork. It seems like +there should be some common ground between us in those ideas. Where it +seems we may perhaps unreconcilably disagree are that A. miners are users +too and generally have interests that are important and different than most +users, and giving them at least some mechanism to force discussion is +appropriate, and B. chain splits are no joke and should almost never be +possible accidentally and therefore we should make a significant effort to +avoid them, which almost definitely means orderly coordination of miners. + +Do you have anything concrete you want to propose? An example mechanism? +Are you simply here advocating your support for BIP8+LOT=3Dtrue? + + +On Fri, Mar 11, 2022 at 7:47 AM Russell O'Connor via bitcoin-dev < +bitcoin-dev@lists.linuxfoundation.org> wrote: + +> On Fri, Mar 11, 2022 at 7:18 AM Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote= +: +> +>> I talked about this. But the "no-divergent-rules" faction doesn't like +>> it, so we can pretend we have listened to this "faction" and addressed a= +ll +>> its concerns, I guess. +>> Or perhaps it's just "prosectution complex", but, hey, what do I know +>> about psychology? +>> +> +> Your accusations of bad faith on the part of myself and pretty much +> everyone else makes me disinclined to continue this discussion with you. +> I'll reply, but if you want me to continue beyond this, then you need to +> knock it off with the accusations. +> +> +>> A major contender to the Speedy Trial design at the time was to mandate +>>> eventual forced signalling, championed by luke-jr. It turns out that, = +at +>>> the time of that proposal, a large amount of hash power simply did not = +have +>>> the firmware required to support signalling. That activation proposal +>>> never got broad consensus, and rightly so, because in retrospect we see +>>> that the design might have risked knocking a significant fraction of mi= +ning +>>> power offline if it had been deployed. Imagine if the firmware couldn'= +t be +>>> quickly updated or imagine if the problem had been hardware related. +>>> +>> +>> Yes, I like this solution too, with a little caveat: an easy mechanism +>> for users to actively oppose a proposal. +>> Luke alao talked about this. +>> If users oppose, they should use activation as a trigger to fork out of +>> the network by invalidating the block that produces activation. +>> The bad scenario here is that miners want to deploy something but users +>> don't want to. +>> "But that may lead to a fork". Yeah, I know. +>> I hope imagining a scenario in which developers propose something that +>> most miners accept but some users reject is not taboo. +>> +> +> This topic is not taboo. +> +> There are a couple of ways of opting out of taproot. Firstly, users can +> just not use taproot. Secondly, users can choose to not enforce taproot +> either by running an older version of Bitcoin Core or otherwise forking t= +he +> source code. Thirdly, if some users insist on a chain where taproot is +> "not activated", they can always softk-fork in their own rule that +> disallows the version bits that complete the Speedy Trial activation +> sequence, or alternatively soft-fork in a rule to make spending from (or +> to) taproot addresses illegal. +> +> As for mark, he wasn't talking about activation, but quantum computing +>> concerns. Perhaps those have been "addressed"? +>> I just don't know where. +>> +> +> Quantum concerns were discussed. Working from memory, the arguments were +> (1) If you are worried about your funds not being secured by taproot, the= +n +> don't use taproot addresses, and (2) If you are worried about everyone +> else's funds not being quantum secure by other people choosing to use +> taproot, well it is already too late because over 5M BTC is currently +> quantum insecure due to pubkey reuse < +> https://nitter.net/pwuille/status/1108091924404027392>. I think it is +> unlikely that a quantum breakthrough will sneak up on us without time to +> address the issue and, at the very least, warn people to move their funds +> off of taproot and other reused addresses, if not forking in some quantum +> secure alternative. A recent paper < +> https://www.sussex.ac.uk/physics/iqt/wp-content/uploads/2022/01/Webber-20= +22.pdf> +> suggest that millions physical qubits will be needed to break EC in a day +> with current error correction technology. But even if taproot were to be +> very suddenly banned, there is still a small possibility for recovery +> because one can prove ownership of HD pubkeys by providing a zero-knowled= +ge +> proof of the chaincode used to derive them. +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +> + +--0000000000007d5d5b05d9f3cb15 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div dir=3D"ltr">Thanks for pointing out that PR @pushd. L= +ooks like pretty good evidence=C2=A0for what the status of consensus was ar= +ound BIP8 in the last 2 years.</div><div dir=3D"ltr"><br></div><div>@Jorge,= + I tried to engage with you on the topic of activation rules last year. Thi= +s is <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/202= +1-June/019172.html" target=3D"_blank">where we left it</a>. If I'm bein= +g frank, you were not clear about what you advocated for, you didn't se= +em to take the time to understand what I was advocating for and what I was = +asking you and trying to discuss with you, and you ghosted some of my quest= +ions to you. I think you have some ideas that are important to consider, bu= +t you're quite a bit more difficult to communicate with than the averag= +e bitcoin-dev user, and I'd suggest that if you want your concerns addr= +essed, you figure out how to interact more constructively with people on he= +re. You're being very defensive and adversarial. Please take a step bac= +k and try to be more objective. That is IHMO the best way for your thoughts= + to be heard and understood.=C2=A0</div><div><br></div><div>I think involvi= +ng users more in activation is a good avenue=C2=A0of thought for improving = +how bitcoin does soft forks. I also think the idea you brought up of some w= +ay for people to signal opposition is a good idea. I've suggested a mec= +hanism for <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-d= +ev/2021-May/019022.html" target=3D"_blank">signature-based user polling</a>= +, I've also suggested <a href=3D"https://lists.linuxfoundation.org/pipe= +rmail/bitcoin-dev/2021-June/019117.html" target=3D"_blank">a mechanism</a> = +where miners can actively signal for opposing a soft fork. It seems like th= +ere should be some common ground between us in those ideas. Where it seems = +we may perhaps unreconcilably=C2=A0disagree are that A. miners are users to= +o and generally have interests that are important and different than most u= +sers, and giving them at least some mechanism to force discussion is approp= +riate, and B. chain splits are no joke and should almost never be possible = +accidentally and therefore we should make a significant effort to avoid the= +m, which almost definitely means orderly coordination of miners.=C2=A0</div= +><div><br></div><div>Do you have anything concrete you want to propose? An = +example mechanism? Are you simply here advocating your support for BIP8+LOT= +=3Dtrue?=C2=A0</div><div><br></div><br><div class=3D"gmail_quote"><div dir= +=3D"ltr" class=3D"gmail_attr">On Fri, Mar 11, 2022 at 7:47 AM Russell O'= +;Connor via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfounda= +tion.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>> w= +rote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p= +x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir= +=3D"ltr"><div dir=3D"ltr"></div><div class=3D"gmail_quote"><div dir=3D"ltr"= + class=3D"gmail_attr">On Fri, Mar 11, 2022 at 7:18 AM Jorge Tim=C3=B3n <= +<a href=3D"mailto:jtimon@jtimon.cc" target=3D"_blank">jtimon@jtimon.cc</a>&= +gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0= +px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div = +dir=3D"auto"><div dir=3D"auto">I talked about this. But the "no-diverg= +ent-rules" faction doesn't like it, so we can pretend we have list= +ened to this "faction" and addressed all its concerns, I guess.</= +div><div dir=3D"auto">Or perhaps it's just "prosectution complex&q= +uot;, but, hey, what do I know about psychology? <br></div></div></blockquo= +te><div><br></div><div>Your accusations of bad faith on the part of myself = +and pretty much everyone else makes me disinclined to continue this discuss= +ion with you.=C2=A0 I'll reply, but if you want me to continue beyond t= +his, then you need to knock it off with the accusations.=C2=A0 <br></div><d= +iv>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p= +x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir= +=3D"auto"><div dir=3D"auto"></div><div dir=3D"auto"><div class=3D"gmail_quo= +te"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor= +der-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"auto"><di= +v dir=3D"auto">A major contender to the Speedy Trial design at the time was= + to mandate eventual forced signalling, championed by luke-jr.=C2=A0 It tur= +ns out that, at the time of that proposal, a large amount of hash power sim= +ply did not have the firmware required to support signalling.=C2=A0 That ac= +tivation proposal never got broad consensus, and rightly so, because in ret= +rospect we see that the design might have risked knocking a significant fra= +ction of mining power offline if it had been deployed.=C2=A0 Imagine if the= + firmware couldn't be quickly updated or imagine if the problem had bee= +n hardware related.</div></div></blockquote></div></div><div dir=3D"auto"><= +br></div><div dir=3D"auto">Yes, I like this solution too, with a little cav= +eat: an easy mechanism for users to actively oppose a proposal.</div><div d= +ir=3D"auto">Luke alao talked about this.</div><div dir=3D"auto">If users op= +pose, they should use activation as a trigger to fork out of the network by= + invalidating the block that produces activation.</div><div dir=3D"auto">Th= +e bad scenario here is that miners want to deploy something but users don&#= +39;t want to.</div><div dir=3D"auto">"But that may lead to a fork"= +;. Yeah, I know.</div><div dir=3D"auto">I hope imagining a scenario in whic= +h developers propose something that most miners accept but some users rejec= +t is not taboo.</div></div></blockquote><div><br></div><div>This topic is n= +ot taboo.<br></div><div><br></div><div><div>There are a couple of ways of o= +pting out of taproot.=C2=A0 Firstly, users can just=20 +not use taproot.=C2=A0 Secondly, users can choose to not enforce taproot ei= +ther by running an older version of Bitcoin Core or otherwise forking the s= +ource code.=C2=A0 Thirdly, if some users insist on a chain where taproot is= + "not activated", they can always softk-fork in their own rule th= +at disallows + the version bits that complete the Speedy Trial activation sequence, or al= +ternatively soft-fork in a rule to make spending from (or to) taproot addre= +sses illegal.<br></div><div><br></div></div><blockquote class=3D"gmail_quot= +e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)= +;padding-left:1ex"><div dir=3D"auto"><div dir=3D"auto">As for mark, he wasn= +'t talking about activation, but quantum computing concerns. Perhaps th= +ose have been "addressed"?</div><div dir=3D"auto">I just don'= +t know where.</div></div></blockquote><div><br></div><div>Quantum concerns = +were discussed.=C2=A0 Working from memory, the arguments were (1) If you ar= +e worried about your funds not being secured by taproot, then don't use= + taproot addresses, and (2) If you are worried about everyone else's fu= +nds not being quantum secure by other people choosing to use taproot, well = +it is already too late because over 5M BTC is currently quantum insecure du= +e to pubkey reuse <<a href=3D"https://nitter.net/pwuille/status/11080919= +24404027392" target=3D"_blank">https://nitter.net/pwuille/status/1108091924= +404027392</a>>.=C2=A0 I think it is unlikely that a quantum breakthrough= + will sneak up on us without time to address the issue and, at the very lea= +st, warn people to move their funds off of taproot and other reused address= +es, if not forking in some quantum secure alternative.=C2=A0 A recent paper= + <<a href=3D"https://www.sussex.ac.uk/physics/iqt/wp-content/uploads/202= +2/01/Webber-2022.pdf" target=3D"_blank">https://www.sussex.ac.uk/physics/iq= +t/wp-content/uploads/2022/01/Webber-2022.pdf</a>> suggest that millions = +physical qubits will be needed to break EC in a day with current error corr= +ection technology.=C2=A0 But even if taproot were to be very suddenly banne= +d, there is still a small possibility for recovery because one can prove ow= +nership of HD pubkeys by providing a zero-knowledge proof of the chaincode = +used to derive them.<br></div></div></div> +_______________________________________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= +bitcoin-dev@lists.linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= +man/listinfo/bitcoin-dev</a><br> +</blockquote></div></div> + +--0000000000007d5d5b05d9f3cb15-- + |