path: root/19/b90691a344352b378af34c32cd8cc12e3d9a60

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&#39;m bein=
g frank, you were not clear about what you advocated for, you didn&#39;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&#39;re quite a bit more difficult to communicate with than the averag=
e bitcoin-dev user, and I&#39;d suggest that if you want your concerns addr=
essed, you figure out how to interact more constructively with people on he=
re. You&#39;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&#39;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&#39;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&#39=
;Connor via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfounda=
tion.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; 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 &lt;=
<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 &quot;no-diverg=
ent-rules&quot; faction doesn&#39;t like it, so we can pretend we have list=
ened to this &quot;faction&quot; and addressed all its concerns, I guess.</=
div><div dir=3D"auto">Or perhaps it&#39;s just &quot;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&#39;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&#39;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">&quot;But that may lead to a fork&quot=
;. 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=
 &quot;not activated&quot;, 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=
&#39;t talking about activation, but quantum computing concerns. Perhaps th=
ose have been &quot;addressed&quot;?</div><div dir=3D"auto">I just don&#39;=
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&#39;t use=
 taproot addresses, and (2) If you are worried about everyone else&#39;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 &lt;<a href=3D"https://nitter.net/pwuille/status/11080919=
24404027392" target=3D"_blank">https://nitter.net/pwuille/status/1108091924=
404027392</a>&gt;.=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=
 &lt;<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>&gt; 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--