MIME-Version: 1.0
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
Subject: Re: [bitcoin-dev] BIP30 and BIP34 interaction (was Re: [BIP
 Proposal] Buried Deployments)
Precedence: list

--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">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targ=
et=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</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&#39;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&#39;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--