Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Johnson Lau <jl2012@xbt.hk>
In-Reply-To: <59D27CC6-120C-4673-9F20-6B5E95EA60C6@voskuil.org>
Date: Fri, 18 Nov 2016 02:08:09 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <6F2B3EA2-4245-4A0E-8E19-12D02A871815@xbt.hk>
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>
	<34949746-c0c9-7f14-0e92-69d5a7d44b04@voskuil.org>
	<FA128F93-7E79-47FE-8270-225D07DD6FEF@xbt.hk>
	<8d92ae05-ac6a-30b7-5ef3-f7aa1298e46d@voskuil.org>
	<632B36D5-74AF-41E2-8E21-359F02645066@xbt.hk>
	<59D27CC6-120C-4673-9F20-6B5E95EA60C6@voskuil.org>
To: Eric Voskuil <eric@voskuil.org>
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP30 and BIP34 interaction (was Re: [BIP
	Proposal] Buried Deployments)
Precedence: list

The fact that some implementations ban an invalid block hash and some do =
not, suggests that it=E2=80=99s not a pure p2p protocol issue. A pure =
p2p split should be unified by a bridge node. However, a bridge node is =
not helpful in this case. Banning an invalid block hash is an implicit =
=E2=80=9Cfirst seen=E2=80=9D consensus rule.

jl2012

> On 18 Nov 2016, at 01:49, Eric Voskuil <eric@voskuil.org> wrote:
>=20
> Actually both possibilities were specifically covered in my =
description. Sorry if it wasn't clear.
>=20
> If you create a new valid block out of an old one it's has potential =
to cause a reorg. The blocks that previously built on the original are =
still able to do so but presumably cannot build forever on the *new* =
block as it has a different tx. But other new blocks can. There is no =
chain split due to a different interpretation of valid, there are simply =
two valid competing chains.
>=20
> Note that this scenario requires not only block and tx validity with a =
tx hash collision, but also that the tx be valid within the block. =
Pretty far to reach to not even get a chain split, but it could produce =
a deep reorg with a very low chance of success. As I keep telling =
people, deep reorgs can happen, they are just unlikely, as is this =
scenario.
>=20
> If you create a new invalid block it is discarded by everyone. That =
does not invalidate the hash of that block. Permanent blocking as you =
describe it would be a p2p protocol design choice, having nothing to do =
with consensus. Libbitcoin for example does not ban invalidated hashes =
at all. It just discards the block and drops the peer.
>=20
> e