public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Peter Todd <pete@petertodd.org>
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 03:44:05 -0500	[thread overview]
Message-ID: <20161117084405.GA12334@savin.petertodd.org> (raw)
In-Reply-To: <e0e6679f-aec6-a579-667d-b5b58ea2360b@voskuil.org>

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

On Wed, Nov 16, 2016 at 04:43:08PM -0800, Eric Voskuil via bitcoin-dev 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.
> 
> If there is an address collision, someone may lose some money. If there
> is a tx hash collision, and implementations handle this differently, it
> will produce a chain split. As such this is not something that a node
> can just dismiss. If they do they are implementing a hard fork.

If there is a tx hash collision it is almost certainly going to be because
SHA256 has become weak through advances in cryptography, much like MD5. If that
is the case, Bitcoin is fundementally broken because the blockchain no longer
can be relied upon to commit to a unique transaction history: miners would be
able to generate blocks that have SHA256 collisions in transactions and even
the merkle tree itself, making it possible to simultaneously mine two (or more)
contradictory transaction histories at once.

Meanwhile the probability of SHA256 _not_ being broken and a collision being
found is low enough that we should be more worried about earth-killing
asteroids and mutant sharks, among other things.

Quoting Bruce Schneier:

    These numbers have nothing to do with the technology of the devices; they are
    the maximums that thermodynamics will allow. And they strongly imply that
    brute-force attacks against 256-bit keys will be infeasible until computers are
    built from something other than matter and occupy something other than space.

-https://www.schneier.com/blog/archives/2009/09/the_doghouse_cr.html

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

  parent reply	other threads:[~2016-11-17  8:44 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 [this message]
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
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=20161117084405.GA12334@savin.petertodd.org \
    --to=pete@petertodd.org \
    --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