From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id E262EC000A for ; Tue, 16 Mar 2021 13:28:36 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id BCCA342D1D for ; Tue, 16 Mar 2021 13:28:36 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.107 X-Spam-Level: X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pi3SsDSgKW3C for ; Tue, 16 Mar 2021 13:28:35 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from mail.wpsoftware.net (unknown [66.183.0.205]) by smtp2.osuosl.org (Postfix) with ESMTP id C4B32414E0 for ; Tue, 16 Mar 2021 13:28:35 +0000 (UTC) Received: from camus (camus-andrew.lan [192.168.0.190]) by mail.wpsoftware.net (Postfix) with ESMTPSA id 8ACD7400F9; Tue, 16 Mar 2021 13:23:28 +0000 (UTC) Date: Tue, 16 Mar 2021 13:28:34 +0000 From: Andrew Poelstra To: Luke Dashjr Message-ID: References: <202103152148.15477.luke@dashjr.org> <202103160344.26299.luke@dashjr.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0EwcQkygrej2ZUHa" Content-Disposition: inline In-Reply-To: <202103160344.26299.luke@dashjr.org> Cc: Bitcoin Protocol Discussion 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: Tue, 16 Mar 2021 13:28:37 -0000 --0EwcQkygrej2ZUHa Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. =20 > On Monday 15 March 2021 23:12:18 Andrew Poelstra wrote: > > "No gain" except to save significant CPU time and bandwidth? >=20 > The CPU time is localised to involved nodes, and (correct me if I'm wrong= )=20 > trivial in comparison to what is required to run a full node in the first= =20 > 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, sign= ature 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. =20 > > Having exposed keys also lets you do ring signatures over outputs, crea= ting > > the ability to do private proof of funds via Provisions. >=20 > But you can also do comparable proofs behind a hash with Bulletproofs, ri= ght? > Yes, if you are willing to accept independent >100000x slowdowns on proving, verification and code review. =20 > > > 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 softfo= rk > > > and fix this. > > > > This would make Bitcoin strictly worse. >=20 > 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 qua= ntum=20 > risk would be forced to forego the benefits of Taproot and stick to p2pkh= or=20 > 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 implemen= ting Taproot, and slow down Bitcoin nodes who would have to validate the extra material. =20 > > > 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 sup= ply > > > 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%. >=20 > xpubs should be treated like secret key material IMO. >=20 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= =20 > wallet, right? >=20 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 out= puts > > actually have better quantum resistance than legacy outputs; and (b) ad= ding > > another hash would be strictly redundant. >=20 > It not only stops the attacker from obtaining the original key, but also= =20 > prevents creating a new private key that can spend the output? >=20 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 ov= er legacy outputs in this scenario: * Taproot keys are hashes of semi-secret data (at least as secret as xpub= s) 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 pr= ove 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 br= eak, 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. --=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 --0EwcQkygrej2ZUHa Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEkPnKPD7Je+ki35VexYjWPOQbl8EFAmBQsn4ACgkQxYjWPOQb l8F03Qf+PYw80K0gYPOK0QfHLTIaXBfO4F2D5ufP8qU2vvOsvHsqlHgrMStaXvQ9 r//RW5AAT7mnqNv7TFXW8xXCtpJ2qOkHqGZL84R6BO4sFf6YcrUBMdMctCHE3L6u JuBowXwWSBBxDSXyxGUIVZ5EBYHmZc/y1jLWTtsz3PdlEKm+wueLrl3OGOLR465A 4kPIxSV07y7QW4jhKtaacnozPcJgGeANCn/jQ31ZqECRgdaTFn8yAwyQvE/k9mAY QFcnW2uKFMVXxKsigY0ecO7OAZaO8cAnIYteG3WGd3AxGxm0NqlRVyEsfmjtwzhM K1UkacmBxrGQC6Caiaz5fMwbPgcCog== =HQDI -----END PGP SIGNATURE----- --0EwcQkygrej2ZUHa--