Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 98676C0001 for ; Tue, 23 Mar 2021 09:36:46 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 7D97060694 for ; Tue, 23 Mar 2021 09:36:46 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 0.602 X-Spam-Level: X-Spam-Status: No, score=0.602 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 T9M_mp-zaH7H for ; Tue, 23 Mar 2021 09:36:45 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) by smtp3.osuosl.org (Postfix) with ESMTPS id E045560812 for ; Tue, 23 Mar 2021 09:36:44 +0000 (UTC) Received: by mail-ej1-x633.google.com with SMTP id a7so25950667ejs.3 for ; Tue, 23 Mar 2021 02:36:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=OVH0R+3J2EPofJmblxgp4lisV5uGCvYMVWBAFI+3/PU=; b=lT01xwsUc96+xikmdCQoIgQ0n89k7CCAqEDtMhyo/aN9nU/bZJwV4RqL1nkpBo8TBw JIf9hpdcjYC6ds4KTB1GTYVkgR+JsIKcJKvEbC0zrB0uYiadYoQXNMdG20aHwAwhn67J fGOsz5SYhmuBrMIDju0NVeLGcbz0talUI2AyyeC9eOMBXFlCdeFzfohrmIQudkN8qSXV YtIkh7GZ3qFRNL+na4ExVQYmjGAWxHu+41PYdj2hybav0SQq2aZ5F/txLOek/ZYV6dHl y2qQrg5gPGiD+7Jm+Tn/yIK1elGhFhlcMhFoP1Tg6N6ABVynS7moieaZ0/XwQwi/6DDL Gbww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=OVH0R+3J2EPofJmblxgp4lisV5uGCvYMVWBAFI+3/PU=; b=oWhet77VrIWfzq4gIwFrZpCsKASAqZTzuXtHAJpuuUlxBEXsbtSXdjcKjMWU1ZdqXm GkGEC5atC5+34wFYSFvogGy5koMKmVPIZoh0Ceww9hAoBcI1KI8ayPUE/YknCGtEcNpW EaJVMkSrQ3+aL3U9/0+N+Tu0mDiXBhbaABHp6iA8yFF/F8xQQNK6VVWgJorvAMKQRjAI vNZppANJbiWo1LPjLhkcnlMsSRrvWYu4vWC1QY0PWyDAQ31Wqh8uAlPlQNnn5iMPSG9I ub9oOoif2HKcoz8XKukW9GnWA4nZSDU1C9DM8jhByTmLiaA1fyMcb53fGF/5+Q8TK7i6 MV1g== X-Gm-Message-State: AOAM530TLf4ZPaTpp5DOuvvn63UzZtNHmAGZfaJvC9smSAAcDVxcJ4cp ShmkElFKSIUBNNBUPK4LIStbl2xenuS8vfvJqlxVS3S+chbhdj5z X-Google-Smtp-Source: ABdhPJxPoERnPDRwFEkWq17E8ai3/FXGmaOwFOP4+v5iUqMJVc8ZEdUJG7N1UAQZ3qQOqO5O2HvLCsVk2nU+usnwrl8= X-Received: by 2002:a17:906:95d1:: with SMTP id n17mr3947280ejy.394.1616492203116; Tue, 23 Mar 2021 02:36:43 -0700 (PDT) MIME-Version: 1.0 References: <202103152148.15477.luke@dashjr.org> In-Reply-To: From: Martin Schwarz Date: Tue, 23 Mar 2021 10:36:32 +0100 Message-ID: To: Erik Aronesty , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000008c8cab05be30eb33" X-Mailman-Approved-At: Tue, 23 Mar 2021 09:55:26 +0000 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: Tue, 23 Mar 2021 09:36:46 -0000 --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 > 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
Erik,

> Does anyone think it would it be useful to write up a more official,
and= even partly functional plan for Bitcoin to use=C2=A0zero-knowledge
proofs to trans= ition to=C2=A0quantum=C2=A0resistance?
=
yes, this would be appreciated very much! Andrew Chow's = write-up=C2=A0
gives already some high-level idea, but a more det= ailed 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> w= rote:
The argume= nt 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-p= rovide-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".=C2=A0 =C2=A0Mikhail Dyakonov summarized the arguments well he= re:
https://t.co/cgrfrroTTT?amp=3D1.

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
=C2=A0 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 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.
>
> Mark Friedenbach explains on his blog:
>=C2=A0 =C2=A0 =C2=A0https://freicoin.subst= ack.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 "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.
>
> 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!
>
> 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.
>
> 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.
>
> 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.)
>
> To conclude, I recommend anyone using Bitcoin to read Mark's artic= le, my
> thoughts, and any other arguments on the topic; decide if this is a co= ncern
> to you, and make your own post(s) accordingly. Mark has conceded the a= rgument
> (AFAIK he doesn't have an interest in bitcoins anyway), and I do n= ot consider
> it a showstopper - so if anyone else out there does, please make yours= elf
> 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 th= ings
> 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/mail= man/listinfo/bitcoin-dev
--0000000000008c8cab05be30eb33--