Re: [bitcoin-dev] BIP30 and BIP34 interaction (was Re: [BIP Proposal] Buried Deployments)

[Eric Voskuil <eric@voskuil.org>]

[-- Attachment #1: Type: text/plain, Size: 1401 bytes --]

On 11/17/2016 03:38 AM, Alex Morcos wrote:
> I think this conversation has gone off the rails and is no longer really
> 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. 
> 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/06d81ad516f1d136da9f03ca2ae823211c0f6988

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]