Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 94F5CA87 for ; Thu, 17 Nov 2016 11:38:15 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-it0-f44.google.com (mail-it0-f44.google.com [209.85.214.44]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DAA8E306 for ; Thu, 17 Nov 2016 11:38:13 +0000 (UTC) Received: by mail-it0-f44.google.com with SMTP id c20so272266461itb.0 for ; Thu, 17 Nov 2016 03:38:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=lFOZqi0cGDgzLOy+6zbm2wQJxQ8CCdIFoXt9gkwsjYA=; b=YW5C5RGFE94J5T85cJ3PAbredmGwzMPKMHVgVlZTDmR/kK6eEO3lhXXacBxmtBJVxc P941iNynp0NQpH/kjvpB8pP+q2hwWlt8VMnHZyf18deSJDLp3CMHpRFbNYgQnUGRQFaG 8N7tzUkL5GeW4smU1jkQez26lVjtPRYgLg+4n12iapkv3CgHjgNvm371bqkxSLoslix7 rKO5j6IOkS1Hx6BGL2zE35JX0CpcgTqALjo47Bm/cqkgNWgiolOaM6vAjgn71P/4TQqJ IVTOcXc4HSz8sI52LqgvCsanTf2dipO78no0luNqY3uG5Ub632idorkfIFU8eQf8qjKZ Qxow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=lFOZqi0cGDgzLOy+6zbm2wQJxQ8CCdIFoXt9gkwsjYA=; b=lY2sYVRf+vGElqX5DTGobL0Tl47OmVA/PnfJEcnyIQzLPwdHYASLp0giQpQlU3Doq0 bBTeO7dsrpQ3cZGqQ8oAF7xWctdTf+8qYRR+6wUDvAjDE2PLV7iXc+q/3SPkp4u8sjHB 4aV2tF3aLkBvgr8uYU/MdgYS8noc4QIvkx5MKWgM5CGXrXjCCBU60W5QCH/HV3/HceDc px3AWjo7NFZDWOXGXpGnWQXZz5fFJoqCQHC8ZxAkY1n1tvoTosdWdq0Dc/vNvZlaVUAb knoL3ZSXL0EhyH8iqrWbL4ITEDSuaiduKIKTwkVgvWfOJgQEujFrIQCNKZtk977t9Y20 6kUg== X-Gm-Message-State: ABUngvdwQJBAmnv7Aae0rA6bYu8ZhxmBYlVml/jh+GC4VW4n3HKgorEIz6sVE3ASHEFIyxfzbQCU8hzBgBe1sg== X-Received: by 10.36.123.82 with SMTP id q79mr12120507itc.25.1479382693070; Thu, 17 Nov 2016 03:38:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.119.199 with HTTP; Thu, 17 Nov 2016 03:38:12 -0800 (PST) In-Reply-To: <5ef23296-5909-a350-ab11-e717f8fffc41@voskuil.org> References: <5ef23296-5909-a350-ab11-e717f8fffc41@voskuil.org> From: Alex Morcos Date: Thu, 17 Nov 2016 06:38:12 -0500 Message-ID: To: Eric Voskuil , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=001a11474ba4e84b8905417d9f61 X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_LOW, RCVD_IN_SORBS_SPAM 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 11:38:15 -0000 --001a11474ba4e84b8905417d9f61 Content-Type: text/plain; charset=UTF-8 I think this conversation has gone off the rails and is no longer really appropriate for the list. 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. On Thu, Nov 17, 2016 at 6:22 AM, Eric Voskuil via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On 11/17/2016 02:22 AM, Tier Nolan via bitcoin-dev wrote: > > On Thu, Nov 17, 2016 at 12:43 AM, Eric Voskuil > > wrote: > > > > > This means that all future transactions will have different > txids... > > rules do guarantee it. > > > > No, it means that the chance is small, there is a difference. > > > > I think we are mostly in agreement then? It is just terminology. > > Sure, if you accept that mostly is not fully - just as unlikely is not > impossible. > > > In terms of discussing the BIP, barring a hash collision, it does make > > duplicate txids impossible. > > That's like saying, as long as we exclude car accidents from > consideration, car accidents are impossible. > > > Given that a hash collision is so unlikely, the qualifier should be > > added to those making claims that require hash collisions rather than > > those who assume that they aren't possible. > > > > You could have said "However nothing precludes different txs from having > > the same hash, but it requires a hash collision". > > I generally try to avoid speaking in tautologies :) > > > Thinking about it, a re-org to before the enforcement height could allow > > it. The checkpoints protect against that though. > > > > As such this is not something that a node > > can just dismiss. > > > > The security of many parts of the system is based on hash collisions not > > being possible. > > This is not the case. > > Block hash duplicates within the same chain are invalid as a matter of > consensus, which is the opposite of assuming impossibility. > > Tx hash collisions are explicitly allowed in the case that preceding tx > with the same hash is unspent. This is also not a reliance on the > impossibility of hash collision. Core certainly implements this > distinction: > > https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L2419-L2426 > > Address hashes and script hashes can collide without harming the > security of Bitcoin (although address owner(s) may experience harm). > Rare in this case is sufficient because of this distinction. > > Compact blocks contemplates hash collisions: > > https://github.com/bitcoin/bips/blob/master/bip-0152. > mediawiki#Random_collision_probabilty > > Checkpoints aren't part of Bitcoin security, so even the remote > possibility of two different potential blocks, with the same hash, at > the same height in the same chain, does not indicate a problem. > > There is no case where the security of Bitcoin assumes that hashes never > collide. Consensus rules have specific handling for both block hash > collisions and tx hash collisions. > > e > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --001a11474ba4e84b8905417d9f61 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think this conversation has gone off the rails and is no= longer really appropriate for the list.

But just to be = clear to any readers.=C2=A0 Bitcoin Core absolutely does rely on the imposs= ibility of a hash collision for maintaining consensus.=C2=A0 This happens i= n multiple places in the code but in particular we don't check BIP30 an= y more since the only way it could get violated is by a hash collision.=C2= =A0




=

On Thu, Nov 17, 2= 016 at 6:22 AM, Eric Voskuil via bitcoin-dev <bitcoin= -dev@lists.linuxfoundation.org> wrote:
On 11/17/2016 02:22 AM, Tier Nolan via bitco= in-dev wrote:
> On Thu, Nov 17, 2016 at 12:43 AM, Eric Voskuil <eric@voskuil.org
> <mailto:eric@voskuil.org>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0> This means that all future transactions will h= ave different txids...
>=C2=A0 =C2=A0 =C2=A0rules do guarantee it.
>
>=C2=A0 =C2=A0 =C2=A0No, it means that the chance is small, there is a d= ifference.
>
> I think we are mostly in agreement then?=C2=A0 It is just terminology.=

Sure, if you accept that mostly is not fully - just as unlikely is n= ot
impossible.

> In terms of discussing the BIP, barring a hash collision, it does make=
> duplicate txids impossible.

That's like saying, as long as we exclude car accidents from
consideration, car accidents are impossible.

> Given that a hash collision is so unlikely, the qualifier should be > added to those making claims that require hash collisions rather than<= br> > those who assume that they aren't possible.
>
> You could have said "However nothing precludes different txs from= having
> the same hash, but it requires a hash collision".

I generally try to avoid speaking in tautologies :)

> Thinking about it, a re-org to before the enforcement height could all= ow
> it.=C2=A0 The checkpoints protect against that though.
>
>=C2=A0 =C2=A0 =C2=A0As such this is not something that a node
>=C2=A0 =C2=A0 =C2=A0can just dismiss.
>
> The security of many parts of the system is based on hash collisions n= ot
> being possible.

This is not the case.

Block hash duplicates within the same chain are invalid as a matter of
consensus, which is the opposite of assuming impossibility.

Tx hash collisions are explicitly allowed in the case that preceding tx
with the same hash is unspent. This is also not a reliance on the
impossibility of hash collision. Core certainly implements this distinction= :

https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L2419-L2426

Address hashes and script hashes can collide without harming the
security of Bitcoin (although address owner(s) may experience harm).
Rare in this case is sufficient because of this distinction.

Compact blocks contemplates hash collisions:

https://gi= thub.com/bitcoin/bips/blob/master/bip-0152.mediawiki#Random_colli= sion_probabilty

Checkpoints aren't part of Bitcoin security, so even the remote
possibility of two different potential blocks, with the same hash, at
the same height in the same chain, does not indicate a problem.

There is no case where the security of Bitcoin assumes that hashes never collide. Consensus rules have specific handling for both block hash
collisions and tx hash collisions.

e


_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev


--001a11474ba4e84b8905417d9f61--