To: Alex Morcos <morcos@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>
	<CAE-z3OXfJa3Lewtrafm25bdfPa=eiarOAXBNbgc3ccTi7Qoe6A@mail.gmail.com>
	<5ef23296-5909-a350-ab11-e717f8fffc41@voskuil.org>
	<CAPWm=eW9X77+qQZGHkAOjN-k7KFwq06gKS6HOVOTE1+SmYBhWA@mail.gmail.com>
From: Eric Voskuil <eric@voskuil.org>
Message-ID: <34949746-c0c9-7f14-0e92-69d5a7d44b04@voskuil.org>
Date: Thu, 17 Nov 2016 04:22:09 -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: <CAPWm=eW9X77+qQZGHkAOjN-k7KFwq06gKS6HOVOTE1+SmYBhWA@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="HQVQNhxjAKHdbObmF0J7vTivF7XK4A9BA"
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)
--HQVQNhxjAKHdbObmF0J7vTivF7XK4A9BA
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 11/17/2016 03:38 AM, Alex Morcos wrote:
> I think this conversation has gone off the rails and is no longer reall=
y
> appropriate for the list.

If this discussion is not appropriate for the Bitcoin Protocol
Discussion list then the list is pointless.

> But just to be clear to any readers.  Bitcoin Core absolutely does rely=

> on the impossibility of a hash collision for maintaining consensus.=20
> This happens in multiple places in the code but in particular we don't
> check BIP30 any more since the only way it could get violated is by a
> hash collision.

So the protocol change that I suggested to Peter an hour or so ago was
actually implemented, a year ago, by you:

https://github.com/bitcoin/bitcoin/commit/06d81ad516f1d136da9f03ca2ae8232=
11c0f6988

Given that hash collisions are unquestionably possible, this is a clear
break with BIP30 (irrespective of BIP34) and constitutes a hard fork. Is
there going to be a retroactive BIP for this one at some point as well?

I'm aware that the block hash check is performed against the full chain,
as opposed to the candidate block fork height, and as a result is
insufficient to guard against a block hash collision causing a chain
split (though until now I assumed this was a bug).

Would you care to share the other consensus critical reliances on the
impossibility of hash collision that you are implying?

e


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

iQEcBAEBAgAGBQJYLaDxAAoJEDzYwH8LXOFOEScH/ii9KYDI5EyYV2U1mx0dDeGI
G9gvaLEq1MtaZCEaeb5USYwL05LO/kKcAg5t3xBvkpeDfoyIDKBuHkq3CKk5RlJp
MEMK651aFG4QczRktOmCSEo6wYaZ0Y66U27tHoAfEfbcZsWpPPx5ado7dKHUTYz3
+rUueWE1z7qjRH52k73JQ+PBrhFCMDqH9tpx1wLK7euMy1GQxnCja7JrVXv/H1D5
r72HZsXJgvZ7R2ZfpmZ5iGJuoLhQS8GP5LEKKozD7hxttslcb+zAUAjgBCPxTYQt
CV/5wVYxVUptUUXFqAYhlPKjbiiPAkkBcDP9opY+LfuWOZ7PKlsj+PSCtfSsKJ8=
=KxwF
-----END PGP SIGNATURE-----

--HQVQNhxjAKHdbObmF0J7vTivF7XK4A9BA--