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
|
Return-Path: <eric@voskuil.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 815FAB3E
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 Nov 2016 00:53:45 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pf0-f178.google.com (mail-pf0-f178.google.com
[209.85.192.178])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F13EF8D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 Nov 2016 00:53:44 +0000 (UTC)
Received: by mail-pf0-f178.google.com with SMTP id i88so45441376pfk.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Nov 2016 16:53:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=voskuil-org.20150623.gappssmtp.com; s=20150623;
h=subject:to:references:from:message-id:date:user-agent:mime-version
:in-reply-to; bh=BRHcscN3KBBYRVPTc/m/fls+8ZzvocvZJ7Cqg3sO7qY=;
b=ERLmKlT90+23CZig7pbmB2Fl35p7GRLvEgDmttAiD2O7nX66sI1al3f7xfK6OMVyqR
NAAKgLjzP1cTuoXYDl12oKEGGYwnFUglOWRPUJGScIUPxIy1MtHx/FxBqyMhS8mETBdu
lgUfdxNv9AaQybt7fFU8dw4l6Ikozg4r3svSWoXe3Uq/0zIl9W6cJ9NqD4NS8ohHhcW0
jLcIEkVSrOIA0nyFPg/UUWirquDmEkbDZ3UujexCiSpepafT9FB2waky9kWzvJ7dCiyf
CQH+c1/sBPWLcwFIHsu0+Q4m3+doxrynjzWdeGXaxqLSRlQ0pVIrFhmTaAc+SBKzQnBf
EBhw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:subject:to:references:from:message-id:date
:user-agent:mime-version:in-reply-to;
bh=BRHcscN3KBBYRVPTc/m/fls+8ZzvocvZJ7Cqg3sO7qY=;
b=LEuz1Pz8LRGKtgApZHkx8KrVu74JFTZuFslB1ct7ye2wRJQgZCvRfbV56LZGHOz1xc
tcAQ79Hn0jPBfw4Oo1uzibmAIZBZrop7O6vNcyZTxTABY/Z3LO0HkqFYFyzkLaf+2wBo
8Av/r27xaVl81tIPlNliHAZTM3MWpnjKTMXsbQd5lroOSNtaqtyDvI0LZDZ/T2SYI2x1
WYzuqW+16Z98rHbkQL7Dveusm4cbbAL/N5N7e5cDKCYv6nVmjyodIME7a690yKyE6rXh
IrcdFqvRTPzpAN51OYi5ST8i4abpsKHLA0mFCE6+L3wrUCH10PETasPtYUe87CTCuXzh
PTGg==
X-Gm-Message-State: ABUngvcYNSPsu0KA/uEffeh7zcgWOM7psU4s5hUt8vwQtfITPx6a3PPuOIswbsvOcCjzJg==
X-Received: by 10.99.117.71 with SMTP id f7mr1085366pgn.126.1479344024449;
Wed, 16 Nov 2016 16:53:44 -0800 (PST)
Received: from ?IPv6:2601:600:9000:d69e:8084:4206:2529:776d?
([2601:600:9000:d69e:8084:4206:2529:776d])
by smtp.gmail.com with ESMTPSA id 72sm498025pfw.37.2016.11.16.16.53.43
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Wed, 16 Nov 2016 16:53:43 -0800 (PST)
To: Tier Nolan <tier.nolan@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.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: Eric Voskuil <eric@voskuil.org>
X-Enigmail-Draft-Status: N1110
Message-ID: <b3e6473d-fd9c-2452-f673-930fc1322046@voskuil.org>
Date: Wed, 16 Nov 2016 16:53:45 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <e0e6679f-aec6-a579-667d-b5b58ea2360b@voskuil.org>
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="BAerLQSgxw9XmB2oMpUnoW0uL7FReeTvR"
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,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
X-Mailman-Approved-At: Thu, 17 Nov 2016 01:18:54 +0000
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 00:53:45 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--BAerLQSgxw9XmB2oMpUnoW0uL7FReeTvR
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Also, it's important to take note of the motivation behind not banning
duplicate tx hashes outright. Doing so would require that spent tx
hashes are retained forever. A pruning node will have no way of knowing
whether a new tx duplicates the hash of a preceding tx. Any
implementation that does retain such hashes and dismisses new txs on
that basis would fork against pruning nodes.
e
On 11/16/2016 04:43 PM, Eric Voskuil wrote:
>> This means that all future transactions will have different txids...
> rules do guarantee it.
>=20
> No, it means that the chance is small, there is a difference.
>=20
> If there is an address collision, someone may lose some money. If there=
> is a tx hash collision, and implementations handle this differently, it=
> will produce a chain split. As such this is not something that a node
> can just dismiss. If they do they are implementing a hard fork.
>=20
> e
>=20
> On 11/16/2016 04:31 PM, Tier Nolan via bitcoin-dev wrote:
>>
>>
>> On Thu, Nov 17, 2016 at 12:10 AM, Eric Voskuil via bitcoin-dev
>> <bitcoin-dev@lists.linuxfoundation.org
>> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>>
>> Both of these cases resulted from exact duplicate txs, which BIP34=
now
>> precludes. However nothing precludes different txs from having the=
same
>> hash.
>>
>>
>> The only way to have two transactions have the same txid is if their
>> parents are identical, since the txids of the parents are included in =
a
>> transaction.
>>
>> Coinbases have no parents, so it used to be possible for two of them t=
o
>> be identical.
>>
>> Duplicate outputs weren't possible in the database, so the later
>> coinbase transaction effectively overwrote the earlier one.
>>
>> The happened for two coinbases. That is what the exceptions are for.
>>
>> Neither of the those coinbases were spent before the overwrite
>> happened. I don't even think those coinbases were spent at all.
>>
>> This means that every activate coinbase transaction has a unique hash
>> and all new coinbases will be unique.
>>
>> This means that all future transactions will have different txids.
>>
>> There might not be an explicit rule that says that txids have to be
>> unique, but barring a break of the hash function, they rules do
>> guarantee it.
>=20
--BAerLQSgxw9XmB2oMpUnoW0uL7FReeTvR
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBAgAGBQJYLP+ZAAoJEDzYwH8LXOFO44UIAJKCj8c/lv6VM2ISJn+Inhvm
2NwWJUd8ruezqxGyvOxCADnPir2pSqZDWTf0+HqEr7eThN6MYwuvqXk1nzdmWwFn
E35v7KLkU0DDKeiih8DSCcO3KLfEWf7m1KesqsViNze3Gd9yUySsmOKWXHFSHWY8
VRm5nhWDHNqw4mUXb9h+ncO6F5Ben8qo8Q9QT6Wau9jsgBEz1vTJBgKHy0/DYxMi
CokGl2T3bHFbaIkzyJI8mtYo2YXSMo1g2Dz69c7TafF1o0sgPi7R+Ntw6b0cgLzp
eB40PHKOHOOK/qhoBKWBfQXOystSf9RUg7Zr9tZE3zXA3fXAO+Rvlk00+UKHnho=
=DdfR
-----END PGP SIGNATURE-----
--BAerLQSgxw9XmB2oMpUnoW0uL7FReeTvR--
|
