Date: Mon, 15 Mar 2021 23:12:18 +0000
From: Andrew Poelstra <apoelstra@wpsoftware.net>
To: Luke Dashjr <luke@dashjr.org>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <YE/p0u3gp4UYNS7R@camus>
References: <202103152148.15477.luke@dashjr.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature"; boundary="32e/KgGra1tfOUvA"
Content-Disposition: inline
In-Reply-To: <202103152148.15477.luke@dashjr.org>
Subject: Re: [bitcoin-dev] PSA: Taproot loss of quantum protections
Precedence: list


--32e/KgGra1tfOUvA
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Mar 15, 2021 at 09:48:15PM +0000, Luke Dashjr via bitcoin-dev wrote:
> Also, what I didn't know myself until today, is that we do not actually g=
ain=20
> anything from this: the features proposed to make use of the raw keys bei=
ng=20
> public prior to spending can be implemented with hashed keys as well.
> It would use significantly more CPU time and bandwidth (between private=
=20
> parties, not on-chain), but there should be no shortage of that for anyon=
e=20
> running a full node (indeed, CPU time is freed up by Taproot!); at worst,=
 it=20
> would create an incentive for more people to use their own full node, whi=
ch=20
> is a good thing!
>=20

"No gain" except to save significant CPU time and bandwidth? As Matt points
out there is also a storage hit (unless you want to _really_ waste CPU time
by using pubkey recovery, eliminating any hope of batch validation while
introducing a new dependency on an algorithm with a very unclear patent
story).

Having exposed keys also lets you do ring signatures over outputs, creating=
 the
ability to do private proof of funds via Provisions.

> Despite this, I still don't think it's a reason to NACK Taproot: it shoul=
d be=20
> fairly trivial to add a hash on top in an additional softfork and fix thi=
s.
>=20

This would make Bitcoin strictly worse.

> In addition to the points made by Mark, I also want to add two more, in=
=20
> response to Pieter's "you can't claim much security if 37% of the supply =
is=20
> at risk" argument. This argument is based in part on the fact that many=
=20
> people reuse Bitcoin invoice addresses.
>=20

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 wall=
ets
or PSBTs. I expect the real number is close to 100%.


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.

--=20
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


--32e/KgGra1tfOUvA
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEkPnKPD7Je+ki35VexYjWPOQbl8EFAmBP6dAACgkQxYjWPOQb
l8E9egf/bRsficyhcJXbnedHnrb7NC6S3Vzmq7LHQ5v3S0VuJ8UvQG9qGRmi8V/r
Sc/36DVJRUqeaYQkLOI9ac86t2HQZn0KhQ16hh0ClAZFWfyHUkN7Y8CREQHkB1XO
ONvyDxJtFXvRMDD0waenq2R1mlrOxdzmU2QY6LFgq4KsGR885Af0LBMoPXckCl+E
sb3rjzXEMOBTKeaJyhyW7/cncz8k6tkXkwqkCNwsqJOSzb3MEt+6s0WPcj90Azeg
5q88EgzLV25BiJMXnrCqgh3FAVqEtSmywj1CZ5o5g9g4E4CMXIVGKAkd9qv6Acy5
Ww6ZCz+E9Dw6IXgvC5B1PuZzpUpLng==
=ETWL
-----END PGP SIGNATURE-----

--32e/KgGra1tfOUvA--