path: root/11/a3bbbf42c19ad88aa47154a3de4551bc0540e5

Return-Path: <earonesty@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id C5C03C0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 22 Mar 2021 14:25:08 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id A812D40262
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 22 Mar 2021 14:25:08 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.65
X-Spam-Level: 
X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001,
 HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001,
 SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=q32-com.20150623.gappssmtp.com
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 4OzBg4c-lBWp
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 22 Mar 2021 14:25:07 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com
 [IPv6:2607:f8b0:4864:20::52f])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 81C834022B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 22 Mar 2021 14:25:07 +0000 (UTC)
Received: by mail-pg1-x52f.google.com with SMTP id v3so8724434pgq.2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 22 Mar 2021 07:25:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=q32-com.20150623.gappssmtp.com; s=20150623;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=QfCShnoGf7PV8QKZGKCkbgE6GilC3LFFfhlqcT7/80w=;
 b=JQCUDT6B7fl2TMM0JHZWKDQ2wuaJLXU1esN7z33l0n0SdvDOuwxu2q2LMcayYQjqKa
 XkrurznsiNcB8cyFtuLO6O60X+jxxJTfMUwSLpK0XIeJMCufVHiMED68uC6JDY9u80XA
 F+SaK6iBxksoIPcNFzt816m7BZ0nP61xszGfOmiFg5St2b+CIGblZCUzZtUQ89FSxdea
 IdorkcWYyZ2pPqC0te9oMitwY6atoUYulJe1Mwdo30B7dj4ZrwsqH5QsBiVCwLaZpiyj
 5MlCxqjnE01OAi94jthY3nCHqxCvXFtvLyBtSz4BjCeJYKpZQ2E7Ipz3OOw9gu3PLwZd
 o+SQ==
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=QfCShnoGf7PV8QKZGKCkbgE6GilC3LFFfhlqcT7/80w=;
 b=pN7UCJ7wgP2KmDTn0KzSmIV6UyMm0u1Kcexh58JFeNLbmZ7xQ2dehqJ1QeF/zsEURb
 BWiylphHy9pjw3QZm72e1ICj+J5BC4vQ7VRVNOMrJLml+I5Jk6L02IkAeWPvhVmL8O33
 FeM/kntUsHUdPCIJ5nuvaLEYUVLG4SslLdvREEFyRW/wB7hBG44+JHMYOxZVpODgYIv+
 54wm+X+oAOYgy8kCpIKbRbMUon7f/8hNAgTJ8gmA1t4GwdqYkDL3rw2ipOK3ZkTOyCdD
 v3AW9KCx5PtOKcDjjMJOHdLSBR2CI/MXw+Dc4x/2GND3mu7P98tH6w55qdlyPYpOAJJs
 2kug==
X-Gm-Message-State: AOAM531SzI0m6sZy5i3y3RFZM7ZeDhSGYje01veH0h07VmIYnja+QVI7
 1smYiBnEC0n0euIhgmflvtgWAzZztRBgC7Q+qxiaEnY=
X-Google-Smtp-Source: ABdhPJzTmST7eZscqVtR9Pwhz3+NoDt3BuU5zHChWyDWHfM0lzsodUd7zHw3Hp1jZyZEu9R+H7b1kth0pN2ccTOnuRQ=
X-Received: by 2002:a65:4542:: with SMTP id x2mr22744856pgr.53.1616423106722; 
 Mon, 22 Mar 2021 07:25:06 -0700 (PDT)
MIME-Version: 1.0
References: <202103152148.15477.luke@dashjr.org>
In-Reply-To: <202103152148.15477.luke@dashjr.org>
From: Erik Aronesty <erik@q32.com>
Date: Mon, 22 Mar 2021 10:24:55 -0400
Message-ID: <CAJowKgLuWOkD=_jDaLqG=FOG02qX7p4-EZ69yvw4UqcWpz+rRg@mail.gmail.com>
To: Luke Dashjr <luke@dashjr.org>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
X-Mailman-Approved-At: Mon, 22 Mar 2021 14:47:44 +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 <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, 22 Mar 2021 14:25:08 -0000

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