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
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
|
Return-Path: <luke@dashjr.org>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 69389C000A
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 16 Mar 2021 03:48:43 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 4338060642
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 16 Mar 2021 03:48:43 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.202
X-Spam-Level:
X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5
tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001,
RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
dkim=pass (1024-bit key) header.d=dashjr.org
Received: from smtp3.osuosl.org ([127.0.0.1])
by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id W-IhtKNxd8zM
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 16 Mar 2021 03:48:42 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21])
by smtp3.osuosl.org (Postfix) with ESMTP id ECB24605BE
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 16 Mar 2021 03:48:41 +0000 (UTC)
Received: from ishibashi.lan (unknown [12.190.236.209])
(Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id 4B2B638A009D;
Tue, 16 Mar 2021 03:44:29 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dashjr.org; s=zinan;
t=1615866519; bh=KsbZ4eFbhfBi/VUDKXKCeh0iL+jlzKt8vP8m2tXsKtQ=;
h=From:To:Subject:Date:Cc:References:In-Reply-To;
b=GqTF/PE3ylmPnBZCd3Cwf+s3Rsnwh7iLK6PuHpDB8+ZOqkEMJ1ogpdoZGYio90LKK
bxV2csqPTCVrs4gZv3Zh1rxDIqFu4AjNmF5tZtlUEV3eRJ0OMl5KX9nXc+kopOfO1u
E6JELu5QV8laK7gyALvxaWpZ3XGnE+lZkOxMKnQ0=
X-Hashcash: 1:25:210316:lf-lists@mattcorallo.com::VFrdaEq2b2d4f4OW:fWtXr
X-Hashcash: 1:25:210316:ZmnSCPxj@protonmail.com::KiJLvFsun5plL0JP:a84UE
X-Hashcash: 1:25:210316:karljohan-alm@garage.co.jp::DhKzZPn4EcniSIwL:a1jbS
X-Hashcash: 1:25:210316:apoelstra@wpsoftware.net::QGBaYGo+nQRfP62b:B55H
X-Hashcash: 1:25:210316:bitcoin-dev@lists.linuxfoundation.org::WXcS//yysJUaT6Zh:Etg1
From: Luke Dashjr <luke@dashjr.org>
To: Matt Corallo <lf-lists@mattcorallo.com>,
ZmnSCPxj <ZmnSCPxj@protonmail.com>,
"Karl-Johan Alm" <karljohan-alm@garage.co.jp>,
Andrew Poelstra <apoelstra@wpsoftware.net>
Date: Tue, 16 Mar 2021 03:44:25 +0000
User-Agent: KMail/1.9.10
References: <202103152148.15477.luke@dashjr.org>
<a88cd471-fdc9-de35-86cd-595b387249c8@mattcorallo.com>
In-Reply-To: <a88cd471-fdc9-de35-86cd-595b387249c8@mattcorallo.com>
X-KMail-QuotePrefix: >
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <202103160344.26299.luke@dashjr.org>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.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: Tue, 16 Mar 2021 03:48:43 -0000
(To reiterate: I do not intend any of this as a NACK of Taproot.)
On Monday 15 March 2021 22:05:45 Matt Corallo wrote:
> > First, so long as we have hash-based addresses as a best practice, we can
> > continue to shrink the percentage of bitcoins affected through social
> > efforts discouraging address use. If the standard loses the hash, the
> > situation cannot be improved, and will indeed only get worse.
>
> I truly wish this were the case, but we've been beating that drum for at
> least nine years and still haven't solved it.
I think we've made progress over those 9 years, don't you?
> > Second, when/if quantum does compromise these coins, so long as they are
> > neglected or abandoned/lost coins (inherent in the current model), it can
> > be seen as equivalent to Bitcoin mining. At the end of the day, 37% of
> > supply minable by QCs is really no different than 37% minable by ASICs.
> > (We've seen far higher %s available for mining obviously.)
>
> Except its not? One entity would be able to steal that entire block of
> supply rather quickly (presumably over the course of a few days, at
> maximum), instead of a slow process with significant upfront real-world
> cost in the form of electricity.
My understanding is that at least initial successes would likely be very slow.
Hopefully we would have a permanent solution before it got too out of hand.
On Monday 15 March 2021 23:01:47 Karl-Johan Alm via bitcoin-dev wrote:
> The important distinction here is that, with hashes, an attacker has
> to race against the spending transaction confirming, whereas with
> naked pubkeys, the attacker doesn't have to wait for a spend to occur,
> drastically increasing the available time to attack.
More importantly, once an attack is recognised, with hashes, people can simply
stop sending transactions and await a fix, to protect their stash. Without
hashes, there is no defense at all (other than sending bitcoins to a
non-taproot address and hoping they evade the attack in time).
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.
> 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?
> > 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.
> > 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.
A quantum attacker would need to compromise your PC to attack a hardware
wallet, right?
> 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?
On Tuesday 16 March 2021 02:38:55 ZmnSCPxj via bitcoin-dev wrote:
> From this point-of-view, it seems to me that the amount of energy to mount
> a "fast" attack may eventually approach the energy required by mining, in
> which case someone who possesses the ability to mount such an attack may
> very well find it easier to just 51% the network (since that can be done
> today without having to pour R&D satoshis into developing practical quantum
> computers).
Mining adapts its difficulty to the block rate, so it will slow you down up to
4x each retarget. An attack on public keys would probably scale better. :)
Luke
|
