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