public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Alex Morcos <morcos@gmail.com>
To: Eric Voskuil <eric@voskuil.org>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP30 and BIP34 interaction (was Re: [BIP Proposal] Buried Deployments)
Date: Thu, 17 Nov 2016 06:38:12 -0500	[thread overview]
Message-ID: <CAPWm=eW9X77+qQZGHkAOjN-k7KFwq06gKS6HOVOTE1+SmYBhWA@mail.gmail.com> (raw)
In-Reply-To: <5ef23296-5909-a350-ab11-e717f8fffc41@voskuil.org>

[-- Attachment #1: Type: text/plain, Size: 3356 bytes --]

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 <eric@voskuil.org
> > <mailto:eric@voskuil.org>> 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
>
>

[-- Attachment #2: Type: text/html, Size: 4766 bytes --]

  reply	other threads:[~2016-11-17 11:38 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-17  0:06 [bitcoin-dev] BIP30 and BIP34 interaction (was Re: [BIP Proposal] Buried Deployments) Jorge Timón
2016-11-17  0:10 ` Eric Voskuil
2016-11-17  0:31   ` Tier Nolan
2016-11-17  0:43     ` Eric Voskuil
2016-11-17  0:53       ` Eric Voskuil
2016-11-17  8:44       ` Peter Todd
2016-11-17  9:58         ` Eric Voskuil
2016-11-17 10:22       ` Tier Nolan
2016-11-17 11:22         ` Eric Voskuil
2016-11-17 11:38           ` Alex Morcos [this message]
2016-11-17 12:22             ` Eric Voskuil
2016-11-17 15:40               ` Johnson Lau
2016-11-17 17:01                 ` Eric Voskuil
2016-11-17 17:22                   ` Johnson Lau
2016-11-17 17:49                     ` Eric Voskuil
2016-11-17 18:08                       ` Johnson Lau
2016-11-18  3:20                         ` Eric Voskuil
2016-11-18 14:43                           ` Johnson Lau
2016-11-18 16:47                             ` Eric Voskuil

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAPWm=eW9X77+qQZGHkAOjN-k7KFwq06gKS6HOVOTE1+SmYBhWA@mail.gmail.com' \
    --to=morcos@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=eric@voskuil.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox