Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 7F638B37 for ; Thu, 17 Nov 2016 15:44:59 +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 EB3D923D for ; Thu, 17 Nov 2016 15:44:58 +0000 (UTC) Received: from [10.8.8.2] (119246245241.ctinets.com [119.246.245.241]) by mx.zohomail.com with SMTPS id 1479397492755223.42326607453913; Thu, 17 Nov 2016 07:44:52 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Johnson Lau In-Reply-To: <34949746-c0c9-7f14-0e92-69d5a7d44b04@voskuil.org> Date: Thu, 17 Nov 2016 23:40:05 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5ef23296-5909-a350-ab11-e717f8fffc41@voskuil.org> <34949746-c0c9-7f14-0e92-69d5a7d44b04@voskuil.org> To: Eric Voskuil , bitcoin-dev 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 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 15:44:59 -0000 > On 17 Nov 2016, at 20:22, Eric Voskuil via bitcoin-dev = wrote: >=20 >=20 > Given that hash collisions are unquestionably possible,=20 Everything you said after this point is irrelevant. Having hash collision is **by definition** a consensus failure, or a = hardfork. You could replace the already-on-chain tx with the collision = and create 2 different versions of UTXOs (if the colliding tx is valid), = or make some nodes to accept a fork with less PoW (if the colliding tx = is invalid, or making the block invalid, such as being to big). To put = it simply, the Bitcoin protocol is broken. So with no doubt, Bitcoin = Core and any implementation of the Bitcoin protocol should assume SHA256 = collision is unquestionably **impossible**. If some refuse to make such = assumption, they should have introduced an alternative hash algorithm = and somehow run it in parallel with SHA256 to prevent the consensus = failure. jl2012=