1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
|
Return-Path: <apoelstra@wpsoftware.net>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 07242C0001
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <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
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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--
|
