summaryrefslogtreecommitdiff
path: root/d5/efc81e7e01d651fc04989a063fd740cf6b8411
blob: 3b50e6cdd72a0670eedba9c7a6247edf971d204e (plain)
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
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 C49F3826
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 17 Nov 2016 00:43:08 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pg0-f45.google.com (mail-pg0-f45.google.com [74.125.83.45])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4295A1B8
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 17 Nov 2016 00:43:08 +0000 (UTC)
Received: by mail-pg0-f45.google.com with SMTP id p66so84796286pga.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 16 Nov 2016 16:43:08 -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=VPJCpn0EPVbWlMRAwh9Z5stBW1hf0KVgmTM+maP7b9M=;
	b=Uif16Hv73wmgz88AcxseycGJHq1ssZTsgiITx6/sNCvnwVb9i9EF1A7zI7FF+EBjrs
	ruskcDmzmhLnhN5gHUMfZnOJu2sPBVbzspVvkJ3RA3MO9L1ty4JQd7osmuQgvGPXQq4K
	l+Tw0uB9jVn+/OSfkbl3B0bJF5sB70wdywVBQG/KVw6YFCcmj8CbdRX1Ry2q7Lz4Kxwq
	0HoyA5EHkJR9FX05z7N+fi0b0l0fdFy44C44Da+8KltCXllOWKJ79rBUNKpHVNGTmG8W
	Y9LagoMJHMF/y8CKcujzrDGKB59WmS3pZTF3XOgCxPpccY9965Rc3vUwb59cDQm4QuLm
	2+Kw==
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=VPJCpn0EPVbWlMRAwh9Z5stBW1hf0KVgmTM+maP7b9M=;
	b=CWwE/FBv/HVuoGXupuYTJFeFCV5znAKmHBZUC/Fwao4zuBHgHu3uMw5KYqNI2f+vU8
	kTm42VLj7GMFcVb64KnII2aZ2xM7iposcdMZkxSJizDD8sixliGBlUxIdSkMnlfpBS78
	p1DaV86UoDoje8xAuiOEqUSvKz/JqXKlZ6JJLyiNXSeZ7/dO973ilv0hoOWagGArmDce
	FTrmd4/lL0L+V9Ku/V9fAVHNj9nD8GODxnffe+FC/dXqYDXnRwGvfeovT9xlcHGniKAc
	SHIpCcXVVkg6tiTR12IlEyZNv6N1oPMuHTiuYwdtRswcLdQ3iLpTNx81C7TZBsuEJVB5
	eGvg==
X-Gm-Message-State: ABUngvfDeQd6pHkiZJqReWGhR9fQvKs33HWtp+cPdmCVveaBfwjuOomGT4EFitjweSRiAQ==
X-Received: by 10.98.137.153 with SMTP id n25mr558249pfk.89.1479343387639;
	Wed, 16 Nov 2016 16:43:07 -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
	f132sm427424pfa.72.2016.11.16.16.43.06
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 16 Nov 2016 16:43:07 -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>
From: Eric Voskuil <eric@voskuil.org>
X-Enigmail-Draft-Status: N0110
Message-ID: <e0e6679f-aec6-a579-667d-b5b58ea2360b@voskuil.org>
Date: Wed, 16 Nov 2016 16:43:08 -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: <CAE-z3OX5vak25UWcmBSe63OmoOVoGB394WmwyWwUcSxWeDOLhw@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="0Q0sNEpeJDR9XeBRv1tPOJC9sGi0QKtEG"
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 00:44:17 +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:43:08 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--0Q0sNEpeJDR9XeBRv1tPOJC9sGi0QKtEG
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

> 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.

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.

e

On 11/16/2016 04:31 PM, Tier Nolan via bitcoin-dev wrote:
>=20
>=20
> 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:
>=20
>     Both of these cases resulted from exact duplicate txs, which BIP34 =
now
>     precludes. However nothing precludes different txs from having the =
same
>     hash.
>=20
>=20
> 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.
>=20
> Coinbases have no parents, so it used to be possible for two of them to=

> be identical.
>=20
> Duplicate outputs weren't possible in the database, so the later
> coinbase transaction effectively overwrote the earlier one.
>=20
> The happened for two coinbases.  That is what the exceptions are for.
>=20
> Neither of the those coinbases were spent before the overwrite
> happened.  I don't even think those coinbases were spent at all.
>=20
> This means that every activate coinbase transaction has a unique hash
> and all new coinbases will be unique.
>=20
> This means that all future transactions will have different txids.
>=20
> 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.


--0Q0sNEpeJDR9XeBRv1tPOJC9sGi0QKtEG
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)

iQEcBAEBAgAGBQJYLP0cAAoJEDzYwH8LXOFOIssH/1Jyz0FOom4g8IeXYFR9VNdw
eUoovWZlFQvyz11QTp8IGm7G3Cb5wFn45Sb31crJXsoAwXek5AGlcZWaNoxoFSbE
N9C2VYjlXc2cCTY/4NIXTxsTGzum/e839QJg4/B1Y108poSOk9e6rU6iMDZxck00
Qb32T3jz563Fx1q//s33eTxjEmI/vKEuLHqev14fmRPpPkStAvq5lfM9VS2km8rq
Qij1dv+70MWLMqFvWbItig93UQ+hc4Ptdeeo6zqhWdqZK4veoY5WRmJC42RNtTa9
k5U2ZotOBRKV6TzWVEukj84pvB/GVAVnWdHbwfpEvA+wNN0RVuD515n2CbV+XAw=
=HIWH
-----END PGP SIGNATURE-----

--0Q0sNEpeJDR9XeBRv1tPOJC9sGi0QKtEG--