MIME-Version: 1.0
References: <202103152148.15477.luke@dashjr.org>
 <CAJowKgLuWOkD=_jDaLqG=FOG02qX7p4-EZ69yvw4UqcWpz+rRg@mail.gmail.com>
In-Reply-To: <CAJowKgLuWOkD=_jDaLqG=FOG02qX7p4-EZ69yvw4UqcWpz+rRg@mail.gmail.com>
From: Martin Schwarz <martin.schwarz@gmail.com>
Date: Tue, 23 Mar 2021 10:36:32 +0100
Message-ID: <CAKhySQy3BZjPpk17DNedbobG4+VTkQQND_m2X6RhfyOrfkAiJA@mail.gmail.com>
To: Erik Aronesty <erik@q32.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000008c8cab05be30eb33"
Subject: Re: [bitcoin-dev] PSA: Taproot loss of quantum protections
Precedence: list

--0000000000008c8cab05be30eb33
Content-Type: text/plain; charset="UTF-8"

Erik,

> Does anyone think it would it be useful to write up a more official,
and even partly functional plan for Bitcoin to use zero-knowledge
proofs to transition to quantum resistance?

yes, this would be appreciated very much! Andrew Chow's write-up
gives already some high-level idea, but a more detailed exposition
would be essential for further discussion.

thank you,
Martin

On Mon, Mar 22, 2021 at 3:47 PM Erik Aronesty via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> The argument that hashed public addresses provide meaningful quantum
> resistance is flawed *when considered in the context*.of Bitcoin
> itself.
>
> This article by Andrew Chow is easy to read and makes a strong case
> against the quantum utility of hashed public keys:
>
> https://cryptowords.github.io/why-does-hashing-public-keys-not-actually-provide-any-quantum-resistance
>
> And then, of course, one should be mindful of the case against quantum
> computing itself - it is neither inevitable nor "just around the
> corner".   Mikhail Dyakonov summarized the arguments well here:
> https://t.co/cgrfrroTTT?amp=1.
>
> My current stance (at my company at least) is that planning for
> quantum computing should be limited to "a provable and written ability
> to upgrade if it becomes clear that it's necessary."
>
> Does anyone think it would it be useful to write up a more official,
> and even partly functional plan for Bitcoin to use zero-knowledge
> proofs to transition to quantum resistance?
>
> - Erik Aronesty
>   CTO, Atkama
>
> On Mon, Mar 15, 2021 at 5:48 PM Luke Dashjr via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> > I do not personally see this as a reason to NACK Taproot, but it has
> become
> > clear to me over the past week or so that many others are unaware of this
> > tradeoff, so I am sharing it here to ensure the wider community is aware
> of
> > it and can make their own judgements.
> >
> > Mark Friedenbach explains on his blog:
> >     https://freicoin.substack.com/p/why-im-against-taproot
> >
> > In short, Taproot loses an important safety protection against quantum.
> > Note that in all circumstances, Bitcoin is endangered when QC becomes a
> > reality, but pre-Taproot, it is possible for the network to "pause"
> while a
> > full quantum-safe fix is developed, and then resume transacting. With
> Taproot
> > as-is, it could very well become an unrecoverable situation if QC go
> online
> > prior to having a full quantum-safe solution.
> >
> > Also, what I didn't know myself until today, is that we do not actually
> gain
> > anything from this: the features proposed to make use of the raw keys
> being
> > public prior to spending can be implemented with hashed keys as well.
> > It would use significantly more CPU time and bandwidth (between private
> > parties, not on-chain), but there should be no shortage of that for
> anyone
> > running a full node (indeed, CPU time is freed up by Taproot!); at
> worst, it
> > would create an incentive for more people to use their own full node,
> which
> > is a good thing!
> >
> > Despite this, I still don't think it's a reason to NACK Taproot: it
> should be
> > fairly trivial to add a hash on top in an additional softfork and fix
> this.
> >
> > In addition to the points made by Mark, I also want to add two more, in
> > response to Pieter's "you can't claim much security if 37% of the supply
> is
> > at risk" argument. This argument is based in part on the fact that many
> > people reuse Bitcoin invoice addresses.
> >
> > First, so long as we have hash-based addresses as a best practice, we can
> > continue to shrink the percentage of bitcoins affected through social
> efforts
> > discouraging address use. If the standard loses the hash, the situation
> > cannot be improved, and will indeed only get worse.
> >
> > Second, when/if quantum does compromise these coins, so long as they are
> > neglected or abandoned/lost coins (inherent in the current model), it
> can be
> > seen as equivalent to Bitcoin mining. At the end of the day, 37% of
> supply
> > minable by QCs is really no different than 37% minable by ASICs. (We've
> seen
> > far higher %s available for mining obviously.)
> >
> > To conclude, I recommend anyone using Bitcoin to read Mark's article, my
> > thoughts, and any other arguments on the topic; decide if this is a
> concern
> > to you, and make your own post(s) accordingly. Mark has conceded the
> argument
> > (AFAIK he doesn't have an interest in bitcoins anyway), and I do not
> consider
> > it a showstopper - so if anyone else out there does, please make yourself
> > known ASAP since Taproot has already moved on to the activation phase
> and it
> > is likely software will be released within the next month or two as
> things
> > stand.
> >
> > Luke
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div>Erik,</div><div><br></div>&gt;

Does anyone think it would it be useful to write up a more official,<br>and=
 even partly functional plan for Bitcoin to use=C2=A0<span class=3D"gmail-i=
l">zero</span>-<span class=3D"gmail-il">knowledge</span><br>proofs to trans=
ition to=C2=A0<span class=3D"gmail-il">quantum</span>=C2=A0resistance?<div>=
<br></div><div>yes, this would be appreciated very much! Andrew Chow&#39;s =
write-up=C2=A0</div><div>gives already some high-level idea, but a more det=
ailed exposition</div><div>would be essential for further discussion.</div>=
<div><br></div><div>thank you,</div><div>Martin</div></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Mar 22, 2021=
 at 3:47 PM Erik Aronesty via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev=
@lists.linuxfoundation.org">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">The argume=
nt that hashed public addresses provide meaningful quantum<br>
resistance is flawed *when considered in the context*.of Bitcoin<br>
itself.<br>
<br>
This article by Andrew Chow is easy to read and makes a strong case<br>
against the quantum utility of hashed public keys:<br>
<a href=3D"https://cryptowords.github.io/why-does-hashing-public-keys-not-a=
ctually-provide-any-quantum-resistance" rel=3D"noreferrer" target=3D"_blank=
">https://cryptowords.github.io/why-does-hashing-public-keys-not-actually-p=
rovide-any-quantum-resistance</a><br>
<br>
And then, of course, one should be mindful of the case against quantum<br>
computing itself - it is neither inevitable nor &quot;just around the<br>
corner&quot;.=C2=A0 =C2=A0Mikhail Dyakonov summarized the arguments well he=
re:<br>
<a href=3D"https://t.co/cgrfrroTTT?amp=3D1" rel=3D"noreferrer" target=3D"_b=
lank">https://t.co/cgrfrroTTT?amp=3D1</a>.<br>
<br>
My current stance (at my company at least) is that planning for<br>
quantum computing should be limited to &quot;a provable and written ability=
<br>
to upgrade if it becomes clear that it&#39;s necessary.&quot;<br>
<br>
Does anyone think it would it be useful to write up a more official,<br>
and even partly functional plan for Bitcoin to use zero-knowledge<br>
proofs to transition to quantum resistance?<br>
<br>
- Erik Aronesty<br>
=C2=A0 CTO, Atkama<br>
<br>
On Mon, Mar 15, 2021 at 5:48 PM Luke Dashjr via bitcoin-dev<br>
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt;<br>
&gt; I do not personally see this as a reason to NACK Taproot, but it has b=
ecome<br>
&gt; clear to me over the past week or so that many others are unaware of t=
his<br>
&gt; tradeoff, so I am sharing it here to ensure the wider community is awa=
re of<br>
&gt; it and can make their own judgements.<br>
&gt;<br>
&gt; Mark Friedenbach explains on his blog:<br>
&gt;=C2=A0 =C2=A0 =C2=A0<a href=3D"https://freicoin.substack.com/p/why-im-a=
gainst-taproot" rel=3D"noreferrer" target=3D"_blank">https://freicoin.subst=
ack.com/p/why-im-against-taproot</a><br>
&gt;<br>
&gt; In short, Taproot loses an important safety protection against quantum=
.<br>
&gt; Note that in all circumstances, Bitcoin is endangered when QC becomes =
a<br>
&gt; reality, but pre-Taproot, it is possible for the network to &quot;paus=
e&quot; while a<br>
&gt; full quantum-safe fix is developed, and then resume transacting. With =
Taproot<br>
&gt; as-is, it could very well become an unrecoverable situation if QC go o=
nline<br>
&gt; prior to having a full quantum-safe solution.<br>
&gt;<br>
&gt; Also, what I didn&#39;t know myself until today, is that we do not act=
ually gain<br>
&gt; anything from this: the features proposed to make use of the raw keys =
being<br>
&gt; public prior to spending can be implemented with hashed keys as well.<=
br>
&gt; It would use significantly more CPU time and bandwidth (between privat=
e<br>
&gt; parties, not on-chain), but there should be no shortage of that for an=
yone<br>
&gt; running a full node (indeed, CPU time is freed up by Taproot!); at wor=
st, it<br>
&gt; would create an incentive for more people to use their own full node, =
which<br>
&gt; is a good thing!<br>
&gt;<br>
&gt; Despite this, I still don&#39;t think it&#39;s a reason to NACK Taproo=
t: it should be<br>
&gt; fairly trivial to add a hash on top in an additional softfork and fix =
this.<br>
&gt;<br>
&gt; In addition to the points made by Mark, I also want to add two more, i=
n<br>
&gt; response to Pieter&#39;s &quot;you can&#39;t claim much security if 37=
% of the supply is<br>
&gt; at risk&quot; argument. This argument is based in part on the fact tha=
t many<br>
&gt; people reuse Bitcoin invoice addresses.<br>
&gt;<br>
&gt; First, so long as we have hash-based addresses as a best practice, we =
can<br>
&gt; continue to shrink the percentage of bitcoins affected through social =
efforts<br>
&gt; discouraging address use. If the standard loses the hash, the situatio=
n<br>
&gt; cannot be improved, and will indeed only get worse.<br>
&gt;<br>
&gt; Second, when/if quantum does compromise these coins, so long as they a=
re<br>
&gt; neglected or abandoned/lost coins (inherent in the current model), it =
can be<br>
&gt; seen as equivalent to Bitcoin mining. At the end of the day, 37% of su=
pply<br>
&gt; minable by QCs is really no different than 37% minable by ASICs. (We&#=
39;ve seen<br>
&gt; far higher %s available for mining obviously.)<br>
&gt;<br>
&gt; To conclude, I recommend anyone using Bitcoin to read Mark&#39;s artic=
le, my<br>
&gt; thoughts, and any other arguments on the topic; decide if this is a co=
ncern<br>
&gt; to you, and make your own post(s) accordingly. Mark has conceded the a=
rgument<br>
&gt; (AFAIK he doesn&#39;t have an interest in bitcoins anyway), and I do n=
ot consider<br>
&gt; it a showstopper - so if anyone else out there does, please make yours=
elf<br>
&gt; known ASAP since Taproot has already moved on to the activation phase =
and it<br>
&gt; is likely software will be released within the next month or two as th=
ings<br>
&gt; stand.<br>
&gt;<br>
&gt; Luke<br>
&gt; _______________________________________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org=
/mailman/listinfo/bitcoin-dev</a><br>
_______________________________________________<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>

--0000000000008c8cab05be30eb33--