From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 7BC9B71F for ; Thu, 17 Nov 2016 18:08:20 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sender163-mail.zoho.com (sender163-mail.zoho.com [74.201.84.163]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E540B296 for ; Thu, 17 Nov 2016 18:08:19 +0000 (UTC) Received: from [10.8.8.2] (119246245241.ctinets.com [119.246.245.241]) by mx.zohomail.com with SMTPS id 1479406092316156.7201289152149; Thu, 17 Nov 2016 10:08:12 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Johnson Lau 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: <5ef23296-5909-a350-ab11-e717f8fffc41@voskuil.org> <34949746-c0c9-7f14-0e92-69d5a7d44b04@voskuil.org> <8d92ae05-ac6a-30b7-5ef3-f7aa1298e46d@voskuil.org> <632B36D5-74AF-41E2-8E21-359F02645066@xbt.hk> <59D27CC6-120C-4673-9F20-6B5E95EA60C6@voskuil.org> To: Eric Voskuil X-Mailer: Apple Mail (2.3124) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,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 Cc: bitcoin-dev 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 18:08:20 -0000 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 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