From: Luke Dashjr <luke@dashjr.org>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: [bitcoin-dev] PSA: Taproot loss of quantum protections
Date: Mon, 15 Mar 2021 21:48:15 +0000 [thread overview]
Message-ID: <202103152148.15477.luke@dashjr.org> (raw)
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
next reply other threads:[~2021-03-15 21:48 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-15 21:48 Luke Dashjr [this message]
2021-03-15 22:05 ` [bitcoin-dev] PSA: Taproot loss of quantum protections Matt Corallo
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=202103152148.15477.luke@dashjr.org \
--to=luke@dashjr.org \
--cc=bitcoin-dev@lists.linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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