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
|
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 6CF2FFEC
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 15 Feb 2018 22:44:08 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com [74.125.82.51])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D0DF9D3
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 15 Feb 2018 22:44:07 +0000 (UTC)
Received: by mail-wm0-f51.google.com with SMTP id x21so62037wmh.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 15 Feb 2018 14:44:07 -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=FySVwj1WG1AlAchT+Nai19jusgEPoQdr8CLbqSGQvlg=;
b=OGh2tGe36HrgfY92jkHR7dYWlqgSCvfm1IgyCQykiiaXxoJH6x4cuWtG0Oj3xwvcCt
9VOvNZsmbu1R8J8dQ9rJZgbGJH9qZ/+TwnMZJgkxjBYdrRzgoiUaUOMSOxYjsHv73NcW
npSpG1Vd2A7/Uy17miSwEHA3h+uEPUO69GpTie20YhBiuIbDBR/TmdI3zj7zOOsSNjDv
9V3noa15Ln77gQjUlvOhCb/piRQsYVAYVgOXusFCXsoVDLYrkvZBy7uyRVqZkhI/mpG3
LzZ8aOg8fwSVK2vcH3OHV/0Y1yXuZUBFUfkjimRtaakAfW/WqPdlhAtAuGNB1nhijt0y
La6Q==
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=FySVwj1WG1AlAchT+Nai19jusgEPoQdr8CLbqSGQvlg=;
b=ai6uApaCYSMkRlC13Ff+aNSzgYOaPCFXUc/G7DrbmYWTiZ3QvQfDYtPyYKNjjNA3Vg
TA/Fm4rUSsXFRlB27EjA3Zvyml7tJr9Cink8zUqSZg8roCaR4n3nqY2GZSah1aZ9zEIY
f8jt++mFPPqmwdsyUj29ynez95DLfWGOLOO805O1jpfLnZ5qjc4UWMRmBtHzobcSh7Gk
RxgLVaIdtZXXpoK5OQpdU3wzSkZ37FcvlrZQHyTi0qSuJ6jjFvDyg52ema/EkiV/rRVn
KBzzti+irWQpyRsS5aNlQAG3q/9mp5W9CT4m0XpprGAKOrZNVTWnF5DdWTNFTEV0iAyY
3LeQ==
X-Gm-Message-State: APf1xPC6Td/Qk2tDUu96EndON4D6urMVFYpJDwjriHTsmVN2rOF74mPA
CaeE17Pw9MADjK8s7O159K27j3Xw8P+U97IQKFs=
X-Google-Smtp-Source: AH8x225+si61Hghs0OR/42LGhq96WjM3xx6JneCrcYV25PSNvkIZFlI9n4rO0ACo46tvV30rGE2tr8fzez+MckehXw0=
X-Received: by 10.80.151.137 with SMTP id e9mr5391106edb.102.1518734646425;
Thu, 15 Feb 2018 14:44:06 -0800 (PST)
MIME-Version: 1.0
Received: by 10.80.169.74 with HTTP; Thu, 15 Feb 2018 14:44:05 -0800 (PST)
Received: by 10.80.169.74 with HTTP; Thu, 15 Feb 2018 14:44:05 -0800 (PST)
In-Reply-To: <1518731861.3550.131.camel@mmci.uni-saarland.de>
References: <CAFEpHQHP7XXBYUP6CF1OeYoBpj0UwK+qpYG-14_zQZDX4Md7UA@mail.gmail.com>
<1518450650.7829.87.camel@mmci.uni-saarland.de>
<CAFEpHQHYdE3m2GUtN=ijvtYUudwtcG52rRxzH66VFbgO1KEihw@mail.gmail.com>
<1518504374.9878.24.camel@mmci.uni-saarland.de>
<882306fa-3ea0-99bd-61c6-f646d27c2ab6@gmail.com>
<1518710367.3550.111.camel@mmci.uni-saarland.de>
<CAAt2M1-JtmcMH2WCx5T5U8B-B+Ob61WPSvX4JoOcWzYFCLSTmw@mail.gmail.com>
<1518731861.3550.131.camel@mmci.uni-saarland.de>
From: Natanael <natanael.l@gmail.com>
Date: Thu, 15 Feb 2018 23:44:05 +0100
Message-ID: <CAAt2M1-0-c1-OC0g0_6aBueR8wU+ipPw4U_zSLkdoh3K79PWsw@mail.gmail.com>
To: Tim Ruffing <tim.ruffing@mmci.uni-saarland.de>,
Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="f403045c268e1bc01d056547f7e4"
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] Transition to post-quantum
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, 15 Feb 2018 22:44:08 -0000
--f403045c268e1bc01d056547f7e4
Content-Type: text/plain; charset="UTF-8"
Den 15 feb. 2018 22:58 skrev "Tim Ruffing via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org>:
Also, the miners will indeed see one valid decommitment. This
decommitment may have been sent by the attacker but it's the preimage
chal of the address, because otherwise it's not valid for the malicious
commitment. But if the decommitment is chal, then this decommitment is
also valid for the commitment of the honest user, which is earliest
additionally. So the honest commitment wins. The attacker does not
succeed and everything is fine.
The reason why this works:
There is only one unique decommitment for the UTXO (assuming H_addr is
collision-resistant). The decommitment does not depend on the
commitment. The attacker cannot send a different decommitment, just
because there is none.
If your argument is that we publish the full transaction minus the public
key and signatures, just committing to it, and then revealing that later
(which means an attacker can't modify the transaction in advance in a way
that produces a valid transaction);
Allowing expiration retains insecurity, while allowing expiration makes it
a trivial DoS target.
Anybody can flood the miners with invalid transaction commitments. No miner
can ever prune invalid commitments until a valid transaction is finalized
which conflicts with the invalid commitments. You can't even rate limit it
safely.
Like I said in the other thread, this is unreasonable. It's much more
practical with simple hash commitment that you can "fold away" in a Merkle
tree hash and which you don't need to validate until the full transaction
is published.
--f403045c268e1bc01d056547f7e4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div><br><div class=3D"gmail_extra"><br><div class=3D"gma=
il_quote">Den 15 feb. 2018 22:58 skrev "Tim Ruffing via bitcoin-dev&qu=
ot; <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-de=
v@lists.linuxfoundation.org</a>>:<br type=3D"attribution"><blockquote cl=
ass=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div class=3D"quoted-text"><br></div>
Also, the miners will indeed see one valid decommitment. This<br>
decommitment may have been sent by the attacker but it's the preimage<b=
r>
chal of the address, because otherwise it's not valid for the malicious=
<br>
commitment. But if the decommitment is chal, then this decommitment is<br>
also valid for the commitment of the honest user, which is earliest<br>
additionally. So the honest commitment wins. The attacker does not<br>
succeed and everything is fine.<br>
<br>
The reason why this works:<br>
There is only one unique decommitment for the UTXO (assuming H_addr is<br>
collision-resistant). The decommitment does not depend on the<br>
commitment. The attacker cannot send a different decommitment, just<br>
because there is none.<br></blockquote></div></div></div><div dir=3D"auto">=
<br></div><div dir=3D"auto">If your argument is that we publish the full tr=
ansaction minus the public key and signatures, just committing to it, and t=
hen revealing that later (which means an attacker can't modify the tran=
saction in advance in a way that produces a valid transaction);</div><div d=
ir=3D"auto"><br></div><div dir=3D"auto">Allowing expiration retains insecur=
ity, while allowing expiration makes it a trivial DoS target.=C2=A0</div><d=
iv dir=3D"auto"><br></div><div dir=3D"auto">Anybody can flood the miners wi=
th invalid transaction commitments. No miner can ever prune invalid commitm=
ents until a valid transaction is finalized which conflicts with the invali=
d commitments. You can't even rate limit it safely.=C2=A0</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">Like I said in the other thread, this=
is unreasonable. It's much more practical with=C2=A0 simple hash commi=
tment that you can "fold away" in a Merkle tree hash and which yo=
u don't need to validate until the full transaction is published.=C2=A0=
</div><div dir=3D"auto"><div class=3D"gmail_extra"><div class=3D"gmail_quot=
e"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"></blockquote></div></div></div></div>
--f403045c268e1bc01d056547f7e4--
|
