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
|
Return-Path: <lf-lists@mattcorallo.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 2962BC0001
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 15 Mar 2021 22:48:26 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with UTF8SMTP id 0B8F26F5ED
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 15 Mar 2021 22:48:26 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.8
X-Spam-Level:
X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7,
SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=mattcorallo.com
Received: from smtp3.osuosl.org ([127.0.0.1])
by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with UTF8SMTP id ePCotA3xVEeK
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 15 Mar 2021 22:48:25 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from mail.as397444.net (mail.as397444.net [69.59.18.99])
by smtp3.osuosl.org (Postfix) with UTF8SMTPS id 9ECB56F5E4
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 15 Mar 2021 22:48:24 +0000 (UTC)
Received: by mail.as397444.net (Postfix) with UTF8SMTPSA id 284694E28C7;
Mon, 15 Mar 2021 22:48:22 +0000 (UTC)
X-DKIM-Note: Keys used to sign are likely public at https://as397444.net/dkim/
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mattcorallo.com;
s=1615846864; t=1615848502;
bh=L4dnSgY5Ljm0r/+Bm/nMppOcumpAzeZBaY4ISYyfti0=;
h=Date:Subject:To:Cc:References:From:In-Reply-To:From;
b=Oc85X9cWrVbBBvlujGYwKZO6yhz2V0VDcxJ8In/bmck0dg6gIpeFmMh2kS7VGk4df
BL3rFqbZQb+W8s6TVdFsniRsyOuO5mbnbIN/e/qxu4LGdKqrsYHLB80wSj6kNAACOA
kmkyBLiwGpTrTNzQJR4C/wLtEWzzzLJWajiFcWh6yCiNY4etNzn0IBgsW02bXY2ttz
/nEPbPytN9O3gEKcW6CI8WGcvMR7/TN1pNGLurON/qaTJqHJc27kMR9RO0MhSetmb+
wzNlIazSQoPBLbYDmSlJ6GRM2BPMCQVuY6WeCz0tLX+ouWMIuzwXR1NYmWL7td1alQ
JqYU/YGAbVT8Q==
Message-ID: <a4b9df55-b95b-9c95-62ea-7bf6eeec113d@mattcorallo.com>
Date: Mon, 15 Mar 2021 18:48:21 -0400
MIME-Version: 1.0
Content-Language: en-US
To: Jeremy <jlrubin@mit.edu>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <202103152148.15477.luke@dashjr.org>
<a88cd471-fdc9-de35-86cd-595b387249c8@mattcorallo.com>
<CAD5xwhi82fjRB4Ceb6Gnp+LvTweWjwFRmWU5zD-3o6s_GoEvPw@mail.gmail.com>
From: Matt Corallo <lf-lists@mattcorallo.com>
In-Reply-To: <CAD5xwhi82fjRB4Ceb6Gnp+LvTweWjwFRmWU5zD-3o6s_GoEvPw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
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 22:48:26 -0000
Right, you can avoid the storage cost at the cost of significantly higher CPU usage, plus lack of ability to
batch-validate. As Robert pointed out in a neighboring mail, it also reduces ability to do other, fancier, protocols
using the fact that public keys are now a public part of a script_pubkey.
Overall, the tradeoffs here seem ludicrous, given that any QC issues in Bitcoin need to be solved in another way, and
can't practically be solved by just relying on the existing hash indirection.
Matt
On 3/15/21 18:40, Jeremy wrote:
> I think Luke is pointing out that with the Signature and the Message you should be able to recover the key.
>
> if your address is H(P) and the message is H(H(P) || txn), then the you can use the public H(P) and the signature to
> recover the PK and verify that H(P) == P (I think you then don't even have to check the signature after doing that).
>
> Therefore there is no storage benefit.
>
> For the script path case, you might have to pay a little bit extra though as you'd have to reveal P I think? But perhaps
> that can be avoided another way...
> --
> @JeremyRubin <https://twitter.com/JeremyRubin><https://twitter.com/JeremyRubin>
>
>
> On Mon, Mar 15, 2021 at 3:06 PM Matt Corallo via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
> There have been many threads on this before, I'm not sure anything new has been brought up here.
>
> Matt
>
> On 3/15/21 17:48, Luke Dashjr via bitcoin-dev wrote:
> > I do not personally see this as a reason to NACK Taproot, but it has become
> > clear to me over the past week or so that many others are unaware of this
> > tradeoff, so I am sharing it here to ensure the wider community is aware of
> > it and can make their own judgements.
>
> Note that this is most definitely *not* news to this list, eg, Anthony brought it up in "Schnorr and taproot (etc)
> upgrade" and there was a whole thread on it in "Taproot: Privacy preserving switchable scripting". This issue has been
> beaten to death, I'm not sure why we need to keep hitting the poor horse corpse.
>
> >
> > In short, Taproot loses an important safety protection against quantum.
> > Note that in all circumstances, Bitcoin is endangered when QC becomes a
> > reality, but pre-Taproot, it is possible for the network to "pause" while a
> > full quantum-safe fix is developed, and then resume transacting. With Taproot
> > as-is, it could very well become an unrecoverable situation if QC go online
> > prior to having a full quantum-safe solution.
>
> This has been discussed ad nauseam, and it all seems to fall apart once its noted just how much Bitcoin could be stolen
> by any QC-wielding attacker due to address reuse. Ultimately, no "pause" can solve this issue, and, if we learned about
> a QC attacker overnight (instead of slowly over time), there isn't anything that a non-Taproot Bitcoin could do that a
> Taproot Bitcoin couldn't.
>
> > Also, what I didn't know myself until today, is that we do not actually gain
> > anything from this: the features proposed to make use of the raw keys being
> > public prior to spending can be implemented with hashed keys as well.
> > It would use significantly more CPU time and bandwidth (between private
> > parties, not on-chain), but there should be no shortage of that for anyone
> > running a full node (indeed, CPU time is freed up by Taproot!); at worst, it
> > would create an incentive for more people to use their own full node, which
> > is a good thing!
>
> This is untrue. The storage space required for Taproot transactions is materially reduced by avoiding the hash
> indirection.
>
> > 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.
>
> For the reason stated above, i think such a fork is unlikely.
>
> > 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.
> >
> > 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.
> Worse, there's a lot of old coins that are unlikely to move any time soon that are exposed whether we like it or not.
>
> > 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.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org <mailto:bitcoin-dev@lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>
|
