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
|
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 373F6AB9
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 Nov 2016 00:31:04 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f176.google.com (mail-qk0-f176.google.com
[209.85.220.176])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id AB9CF1A8
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 Nov 2016 00:31:03 +0000 (UTC)
Received: by mail-qk0-f176.google.com with SMTP id n204so198673102qke.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Nov 2016 16:31:03 -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=gkw9M4liXNRqgqTJlzyd6TYDk8LHJB/j8QaMn9QMG3Q=;
b=PpWrnf7rEaO68v2y4flbcUOIECixwVAbPJbpeH9MSdToqvJLuoRX89e8fp8Z/YGnqJ
ZH1ruLQVMS+DM+Ax+bAW87KMvZbuwHGM0bPQUbjRC8hZLixgZxJYIiPzI3dER4QBvhlg
Ozlae2lu/CZJSuKfa1PX3T8PzUEtyfK2s9zwaFOfdIcTxL1IQQXg+Evvbr2SLu6dpHMw
BxotUukmy4cxRaRbMoSNStGJl4ugomJx/WdDLqQhlD1uGt2aFC3Plc9fdS59e0emyiHi
IBKNeGGZ1b/hSk3SoGTriSIWlQeUnFosX1IJTCADpYJuqv17+B+/YY8AOhSFQRTBtarQ
WCfw==
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=gkw9M4liXNRqgqTJlzyd6TYDk8LHJB/j8QaMn9QMG3Q=;
b=UZzQe2VBtmUrpShJ+gFZ89v35xX4IjCUN4Csztq6K8UWfdg5KVf89K7ykofETdW5hK
dEPA0qkyKV99ALDEM4WakYiJdnbdNrZkfWLCey7DnV04R+ecwD5BNafDzmp/jSwydSRs
UxCE1AgS76ngy7EdUFxlxMYnlLAdHXq7TycbEyFS1Y8ryUJzQ68pMnSqDPDFiGgsNFQ5
vcF2pzzdGUQ2B3+xzRrMt9PxnG29vi0RgBLOJp1jmlzQbdbRWyOeQyX7hDNacFG4bDlI
akER7dZXlE+2edm6RcoDOgNKiep4He61fTOY3wQb4G/Wf2Q3xFiElUau1NcIh6WjECVT
HCCQ==
X-Gm-Message-State: AKaTC01KpmCyOCjdIuL4EMgy0EdFpCzElkDfj+A11xC/kugzGlalhQNBRhfpftN2BoyxQhF84vrRZfrqpGhbww==
X-Received: by 10.55.209.150 with SMTP id o22mr388525qkl.274.1479342662772;
Wed, 16 Nov 2016 16:31:02 -0800 (PST)
MIME-Version: 1.0
Received: by 10.237.55.227 with HTTP; Wed, 16 Nov 2016 16:31:02 -0800 (PST)
In-Reply-To: <d58ee114-00fd-23c8-9ca7-9a4b28c26f27@voskuil.org>
References: <CABm2gDr2-MCiaFFjgUFP5Xc0fQfuqJ3=ZkrzjHqmOiwRZ50CBw@mail.gmail.com>
<d58ee114-00fd-23c8-9ca7-9a4b28c26f27@voskuil.org>
From: Tier Nolan <tier.nolan@gmail.com>
Date: Thu, 17 Nov 2016 00:31:02 +0000
Message-ID: <CAE-z3OX5vak25UWcmBSe63OmoOVoGB394WmwyWwUcSxWeDOLhw@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a1147a404ea6e6c0541744d1e
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE,
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 00:31:04 -0000
--001a1147a404ea6e6c0541744d1e
Content-Type: text/plain; charset=UTF-8
On Thu, Nov 17, 2016 at 12:10 AM, Eric Voskuil via bitcoin-dev <
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 to 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.
--001a1147a404ea6e6c0541744d1e
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:10 AM, Eric Voskuil via bitcoin-dev <span di=
r=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targ=
et=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex">
Both of these cases resulted from exact duplicate txs, which BIP34 now<br>
precludes. However nothing precludes different txs from having the same<br>
hash.<br></blockquote><div><br></div><div>The only way to have two transact=
ions have the same txid is if their parents are identical, since the txids =
of the parents are included in a transaction.<br><br></div><div>Coinbases h=
ave no parents, so it used to be possible for two of them to be identical.<=
br><br></div><div>Duplicate outputs weren't possible in the database, s=
o the later coinbase transaction effectively overwrote the earlier one.<br>=
<br></div><div>The happened for two coinbases.=C2=A0 That is what the excep=
tions are for.<br><br></div><div>Neither of the those coinbases were spent =
before the overwrite happened.=C2=A0 I don't even think those coinbases=
were spent at all.<br><br></div><div>This means that every activate coinba=
se transaction has a unique hash and all new coinbases will be unique.<br><=
br></div><div>This means that all future transactions will have different t=
xids.<br><br></div><div>There might not be an explicit rule that says that =
txids have to be unique, but barring a break of the hash function, they rul=
es do guarantee it.<br></div></div></div></div>
--001a1147a404ea6e6c0541744d1e--
|
