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
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
|
Return-Path: <morcos@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 94F5CA87
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 Nov 2016 11:38:15 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-it0-f44.google.com (mail-it0-f44.google.com
[209.85.214.44])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DAA8E306
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 Nov 2016 11:38:13 +0000 (UTC)
Received: by mail-it0-f44.google.com with SMTP id c20so272266461itb.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 Nov 2016 03:38:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
bh=lFOZqi0cGDgzLOy+6zbm2wQJxQ8CCdIFoXt9gkwsjYA=;
b=YW5C5RGFE94J5T85cJ3PAbredmGwzMPKMHVgVlZTDmR/kK6eEO3lhXXacBxmtBJVxc
P941iNynp0NQpH/kjvpB8pP+q2hwWlt8VMnHZyf18deSJDLp3CMHpRFbNYgQnUGRQFaG
8N7tzUkL5GeW4smU1jkQez26lVjtPRYgLg+4n12iapkv3CgHjgNvm371bqkxSLoslix7
rKO5j6IOkS1Hx6BGL2zE35JX0CpcgTqALjo47Bm/cqkgNWgiolOaM6vAjgn71P/4TQqJ
IVTOcXc4HSz8sI52LqgvCsanTf2dipO78no0luNqY3uG5Ub632idorkfIFU8eQf8qjKZ
Qxow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to;
bh=lFOZqi0cGDgzLOy+6zbm2wQJxQ8CCdIFoXt9gkwsjYA=;
b=lY2sYVRf+vGElqX5DTGobL0Tl47OmVA/PnfJEcnyIQzLPwdHYASLp0giQpQlU3Doq0
bBTeO7dsrpQ3cZGqQ8oAF7xWctdTf+8qYRR+6wUDvAjDE2PLV7iXc+q/3SPkp4u8sjHB
4aV2tF3aLkBvgr8uYU/MdgYS8noc4QIvkx5MKWgM5CGXrXjCCBU60W5QCH/HV3/HceDc
px3AWjo7NFZDWOXGXpGnWQXZz5fFJoqCQHC8ZxAkY1n1tvoTosdWdq0Dc/vNvZlaVUAb
knoL3ZSXL0EhyH8iqrWbL4ITEDSuaiduKIKTwkVgvWfOJgQEujFrIQCNKZtk977t9Y20
6kUg==
X-Gm-Message-State: ABUngvdwQJBAmnv7Aae0rA6bYu8ZhxmBYlVml/jh+GC4VW4n3HKgorEIz6sVE3ASHEFIyxfzbQCU8hzBgBe1sg==
X-Received: by 10.36.123.82 with SMTP id q79mr12120507itc.25.1479382693070;
Thu, 17 Nov 2016 03:38:13 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.119.199 with HTTP; Thu, 17 Nov 2016 03:38:12 -0800 (PST)
In-Reply-To: <5ef23296-5909-a350-ab11-e717f8fffc41@voskuil.org>
References: <CABm2gDr2-MCiaFFjgUFP5Xc0fQfuqJ3=ZkrzjHqmOiwRZ50CBw@mail.gmail.com>
<d58ee114-00fd-23c8-9ca7-9a4b28c26f27@voskuil.org>
<CAE-z3OX5vak25UWcmBSe63OmoOVoGB394WmwyWwUcSxWeDOLhw@mail.gmail.com>
<e0e6679f-aec6-a579-667d-b5b58ea2360b@voskuil.org>
<CAE-z3OXfJa3Lewtrafm25bdfPa=eiarOAXBNbgc3ccTi7Qoe6A@mail.gmail.com>
<5ef23296-5909-a350-ab11-e717f8fffc41@voskuil.org>
From: Alex Morcos <morcos@gmail.com>
Date: Thu, 17 Nov 2016 06:38:12 -0500
Message-ID: <CAPWm=eW9X77+qQZGHkAOjN-k7KFwq06gKS6HOVOTE1+SmYBhWA@mail.gmail.com>
To: Eric Voskuil <eric@voskuil.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a11474ba4e84b8905417d9f61
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_LOW,
RCVD_IN_SORBS_SPAM 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] BIP30 and BIP34 interaction (was Re: [BIP
Proposal] Buried Deployments)
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, 17 Nov 2016 11:38:15 -0000
--001a11474ba4e84b8905417d9f61
Content-Type: text/plain; charset=UTF-8
I think this conversation has gone off the rails and is no longer really
appropriate for the list.
But just to be clear to any readers. Bitcoin Core absolutely does rely on
the impossibility of a hash collision for maintaining consensus. This
happens in multiple places in the code but in particular we don't check
BIP30 any more since the only way it could get violated is by a hash
collision.
On Thu, Nov 17, 2016 at 6:22 AM, Eric Voskuil via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On 11/17/2016 02:22 AM, Tier Nolan via bitcoin-dev wrote:
> > On Thu, Nov 17, 2016 at 12:43 AM, Eric Voskuil <eric@voskuil.org
> > <mailto:eric@voskuil.org>> wrote:
> >
> > > This means that all future transactions will have different
> txids...
> > rules do guarantee it.
> >
> > No, it means that the chance is small, there is a difference.
> >
> > I think we are mostly in agreement then? It is just terminology.
>
> Sure, if you accept that mostly is not fully - just as unlikely is not
> impossible.
>
> > In terms of discussing the BIP, barring a hash collision, it does make
> > duplicate txids impossible.
>
> That's like saying, as long as we exclude car accidents from
> consideration, car accidents are impossible.
>
> > Given that a hash collision is so unlikely, the qualifier should be
> > added to those making claims that require hash collisions rather than
> > those who assume that they aren't possible.
> >
> > You could have said "However nothing precludes different txs from having
> > the same hash, but it requires a hash collision".
>
> I generally try to avoid speaking in tautologies :)
>
> > Thinking about it, a re-org to before the enforcement height could allow
> > it. The checkpoints protect against that though.
> >
> > As such this is not something that a node
> > can just dismiss.
> >
> > The security of many parts of the system is based on hash collisions not
> > being possible.
>
> This is not the case.
>
> Block hash duplicates within the same chain are invalid as a matter of
> consensus, which is the opposite of assuming impossibility.
>
> Tx hash collisions are explicitly allowed in the case that preceding tx
> with the same hash is unspent. This is also not a reliance on the
> impossibility of hash collision. Core certainly implements this
> distinction:
>
> https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L2419-L2426
>
> Address hashes and script hashes can collide without harming the
> security of Bitcoin (although address owner(s) may experience harm).
> Rare in this case is sufficient because of this distinction.
>
> Compact blocks contemplates hash collisions:
>
> https://github.com/bitcoin/bips/blob/master/bip-0152.
> mediawiki#Random_collision_probabilty
>
> Checkpoints aren't part of Bitcoin security, so even the remote
> possibility of two different potential blocks, with the same hash, at
> the same height in the same chain, does not indicate a problem.
>
> There is no case where the security of Bitcoin assumes that hashes never
> collide. Consensus rules have specific handling for both block hash
> collisions and tx hash collisions.
>
> e
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--001a11474ba4e84b8905417d9f61
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I think this conversation has gone off the rails and is no=
longer really appropriate for the list.<div><br></div><div>But just to be =
clear to any readers.=C2=A0 Bitcoin Core absolutely does rely on the imposs=
ibility of a hash collision for maintaining consensus.=C2=A0 This happens i=
n multiple places in the code but in particular we don't check BIP30 an=
y more since the only way it could get violated is by a hash collision.=C2=
=A0</div><div><br></div><div><br></div><div><br></div><div><br></div></div>=
<div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, Nov 17, 2=
016 at 6:22 AM, Eric Voskuil via bitcoin-dev <span dir=3D"ltr"><<a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin=
-dev@lists.linuxfoundation.org</a>></span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><span class=3D"">On 11/17/2016 02:22 AM, Tier Nolan via bitco=
in-dev wrote:<br>
> On Thu, Nov 17, 2016 at 12:43 AM, Eric Voskuil <<a href=3D"mailto:e=
ric@voskuil.org">eric@voskuil.org</a><br>
</span><span class=3D"">> <mailto:<a href=3D"mailto:eric@voskuil.org"=
>eric@voskuil.org</a>>> wrote:<br>
><br>
>=C2=A0 =C2=A0 =C2=A0> This means that all future transactions will h=
ave different txids...<br>
>=C2=A0 =C2=A0 =C2=A0rules do guarantee it.<br>
><br>
>=C2=A0 =C2=A0 =C2=A0No, it means that the chance is small, there is a d=
ifference.<br>
><br>
> I think we are mostly in agreement then?=C2=A0 It is just terminology.=
<br>
<br>
</span>Sure, if you accept that mostly is not fully - just as unlikely is n=
ot<br>
impossible.<br>
<span class=3D""><br>
> In terms of discussing the BIP, barring a hash collision, it does make=
<br>
> duplicate txids impossible.<br>
<br>
</span>That's like saying, as long as we exclude car accidents from<br>
consideration, car accidents are impossible.<br>
<span class=3D""><br>
> Given that a hash collision is so unlikely, the qualifier should be<br=
>
> added to those making claims that require hash collisions rather than<=
br>
> those who assume that they aren't possible.<br>
><br>
> You could have said "However nothing precludes different txs from=
having<br>
> the same hash, but it requires a hash collision".<br>
<br>
</span>I generally try to avoid speaking in tautologies :)<br>
<span class=3D""><br>
> Thinking about it, a re-org to before the enforcement height could all=
ow<br>
> it.=C2=A0 The checkpoints protect against that though.<br>
><br>
>=C2=A0 =C2=A0 =C2=A0As such this is not something that a node<br>
>=C2=A0 =C2=A0 =C2=A0can just dismiss.<br>
><br>
> The security of many parts of the system is based on hash collisions n=
ot<br>
> being possible.<br>
<br>
</span>This is not the case.<br>
<br>
Block hash duplicates within the same chain are invalid as a matter of<br>
consensus, which is the opposite of assuming impossibility.<br>
<br>
Tx hash collisions are explicitly allowed in the case that preceding tx<br>
with the same hash is unspent. This is also not a reliance on the<br>
impossibility of hash collision. Core certainly implements this distinction=
:<br>
<br>
<a href=3D"https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L241=
9-L2426" rel=3D"noreferrer" target=3D"_blank">https://github.com/bitcoin/<w=
br>bitcoin/blob/master/src/main.<wbr>cpp#L2419-L2426</a><br>
<br>
Address hashes and script hashes can collide without harming the<br>
security of Bitcoin (although address owner(s) may experience harm).<br>
Rare in this case is sufficient because of this distinction.<br>
<br>
Compact blocks contemplates hash collisions:<br>
<br>
<a href=3D"https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki#R=
andom_collision_probabilty" rel=3D"noreferrer" target=3D"_blank">https://gi=
thub.com/bitcoin/<wbr>bips/blob/master/bip-0152.<wbr>mediawiki#Random_colli=
sion_<wbr>probabilty</a><br>
<br>
Checkpoints aren't part of Bitcoin security, so even the remote<br>
possibility of two different potential blocks, with the same hash, at<br>
the same height in the same chain, does not indicate a problem.<br>
<br>
There is no case where the security of Bitcoin assumes that hashes never<br=
>
collide. Consensus rules have specific handling for both block hash<br>
collisions and tx hash collisions.<br>
<br>
e<br>
<br>
<br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br></div>
--001a11474ba4e84b8905417d9f61--
|
