From: Matt Corallo <lf-lists@mattcorallo•com>
To: Luke Dashjr <luke@dashjr•org>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] PSA: Taproot loss of quantum protections
Date: Mon, 15 Mar 2021 18:05:45 -0400 [thread overview]
Message-ID: <a88cd471-fdc9-de35-86cd-595b387249c8@mattcorallo.com> (raw)
In-Reply-To: <202103152148.15477.luke@dashjr.org>
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.
next prev parent reply other threads:[~2021-03-15 22:05 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-15 21:48 Luke Dashjr
2021-03-15 22:05 ` Matt Corallo [this message]
2021-03-15 22:30 ` Robert Spigler
2021-03-15 22:40 ` Jeremy
2021-03-15 22:48 ` Matt Corallo
2021-03-15 23:01 ` Karl-Johan Alm
2021-03-15 23:19 ` Matt Corallo
2021-03-15 23:46 ` Lloyd Fournier
2021-03-16 0:50 ` Anthony Towns
2021-03-16 2:38 ` ZmnSCPxj
2021-03-16 3:44 ` Luke Dashjr
2021-03-16 13:28 ` Andrew Poelstra
2021-03-16 17:25 ` Matt Corallo
2021-03-17 1:23 ` Ryan Grant
2021-03-17 11:56 ` Eoin McQuinn
2021-03-15 23:12 ` Andrew Poelstra
2021-03-16 14:10 ` Andrea
2021-03-16 15:15 ` [bitcoin-dev] Provisions (was: PSA: Taproot loss of quantum protections) Andrew Poelstra
2021-03-17 4:24 ` ZmnSCPxj
2021-03-17 8:29 ` Andrea
2021-03-20 16:31 ` Andrea Barontini
2021-03-16 0:24 ` [bitcoin-dev] PSA: Taproot loss of quantum protections David A. Harding
2021-04-05 0:27 ` Lloyd Fournier
2021-04-16 3:47 ` ZmnSCPxj
2021-04-16 5:00 ` Lloyd Fournier
2021-03-22 14:24 ` Erik Aronesty
2021-03-23 9:36 ` Martin Schwarz
2021-03-23 10:50 ` Tim Ruffing
2021-08-12 22:08 ` Erik Aronesty
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a88cd471-fdc9-de35-86cd-595b387249c8@mattcorallo.com \
--to=lf-lists@mattcorallo$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=luke@dashjr$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox