To: Peter Todd <pete@petertodd.org>,
	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>
	<20161117084405.GA12334@savin.petertodd.org>
From: Eric Voskuil <eric@voskuil.org>
Message-ID: <1165cdfe-b3e0-b1d6-76b7-30e32144601d@voskuil.org>
Date: Thu, 17 Nov 2016 01:58:38 -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: <20161117084405.GA12334@savin.petertodd.org>
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="ojcTqCcLQecVSFjCIWew7dddjeT1jtl4g"
Subject: Re: [bitcoin-dev] BIP30 and BIP34 interaction (was Re: [BIP
 Proposal] Buried Deployments)
Precedence: list

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

On 11/17/2016 12:44 AM, Peter Todd wrote:
> On Wed, Nov 16, 2016 at 04:43:08PM -0800, Eric Voskuil via bitcoin-dev =
wrote:
>>> 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 ther=
e
>> is a tx hash collision, and implementations handle this differently, i=
t
>> 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
> If there is a tx hash collision it is almost certainly going to be beca=
use
> SHA256 has become weak..

Almost certainly is not certainly. Hash collisions happen because of chan=
ce.

BIP30 is quite explicit:

> "Fully-spent transactions are allowed to be duplicated in order not to
hinder pruning at some point in the future. Not allowing any transaction
to be duplicated would require evidence to be kept for each transaction
ever made."

BIP34 motivations:

> "2. Enforce block and transaction uniqueness, and assist unconnected
block validation."

But it only specifies making collisions harder, not impossible (i.e.
explicitly rejected by consensus).

Are you proposing that we draft a new BIP that allows us all to not have
to code for this? If we do so it will be impossible to guard against a
chain split due to pruning, but you seem to think that's unimportant.

e


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

iQEcBAEBAgAGBQJYLX9OAAoJEDzYwH8LXOFOMUQH/1vWIIm4Huf+vVJFCHmqVgyG
8ct06mdrSQJ1UdMlneux3NnzeuvJm1SBLlC4yAPXPYFJQt4XpoMbDKZFLx2apaq5
0s/+hYBqVVvrY3+Boo4zMOFFiXDO0hw8v20ZRNf1/ndRDe+tEjhA66o1msZVcEB+
eYnCwhdG1+PkoGHDxqEgJ+CSJ3x6GLwQpUUrytfZIot73bd4hpT5BYvUe+e9/FgR
Od99Jiy15DesL5DRiONRJcOZfC81pgJ90FEDQsgaUfe6YptX8tGh0n+OEgeoPWnc
OboNcPiJXaMYYa46KQZjrMFk1qNZEeCOKwHVokNtqk8TOCzRQ5rEecX9z3yuR1E=
=m3Y/
-----END PGP SIGNATURE-----

--ojcTqCcLQecVSFjCIWew7dddjeT1jtl4g--