From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 07242C0001 for ; Mon, 15 Mar 2021 23:18:06 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id E36A98382D for ; Mon, 15 Mar 2021 23:18:05 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 1.595 X-Spam-Level: * X-Spam-Status: No, score=1.595 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id saSygjpMFWqV for ; Mon, 15 Mar 2021 23:18:05 +0000 (UTC) X-Greylist: delayed 00:05:46 by SQLgrey-1.8.0 Received: from mail.wpsoftware.net (unknown [66.183.0.205]) by smtp1.osuosl.org (Postfix) with ESMTP id 0B96783005 for ; Mon, 15 Mar 2021 23:18:04 +0000 (UTC) Received: from camus (camus-andrew.lan [192.168.0.190]) by mail.wpsoftware.net (Postfix) with ESMTPSA id B7B5640131; Mon, 15 Mar 2021 23:07:15 +0000 (UTC) Date: Mon, 15 Mar 2021 23:12:18 +0000 From: Andrew Poelstra To: Luke Dashjr , Bitcoin Protocol Discussion Message-ID: 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 X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2021 23:18:06 -0000 --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--