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
178
|
Return-Path: <natanael.l@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 7C08210D0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 25 Jan 2018 00:09:34 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f47.google.com (mail-wm0-f47.google.com [74.125.82.47])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9DA92E2
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 25 Jan 2018 00:09:33 +0000 (UTC)
Received: by mail-wm0-f47.google.com with SMTP id f3so11837166wmc.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 24 Jan 2018 16:09:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
bh=/V6Lystpv41Qe0CXj7M8rWF69+BluajmbPgXbANybjc=;
b=ate9jKz81LklH/dI7SY8l3nLCjDvTDF1FYOTNTGvRPuwNlxkBuFU1tVQAdA2OfopRJ
jIcJlnDtomoEm2E8lc61AVV8bTBMO8g7shPATln0ta4Ain532tz/Wg/Pq2A3cSVjNqx7
8bBK7DthHbKUjF05/H6t6Row1hpapjPleLL9vXXkKxDDT0RkDKxIbRA9QRICRBoJnWln
3IosNpWyvZGQ1LnzrBQa6mnkLR2WnxoHhDWNIpys8n2cU/dtWn6sCzsLdLgoAT91OBjy
tNPei15BVJy5PrQohwEg8ydpR2KZO3SWYIStXw/M8lu7/6qqr+R2KglXpy/qzU7Er09s
ALUQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to;
bh=/V6Lystpv41Qe0CXj7M8rWF69+BluajmbPgXbANybjc=;
b=sqywqC41d3O+nduqQ5yb1TwRjvGcb2SdkneRbDs2Irut2Hdu8u6SWJGdlyYwEUcS7L
YotGx+DGcRqjsFBno0fLobiln64J6rQZ0r6SAzksY/QQTcy3kUByTEyBxLURq+uZfkTz
PJQbBvc0V7Otd3GXhGsHWKUiHlDtviD7tw5oCRivNNYhmN/7sv6Ao4VmCEBxLhcrqRDb
orBtCAhGlS3bwTWTP+Nj4BLxJO8w3xvjCmnIRPYco6z5bQnm1AxlLhs9dpNNJZGjEgMD
J9Gt/3yGTRj+xo+arnAbxrmquH5iv0vk6lkSROC9L9Yw2or9krrcUhkXcFFu8hJjbQpK
zXgQ==
X-Gm-Message-State: AKwxytcH2DdrhXmL50HrzqnVDzDEPINwRzAI2/RPG2tTIsr//GjlRBU6
/jbPGTxVCo5MzSYzieKgpck6twxWdSm4mF7KJqU=
X-Google-Smtp-Source: AH8x225WqZyjseic7zYUIiZKigf3eAhiQ19+JIud2kmff+vW+UVHMepCJAxuTQ6sgJWGB0kDnZFlM6Qu4jLMlE6TIuM=
X-Received: by 10.80.135.8 with SMTP id i8mr26051518edb.233.1516838972235;
Wed, 24 Jan 2018 16:09:32 -0800 (PST)
MIME-Version: 1.0
Received: by 10.80.169.103 with HTTP; Wed, 24 Jan 2018 16:09:31 -0800 (PST)
Received: by 10.80.169.103 with HTTP; Wed, 24 Jan 2018 16:09:31 -0800 (PST)
In-Reply-To: <1516836125.5969.11.camel@mmci.uni-saarland.de>
References: <CAAS2fgTXg5kk6TyUM9dS=tf5N0_Z-GKVmzMLwTW1HxUgrqdo+Q@mail.gmail.com>
<20180123064419.GA1296@erisian.com.au>
<CAAS2fgSy8qg71M6ZOr=xj=W6y2Jbz8hwygZOUYv-Brkt0JwVaQ@mail.gmail.com>
<20180123222229.GA3801@erisian.com.au>
<CAAS2fgTNcCB2mfvCBhC_AhgxX=g8feYguGHN_VPWW0EoOOxMyA@mail.gmail.com>
<CAAt2M1-oh=_Ro6+Srit0XYburK_abQgJiW0Jx=nmNyeToA2rSA@mail.gmail.com>
<1516808291.4277.25.camel@mmci.uni-saarland.de>
<CAAt2M19csW3eTW_rrS+8+OuaG18EhqajWgLFotCrcVfSeVmrrQ@mail.gmail.com>
<1516836125.5969.11.camel@mmci.uni-saarland.de>
From: Natanael <natanael.l@gmail.com>
Date: Thu, 25 Jan 2018 01:09:31 +0100
Message-ID: <CAAt2M19UObuaaODHXb+iW9bWMj53wGHAdjVzZgWBi-ZCCUi4Mg@mail.gmail.com>
To: Tim Ruffing <tim.ruffing@mmci.uni-saarland.de>,
Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="94eb2c0ef2e21f23c705638e98db"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Taproot: Privacy preserving switchable scripting
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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: Thu, 25 Jan 2018 00:09:34 -0000
--94eb2c0ef2e21f23c705638e98db
Content-Type: text/plain; charset="UTF-8"
Den 25 jan. 2018 00:22 skrev "Tim Ruffing via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org>:
I think you misread my second proposal. The first step is not only to
publish the hash but to publish a *pair* consisting of the hash and the
transaction.
If the attacker changes the transaction on the wire, the user does not
care and will try again.
I guess I assumed you meant it otherwise because I didn't assume you
intended a commitment to the full transaction just without the asymmetric
key material.
You could treat it the same way as in my suggestion, let it expire and
prune it if the key material isn't published in time.
However... A sufficiently powerful attacker can deploy as soon as he sees
your published signature and key, delay its propagation to the miners,
force expiration and then *still* repeat the attack with his own forgery.
Honestly, as long as we need to allow any form of expiry + relying on
publication of the vulnerable algorithms result for verification, I think
the weakness will remain.
No expiration hurts in multiple ways like via DoS, or by locking in
potentially wrong (or straight up malicious) transactions.
---
There's one way out, I believe, which is quantum safe Zero-knowledge
proofs. Currently STARK:s are one variant presumed quantum safe. It would
be used to completely substitute the publication of the public key and
signatures, and this way we don't even need two-step commitments.
It does however likely require a hardfork to apply to old transactions. (I
can imagine an extension block type softfork method, in which case old
UTXO:s get locked on the mainchain to create equivalent valued extension
block funds.)
Without practical ZKP, and presuming no powerful QC attackers with the
ability to control the network (basically NSA level attackers), I do think
the Fawkes signature scheme is sufficient. Quantum attacks are likely to be
very expensive anyway, for the foreseeable future.
--94eb2c0ef2e21f23c705638e98db
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div><div class=3D"gmail_extra"><br><div class=3D"gmail_q=
uote">Den 25 jan. 2018 00:22 skrev "Tim Ruffing via bitcoin-dev" =
<<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li=
sts.linuxfoundation.org</a>>:<blockquote class=3D"quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"quot=
ed-text">
<br>
</div>I think you misread my second proposal. The first step is not only to=
<br>
publish the hash but to publish a *pair* consisting of the hash and the<br>
transaction.<br>
<br>
If the attacker changes the transaction on the wire, the user does not<br>
care and will try again.<br></blockquote></div></div></div><div dir=3D"auto=
"><br></div><div dir=3D"auto">I guess I assumed you meant it otherwise beca=
use I didn't assume you intended a commitment to the full transaction j=
ust without the asymmetric key material.=C2=A0</div><div dir=3D"auto"><br><=
/div><div dir=3D"auto">You could treat it the same way as in my suggestion,=
let it expire and prune it if the key material isn't published in time=
.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">However... A suf=
ficiently powerful attacker can deploy as soon as he sees your published si=
gnature and key, delay its propagation to the miners, force expiration and =
then *still* repeat the attack with his own forgery.=C2=A0</div><div dir=3D=
"auto"><br></div><div dir=3D"auto">Honestly, as long as we need to allow an=
y form of expiry + relying on publication of the vulnerable algorithms resu=
lt for verification, I think the weakness will remain.=C2=A0</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">No expiration hurts in multiple ways =
like via DoS, or by locking in potentially wrong (or straight up malicious)=
transactions.</div><div dir=3D"auto"><br></div><div dir=3D"auto">---</div>=
<div dir=3D"auto"><br></div><div dir=3D"auto">There's one way out, I be=
lieve, which is quantum safe Zero-knowledge proofs.=C2=A0<span style=3D"fon=
t-family:sans-serif">Currently STARK:s are one variant presumed quantum saf=
e.=C2=A0</span>It would be used to completely substitute the publication of=
the public key and signatures, and this way we don't even need two-ste=
p commitments.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">It =
does however likely require a hardfork to apply to old transactions. (I can=
imagine an extension block type softfork method, in which case old UTXO:s =
get locked on the mainchain to create equivalent valued extension block fun=
ds.)</div><div dir=3D"auto"><br></div><div dir=3D"auto">Without practical Z=
KP,=C2=A0 and presuming no powerful QC attackers with the ability to contro=
l the network (basically NSA level attackers), I do think the Fawkes signat=
ure scheme is sufficient. Quantum attacks are likely to be very expensive a=
nyway, for the foreseeable future.=C2=A0</div><div dir=3D"auto"></div></div=
>
--94eb2c0ef2e21f23c705638e98db--
|
