From: Andrew Poelstra <apoelstra@wpsoftware•net>
To: Luke Dashjr <luke@dashjr•org>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] PSA: Taproot loss of quantum protections
Date: Tue, 16 Mar 2021 13:28:34 +0000 [thread overview]
Message-ID: <YFCygncy/hyxFRWz@camus> (raw)
In-Reply-To: <202103160344.26299.luke@dashjr.org>
[-- Attachment #1: Type: text/plain, Size: 5234 bytes --]
On Tue, Mar 16, 2021 at 03:44:25AM +0000, Luke Dashjr wrote:
> (To reiterate: I do not intend any of this as a NACK of Taproot.)
>
Thanks, although it's still somewhat frustrating to be rehashing this
discussion again after so many years.
> On Monday 15 March 2021 23:12:18 Andrew Poelstra wrote:
> > "No gain" except to save significant CPU time and bandwidth?
>
> The CPU time is localised to involved nodes, and (correct me if I'm wrong)
> trivial in comparison to what is required to run a full node in the first
> place. I'm not sure how it looks with bandwidth.
>
I really can't parse what "localized to involved nodes" means. All Bitcoin
nodes will be affected. Right now for nodes with sufficient bandwidth, signature
validation is the slowest part of validating transactions, which is why it
is disabled for the bulk of the chain during IBD. Taproot, by virtue of
enabling batch verification, would give a 2-3x speedup when validating the
same number of signatures.
> > Having exposed keys also lets you do ring signatures over outputs, creating
> > the ability to do private proof of funds via Provisions.
>
> But you can also do comparable proofs behind a hash with Bulletproofs, right?
>
Yes, if you are willing to accept independent >100000x slowdowns on proving,
verification and code review.
> > > 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.
> >
> > This would make Bitcoin strictly worse.
>
> How so? People could just not use it if they don't care, right?
> The alternative (if people care enough) is that those concerned about quantum
> risk would be forced to forego the benefits of Taproot and stick to p2pkh or
> such, which seems like an artificial punishment.
>
People who do use it will reduce their privacy set, reduce the privacy set of
people who aren't using it, create confusion and delays for people implementing
Taproot, and slow down Bitcoin nodes who would have to validate the extra
material.
> > > 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.
> >
> > 37% is a dramatic understatement. Every address which is derived using
> > BIP32 should be assumed compromised to a QC attacker because xpubs are not
> > treated like secret key material and are trivial to e.g. extract from
> > hardware wallets or PSBTs. I expect the real number is close to 100%.
>
> xpubs should be treated like secret key material IMO.
>
Your opinion is noted. This is not how xpubs are, in reality, treated. And
it would make them significantly less useful if you could no longer share
descriptors with people you would like to do multiparty transactions with.
> A quantum attacker would need to compromise your PC to attack a hardware
> wallet, right?
>
No, I expect you could get xpubs out of hardware wallets using any of the
web endpoints provided by hardware wallet vendors, or by asking it to update
a PSBT with any of its scriptpubkeys.
> > In any case, Taproot keys, when used according to the recommendation in
> > BIP-0341, are already hashes of their internal keys, so (a) Taproot outputs
> > actually have better quantum resistance than legacy outputs; and (b) adding
> > another hash would be strictly redundant.
>
> It not only stops the attacker from obtaining the original key, but also
> prevents creating a new private key that can spend the output?
>
I don't know what you mean by this. If the original key is usable, i.e. a QC
has appeared overnight, then Bitcoin is screwed. (For that matter, the same is
true if there is an overnight break in SHA2, or ECDSA, or any other major
component of Bitcoin. Fortunately this is not how cryptographic breaks have
historically appeared.) There is no new private key that could be created.
If there is a QC where we have some warning, then we need to disable all EC
operations in Script, including keypath spends of Taproot outputs, and this
would be true with or without the redundant extra hash.
Taproot, with or without the redundant hash, has a few distinct benefits over
legacy outputs in this scenario:
* Taproot keys are hashes of semi-secret data (at least as secret as xpubs)
in a well-defined and simple way, by virtue of committing to an internal
key and some script (usually unspendable)
* By adding secret data to the script, users can provide extra data to prove
in a QC-hard way, even if their internal key is compromised
* Taproot keys can be chosen to be provably unspendable except by a DL break,
as David Harding points out, by using a NUMS point as an internal key.
None of these factors are improved by adding an extra hash.
--
Andrew Poelstra
Director of Research, Blockstream
Email: apoelstra at wpsoftware.net
Web: https://www.wpsoftware.net/andrew
The sun is always shining in space
-Justin Lewis-Webster
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2021-03-16 13:28 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
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 [this message]
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=YFCygncy/hyxFRWz@camus \
--to=apoelstra@wpsoftware$(echo .)net \
--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