From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 5FA65C0001 for ; 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 ; 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 ; 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 ; 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 ; Mon, 15 Mar 2021 18:40:19 -0400 Received: by mail-io1-f42.google.com with SMTP id n132so35177115iod.0 for ; 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> In-Reply-To: From: Jeremy Date: Mon, 15 Mar 2021 15:40:07 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Matt Corallo , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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
I think Luke is pointing = out that with the Signature and the Message you should be able to recover t= he key.

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't even have to check th= e signature after doing that).

Therefore there is no storage benefit.=

For the script path case, you might have to pay a little bit ext= ra though as you'd have to reveal P I think? But perhaps that can be av= oided another way...


On Mon, Mar 15, 2021 at 3:06 PM Matt Corallo via bitcoin-de= v <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 b= ecome
> clear to me over the past week or so that many others are unaware of t= his
> tradeoff, so I am sharing it here to ensure the wider community is awa= re of
> it and can make their own judgements.

Note that this is most definitely *not* news to this list, eg, Anthony brou= ght 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 hors= e 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 "paus= e" 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 o= nline
> 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 "paus= e" can solve this issue, and, if we learned about
a QC attacker overnight (instead of slowly over time), there isn't anyt= hing 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 act= ually 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.<= br> > It would use significantly more CPU time and bandwidth (between privat= e
> parties, not on-chain), but there should be no shortage of that for an= yone
> running a full node (indeed, CPU time is freed up by Taproot!); at wor= st, 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 mate= rially reduced by avoiding the hash indirection.

> Despite this, I still don't think it's a reason to NACK Taproo= t: 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, i= n
> 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 tha= t 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 situatio= n
> cannot be improved, and will indeed only get worse.

I truly wish this were the case, but we've been beating that drum for a= t least nine years and still haven't solved it.
Worse, there's a lot of old coins that are unlikely to move any time so= on that are exposed whether we like it or not.

> Second, when/if quantum does compromise these coins, so long as they a= re
> 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 su= pply
> minable by QCs is really no different than 37% minable by ASICs. (We&#= 39;ve seen
> far higher %s available for mining obviously.)

Except its not? One entity would be able to steal that entire block of supp= ly rather quickly (presumably over the course
of a few days, at maximum), instead of a slow process with significant upfr= ont real-world cost in the form of electricity.
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--0000000000002597f905bd9aef04--