path: root/e4/d2380db2da4aca26adbc88adfae9970d61d364

Return-Path: <roconnor@blockstream.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id BCDE0C000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 11 Mar 2022 13:47:28 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 9DC98611FA
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 11 Mar 2022 13:47:28 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 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=blockstream-com.20210112.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 6LsZ03yVVuhK
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 11 Mar 2022 13:47:27 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com
 [IPv6:2607:f8b0:4864:20::72b])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 614F9611D9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 11 Mar 2022 13:47:27 +0000 (UTC)
Received: by mail-qk1-x72b.google.com with SMTP id h196so6945021qke.12
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 11 Mar 2022 05:47:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=blockstream-com.20210112.gappssmtp.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=xx6OeOX+D0sD7Udkd30VwRiYe51NihQjE8+Mdbi+Z4I=;
 b=WNAD8ak9C/qscP7sCA9DF5AipIBvZxBpL1Xu/GhHEr21j+JzoGhkpZ7ocQ3bqHnWpO
 qqjquvaKKG3gdRoD7zdQmh69csUP9Sk0YiPKJxrxhXay5uRmGrPXOh1LgCp4DyyND1LU
 dHaTvw0wKx74m0WqRCYqrHXjV8O83kqUkeyCPbX98dWeKa6CrGF5hb1ObgRFCnlHvwQZ
 /nAGkj/YLMV5OMN2XTyBm1AbwmcYoTXmR5/j+Lkkgr9ryCKcEOq98Udh/6ZrhPWH6y7e
 kX5Hdssi7ON2qDiqk1ooFSqsWPr2insb5zL1ZHdOgRUrt9CQJeIFtq9VOY1y6zCa4M8C
 sLIw==
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=xx6OeOX+D0sD7Udkd30VwRiYe51NihQjE8+Mdbi+Z4I=;
 b=wlGKVJaLrfPhsCv6qhWniUG+f2YvAJLqtWTxKkUSyY5xxBFgFGFA+ib7eHmj8P2uhA
 mGm+Wkv2gMVhVkRlyhoepCtSmg1aI2MuCkLp+IPFTPHYD4iC3L0qKJXWYRIKG9N0zmD5
 PxtBrqMh89ruXpGL/rtrKCsmOL9DPiPC+CQCuL5pc0/Vi+KG/BDhsScS1nl6oO7jGYge
 hgp9OpaPmkph5EW0UEG4qJ8Ep61N/DUUNLW0PovYkAX9Jj4WwNb2CBUQJhWieK0HlNGw
 sth9bXYrxZrDCMpJ9lHhXGZXWYH6+ZNaYfJnb8Ih+wcfSQL3qGODiGM2oPV56KtfA8dQ
 W9rg==
X-Gm-Message-State: AOAM531Abk6s90xXEQ/B6JgpABGeGRAMoxYkDNdGgRXIqOJ5Hrb4Wbsf
 X5waRcEPY7KLfJFA6ioh87l4gycMlq3n1RldHcoeAh7assDdMIyN
X-Google-Smtp-Source: ABdhPJykLypUVcr3a5NO/ZxsmtZf1rGqFTkaBH2rSPZPTGTawYX1s7B4ZjYjbt6UCAf/XZjkev9v7SleJNZidmW1Hyk=
X-Received: by 2002:a37:bcf:0:b0:60d:ed93:67a1 with SMTP id
 198-20020a370bcf000000b0060ded9367a1mr6425134qkl.548.1647006445930; Fri, 11
 Mar 2022 05:47:25 -0800 (PST)
MIME-Version: 1.0
References: <CAMZUoKkTDjDSgnqhYio8Lnh-yTdsNAdXbDC9RQwnN00RdbbL6w@mail.gmail.com>
 <CABm2gDrdoD3QZ=gZ_nd7Q+AZpetX32dLON7pfdC4aAwpLRd4xA@mail.gmail.com>
In-Reply-To: <CABm2gDrdoD3QZ=gZ_nd7Q+AZpetX32dLON7pfdC4aAwpLRd4xA@mail.gmail.com>
From: "Russell O'Connor" <roconnor@blockstream.com>
Date: Fri, 11 Mar 2022 08:47:14 -0500
Message-ID: <CAMZUoK=kpZZw++WmdRM0KTkj6dQhmtsanm9eH1TksNwypKS8Zw@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000027231b05d9f19218"
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 13:47:28 -0000

--00000000000027231b05d9f19218
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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 all it=
s
> 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, a=
t
>> the time of that proposal, a large amount of hash power simply did not h=
ave
>> 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 min=
ing
>> 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 fo=
r
> 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 the
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, then
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-2022=
.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-knowledge
proof of the chaincode used to derive them.

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

<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">jtimon@jtimon.cc</a>&gt; wrote=
:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"au=
to"><div dir=3D"auto">I talked about this. But the &quot;no-divergent-rules=
&quot; faction doesn&#39;t like it, so we can pretend we have listened to t=
his &quot;faction&quot; and addressed all its concerns, I guess.</div><div =
dir=3D"auto">Or perhaps it&#39;s just &quot;prosectution complex&quot;, but=
, hey, what do I know about psychology? <br></div></div></blockquote><div><=
br></div><div>Your accusations of bad faith on the part of myself and prett=
y much everyone else makes me disinclined to continue this discussion with =
you.=C2=A0 I&#39;ll reply, but if you want me to continue beyond this, then=
 you need to knock it off with the accusations.=C2=A0 <br></div><div>=C2=A0=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-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_quote"><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex"><div dir=3D"auto"><div dir=3D"au=
to">A major contender to the Speedy Trial design at the time was to mandate=
 eventual forced signalling, championed by luke-jr.=C2=A0 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.=C2=A0 That activation pr=
oposal 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.=C2=A0 Imagine if the firmware c=
ouldn&#39;t be quickly updated or imagine if the problem had been hardware =
related.</div></div></blockquote></div></div><div dir=3D"auto"><br></div><d=
iv dir=3D"auto">Yes, I like this solution too, with a little caveat: an eas=
y mechanism for users to actively oppose a proposal.</div><div dir=3D"auto"=
>Luke alao talked about this.</div><div dir=3D"auto">If users oppose, they =
should use activation as a trigger to fork out of the network by invalidati=
ng the block that produces activation.</div><div dir=3D"auto">The bad scena=
rio here is that miners want to deploy something but users don&#39;t want t=
o.</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 which developer=
s propose something that most miners accept but some users reject is not ta=
boo.</div></div></blockquote><div><br></div><div>This topic is not taboo.<b=
r></div><div><br></div><div><div>There are a couple of ways of opting out o=
f 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">https://nitter.net/pwuille/status/1108091924404027392</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 least, warn people to=
 move their funds off of taproot and other reused addresses, if not forking=
 in some quantum secure alternative.=C2=A0 A recent paper &lt;<a href=3D"ht=
tps://www.sussex.ac.uk/physics/iqt/wp-content/uploads/2022/01/Webber-2022.p=
df">https://www.sussex.ac.uk/physics/iqt/wp-content/uploads/2022/01/Webber-=
2022.pdf</a>&gt; suggest that millions physical qubits will be needed to br=
eak EC in a day with current error correction technology.=C2=A0 But even if=
 taproot were to be very suddenly banned, there is still a small possibilit=
y for recovery because one can prove ownership of HD pubkeys by providing a=
 zero-knowledge proof of the chaincode used to derive them.<br></div></div>=
</div>

--00000000000027231b05d9f19218--