path: root/83/0764406ada6233d1d516626364e8f2b7df0f43

Return-Path: <jlrubin@mit.edu>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 5FA65C0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 15 Mar 2021 22:40:22 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 5ADB48319F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 15 Mar 2021 22:40:22 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.519
X-Spam-Level: 
X-Spam-Status: No, score=-1.519 tagged_above=-999 required=5
 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3,
 RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id lw_x0GR2Go90
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 15 Mar 2021 22:40:20 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
 by smtp1.osuosl.org (Postfix) with ESMTPS id ADD5283168
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 15 Mar 2021 22:40:20 +0000 (UTC)
Received: from mail-io1-f42.google.com (mail-io1-f42.google.com
 [209.85.166.42]) (authenticated bits=0)
 (User authenticated as jlrubin@ATHENA.MIT.EDU)
 by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 12FMeItS008635
 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
 for <bitcoin-dev@lists.linuxfoundation.org>; Mon, 15 Mar 2021 18:40:19 -0400
Received: by mail-io1-f42.google.com with SMTP id n132so35177115iod.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 15 Mar 2021 15:40:19 -0700 (PDT)
X-Gm-Message-State: AOAM5323p9/jRcVeoUzuB4IX0ISnWbZjETSs3IkySr+0moFNEvY019LG
 y+Ii3TT8qnS5jldcpoSfTlpwdRbgveO+HVxYLFs=
X-Google-Smtp-Source: ABdhPJy2J5vHWrOE+6MQ6DSeTWVlqquedgeCs6PsyXmrNAw+R0BapSPhJA8F4WsVPMaHxuySql9QJHY1U+chm3XRk8U=
X-Received: by 2002:a02:93e9:: with SMTP id z96mr12008177jah.73.1615848018383; 
 Mon, 15 Mar 2021 15:40:18 -0700 (PDT)
MIME-Version: 1.0
References: <202103152148.15477.luke@dashjr.org>
 <a88cd471-fdc9-de35-86cd-595b387249c8@mattcorallo.com>
In-Reply-To: <a88cd471-fdc9-de35-86cd-595b387249c8@mattcorallo.com>
From: Jeremy <jlrubin@mit.edu>
Date: Mon, 15 Mar 2021 15:40:07 -0700
X-Gmail-Original-Message-ID: <CAD5xwhi82fjRB4Ceb6Gnp+LvTweWjwFRmWU5zD-3o6s_GoEvPw@mail.gmail.com>
Message-ID: <CAD5xwhi82fjRB4Ceb6Gnp+LvTweWjwFRmWU5zD-3o6s_GoEvPw@mail.gmail.com>
To: Matt Corallo <lf-lists@mattcorallo.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000002597f905bd9aef04"
Subject: Re: [bitcoin-dev] PSA: Taproot loss of quantum protections
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, 15 Mar 2021 22:40:22 -0000

--0000000000002597f905bd9aef04
Content-Type: text/plain; charset="UTF-8"

I think Luke is pointing out that with the Signature and the Message you
should be able to recover the key.

if your address is H(P) and the message is H(H(P) || txn), then the you can
use the public H(P) and the signature to recover the PK and verify that
H(P) == P (I think you then don't even have to check the signature after
doing that).

Therefore there is no storage benefit.

For the script path case, you might have to pay a little bit extra though
as you'd have to reveal P I think? But perhaps that can be avoided another
way...
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>


On Mon, Mar 15, 2021 at 3:06 PM Matt Corallo via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> There have been many threads on this before, I'm not sure anything new has
> been brought up here.
>
> Matt
>
> On 3/15/21 17:48, Luke Dashjr via bitcoin-dev 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.
>
> Note that this is most definitely *not* news to this list, eg, Anthony
> brought it up in "Schnorr and taproot (etc)
> upgrade" and there was a whole thread on it in "Taproot: Privacy
> preserving switchable scripting". This issue has been
> beaten to death, I'm not sure why we need to keep hitting the poor horse
> corpse.
>
> >
> > 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.
>
> This has been discussed ad nauseam, and it all seems to fall apart once
> its noted just how much Bitcoin could be stolen
> by any QC-wielding attacker due to address reuse. Ultimately, no "pause"
> can solve this issue, and, if we learned about
> a QC attacker overnight (instead of slowly over time), there isn't
> anything that a non-Taproot Bitcoin could do that a
> Taproot Bitcoin couldn't.
>
> > 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!
>
> This is untrue. The storage space required for Taproot transactions is
> materially reduced by avoiding the hash indirection.
>
> > 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.
>
> For the reason stated above, i think such a fork is unlikely.
>
> > 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.
>
> I truly wish this were the case, but we've been beating that drum for at
> least nine years and still haven't solved it.
> Worse, there's a lot of old coins that are unlikely to move any time soon
> that are exposed whether we like it or not.
>
> > 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.)
>
> Except its not? One entity would be able to steal that entire block of
> supply rather quickly (presumably over the course
> of a few days, at maximum), instead of a slow process with significant
> upfront real-world cost in the form of electricity.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:#000000">I think Luke is pointing =
out that with the Signature and the Message you should be able to recover t=
he key.</div><div class=3D"gmail_default" style=3D"font-family:arial,helvet=
ica,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail=
_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c=
olor:#000000">if your address is H(P) and the message is H(H(P) || txn), th=
en the you can use the public H(P) and the signature to recover the PK and =
verify that H(P) =3D=3D P (I think you then don&#39;t even have to check th=
e signature after doing that).</div><div class=3D"gmail_default" style=3D"f=
ont-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></=
div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-=
serif;font-size:small;color:#000000">Therefore there is no storage benefit.=
<br></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica=
,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail_de=
fault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;colo=
r:#000000">For the script path case, you might have to pay a little bit ext=
ra though as you&#39;d have to reveal P I think? But perhaps that can be av=
oided another way...<br clear=3D"all"></div><div><div dir=3D"ltr" class=3D"=
gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr">--<br>=
<a href=3D"https://twitter.com/JeremyRubin" target=3D"_blank">@JeremyRubin<=
/a><a href=3D"https://twitter.com/JeremyRubin" target=3D"_blank"></a></div>=
</div></div><br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=
=3D"gmail_attr">On Mon, Mar 15, 2021 at 3:06 PM Matt Corallo via bitcoin-de=
v &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@=
lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex">There have been many threads on this before, I&#39=
;m not sure anything new has been brought up here.<br>
<br>
Matt<br>
<br>
On 3/15/21 17:48, Luke Dashjr via bitcoin-dev wrote:<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>
<br>
Note that this is most definitely *not* news to this list, eg, Anthony brou=
ght it up in &quot;Schnorr and taproot (etc) <br>
upgrade&quot; and there was a whole thread on it in &quot;Taproot: Privacy =
preserving switchable scripting&quot;. This issue has been <br>
beaten to death, I&#39;m not sure why we need to keep hitting the poor hors=
e corpse.<br>
<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>
<br>
This has been discussed ad nauseam, and it all seems to fall apart once its=
 noted just how much Bitcoin could be stolen <br>
by any QC-wielding attacker due to address reuse. Ultimately, no &quot;paus=
e&quot; can solve this issue, and, if we learned about <br>
a QC attacker overnight (instead of slowly over time), there isn&#39;t anyt=
hing that a non-Taproot Bitcoin could do that a <br>
Taproot Bitcoin couldn&#39;t.<br>
<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>
<br>
This is untrue. The storage space required for Taproot transactions is mate=
rially reduced by avoiding the hash indirection.<br>
<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>
<br>
For the reason stated above, i think such a fork is unlikely.<br>
<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>
<br>
I truly wish this were the case, but we&#39;ve been beating that drum for a=
t least nine years and still haven&#39;t solved it. <br>
Worse, there&#39;s a lot of old coins that are unlikely to move any time so=
on that are exposed whether we like it or not.<br>
<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>
<br>
Except its not? One entity would be able to steal that entire block of supp=
ly rather quickly (presumably over the course <br>
of a few days, at maximum), instead of a slow process with significant upfr=
ont real-world cost in the form of electricity.<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>

--0000000000002597f905bd9aef04--