public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Tier Nolan <tier.nolan@gmail.com>
To: 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 00:31:02 +0000	[thread overview]
Message-ID: <CAE-z3OX5vak25UWcmBSe63OmoOVoGB394WmwyWwUcSxWeDOLhw@mail.gmail.com> (raw)
In-Reply-To: <d58ee114-00fd-23c8-9ca7-9a4b28c26f27@voskuil.org>

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

On Thu, Nov 17, 2016 at 12:10 AM, Eric Voskuil via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Both of these cases resulted from exact duplicate txs, which BIP34 now
> precludes. However nothing precludes different txs from having the same
> hash.
>

The only way to have two transactions have the same txid is if their
parents are identical, since the txids of the parents are included in a
transaction.

Coinbases have no parents, so it used to be possible for two of them to be
identical.

Duplicate outputs weren't possible in the database, so the later coinbase
transaction effectively overwrote the earlier one.

The happened for two coinbases.  That is what the exceptions are for.

Neither of the those coinbases were spent before the overwrite happened.  I
don't even think those coinbases were spent at all.

This means that every activate coinbase transaction has a unique hash and
all new coinbases will be unique.

This means that all future transactions will have different txids.

There might not be an explicit rule that says that txids have to be unique,
but barring a break of the hash function, they rules do guarantee it.

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

  reply	other threads:[~2016-11-17  0:31 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 [this message]
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
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=CAE-z3OX5vak25UWcmBSe63OmoOVoGB394WmwyWwUcSxWeDOLhw@mail.gmail.com \
    --to=tier.nolan@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.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