From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <lf-lists@mattcorallo.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 10361C0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 15 Mar 2021 22:05:49 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with UTF8SMTP id E66B940001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 15 Mar 2021 22:05:48 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.801
X-Spam-Level: 
X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=mattcorallo.com
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with UTF8SMTP id ANg3gem10AX8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 15 Mar 2021 22:05:47 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from mail.as397444.net (mail.as397444.net [69.59.18.99])
 by smtp2.osuosl.org (Postfix) with UTF8SMTPS id 6014E43144
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 15 Mar 2021 22:05:47 +0000 (UTC)
Received: by mail.as397444.net (Postfix) with UTF8SMTPSA id 638114E2790;
 Mon, 15 Mar 2021 22:05:45 +0000 (UTC)
X-DKIM-Note: Keys used to sign are likely public at https://as397444.net/dkim/
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mattcorallo.com;
 s=1615844464; t=1615845945;
 bh=LCRT+raxT3vTNzcPBRZmL9LE197JKTliKWdE9bgFHVA=;
 h=Date:Subject:To:References:From:In-Reply-To:From;
 b=mIOX+tuOIE3OMFRBL2It7q3aWniaNqKrhdcUufwQr2TrXUKnJpNJIymetRsjbnPB7
 Jkqp07Oic52QPUbfo91ncCC8UrHVz8m4W7vBVYqj483xldTvsmSk6NCg0wqfRoSSb/
 xaQp0c6baaBIoReFURd0VR4d2969Gwx+UAqTHh0vDfO7xWebTIv2+iGuRfvNVWmprD
 cq/mSfikAGOD4m+x/+6eh342sKWUqa4e4ueU45sS9ENUcEBeAQJr9NG4ab4DK0PP8a
 /m3FQhh+9wO028ro5RVd1hx5nShjVOWCg5sM2Gp0IjmhHLn2+1/LBuxAF/bf3iNmUw
 kfOEU6G9GWHcQ==
Message-ID: <a88cd471-fdc9-de35-86cd-595b387249c8@mattcorallo.com>
Date: Mon, 15 Mar 2021 18:05:45 -0400
MIME-Version: 1.0
Content-Language: en-US
To: Luke Dashjr <luke@dashjr.org>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <202103152148.15477.luke@dashjr.org>
From: Matt Corallo <lf-lists@mattcorallo.com>
In-Reply-To: <202103152148.15477.luke@dashjr.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
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:05:49 -0000

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.