Return-Path: <jl2012@xbt.hk> Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 7F638B37 for <bitcoin-dev@lists.linuxfoundation.org>; 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 <bitcoin-dev@lists.linuxfoundation.org>; 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 <jl2012@xbt.hk> 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: <FA128F93-7E79-47FE-8270-225D07DD6FEF@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> To: Eric Voskuil <eric@voskuil.org>, bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> 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 <bitcoin-dev.lists.linuxfoundation.org> List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 = <bitcoin-dev@lists.linuxfoundation.org> 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=