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
|
Return-Path: <tier.nolan@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id C9F86898
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 Nov 2016 10:22:30 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f172.google.com (mail-qk0-f172.google.com
[209.85.220.172])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 442AF1AC
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 Nov 2016 10:22:30 +0000 (UTC)
Received: by mail-qk0-f172.google.com with SMTP id n204so212415653qke.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 Nov 2016 02:22:30 -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:cc;
bh=/RXUTpd6thu9I4sQGJxKT0vCJHRCsOR2hf32szykWjc=;
b=E3mRfXjJU43ApyExxzb5wZ+4NeBJcj5RD4BPK4WfBpdgbL4X8xZZ2/B7Oc1ck0hYZc
UqpbFM06xvoFmq/1qRFlNWihk3/+V7oUKSMfgYZMjaa2vdAWIH/Ec+bNGa47xQ+23ScX
CjfRjSXzpPthAy8L003WPyU6BREV8z+ewhxAjwsjV6Nnh9EYWFk/7NeBno2oAG/FSGKi
N4ll2U7mhWwNdsxWSkSLitka+d/9x6kAleKQxyve2viEx5FSh9sObkuZ9A6TTuftQKuy
8P2Hwre8Wgbo09qgTDPqLjHcwzP040HcOsRNcwAogqqyOqhet9Ro28fAZrPmRqvT3Xel
4vJA==
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:cc;
bh=/RXUTpd6thu9I4sQGJxKT0vCJHRCsOR2hf32szykWjc=;
b=FSr1txJKBQkgBVKXG8UzWWWdDfLubcZz9/Lea59Y8+nO0a3STkl+7QhNlj8nW24A4y
HDGy5kgUsf0fwkspvRpVDhnNWtcwGEQgrH3hK4GXG2Of/w8OAT1ax55qcmJjsM7sApju
9qREOmzXwu6RxYgVUIUREIWT0FOCnuGt7BM06eKKav4IkajOHkgqHPLcVC0bX7xnG6C2
qgM/eiHlOBBIpDurCbv7EIp9dlfTfzkK54NIT5rrFX27Cav1DUfa2Mf6ybNzg21joflv
gHy8hgfAVVwsu4mqtMMh4JzfX2WU5Ifj6796t9iR7KJIssOYe8wKlHMya3+Bw35bwDsJ
OQaA==
X-Gm-Message-State: AKaTC01bvxm/T13llSvqFU+JUCnLugnF97Uin5vtvseJMTw1b9RJ6UpmXZBXnqTVrNhCZC1OeRwt+VlmA8+S9w==
X-Received: by 10.55.209.150 with SMTP id o22mr2093054qkl.274.1479378149368;
Thu, 17 Nov 2016 02:22:29 -0800 (PST)
MIME-Version: 1.0
Received: by 10.237.55.227 with HTTP; Thu, 17 Nov 2016 02:22:28 -0800 (PST)
In-Reply-To: <e0e6679f-aec6-a579-667d-b5b58ea2360b@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>
From: Tier Nolan <tier.nolan@gmail.com>
Date: Thu, 17 Nov 2016 10:22:28 +0000
Message-ID: <CAE-z3OXfJa3Lewtrafm25bdfPa=eiarOAXBNbgc3ccTi7Qoe6A@mail.gmail.com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a1147a40414e97b05417c919e
X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MISSING_HEADERS,
RCVD_IN_DNSWL_LOW,RCVD_IN_SORBS_SPAM autolearn=no 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 10:22:31 -0000
--001a1147a40414e97b05417c919e
Content-Type: text/plain; charset=UTF-8
On Thu, Nov 17, 2016 at 12:43 AM, Eric Voskuil <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.
In terms of discussing the BIP, barring a hash collision, it does make
duplicate txids 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".
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.
--001a1147a40414e97b05417c919e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Thu, Nov 17, 2016 at 12:43 AM, Eric Voskuil <span dir=3D"ltr"><<a=
target=3D"_blank" href=3D"mailto:eric@voskuil.org">eric@voskuil.org</a>>=
;</span> wrote:<br><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t:1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote">> T=
his means that all future transactions will have different txids...<br>
rules do guarantee it.<br>
<br>
No, it means that the chance is small, there is a difference.<br></blockquo=
te><div><br></div><div>I think we are mostly in agreement then?=C2=A0 It is=
just terminology.<br><br></div><div>In terms of discussing the BIP, barrin=
g a hash collision, it does make duplicate txids impossible.<br><br></div><=
div>Given that a hash collision is so unlikely, the qualifier should be add=
ed to those making claims that require hash collisions rather than those wh=
o assume that they aren't possible.<br><br></div><div>You could have sa=
id "<span class=3D"gmail-im">However nothing precludes different txs f=
rom having the same hash</span>, but it requires a hash collision".<br=
><br></div><div>Thinking about it, a re-org to before the enforcement heigh=
t could allow it.=C2=A0 The checkpoints protect against that though.<br></d=
iv><div>=C2=A0<br></div><blockquote style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote">A=
s such this is not something that a node<br>
can just dismiss. </blockquote><div><br></div><div>The security of many par=
ts of the system is based on hash collisions not being possible.<br></div><=
/div></div></div>
--001a1147a40414e97b05417c919e--
|
