From: Tier Nolan <tier.nolan@gmail.com>
Cc: 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 10:22:28 +0000 [thread overview]
Message-ID: <CAE-z3OXfJa3Lewtrafm25bdfPa=eiarOAXBNbgc3ccTi7Qoe6A@mail.gmail.com> (raw)
In-Reply-To: <e0e6679f-aec6-a579-667d-b5b58ea2360b@voskuil.org>
[-- Attachment #1: Type: text/plain, Size: 995 bytes --]
On Thu, Nov 17, 2016 at 12:43 AM, Eric Voskuil <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.
In terms of discussing the BIP, barring a hash collision, it does make
duplicate txids 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".
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.
[-- Attachment #2: Type: text/html, Size: 1638 bytes --]
next prev parent reply other threads:[~2016-11-17 10:22 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 [this message]
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-z3OXfJa3Lewtrafm25bdfPa=eiarOAXBNbgc3ccTi7Qoe6A@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