From: Eric Voskuil <eric@voskuil•org>
To: Peter Todd <pete@petertodd•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 01:58:38 -0800 [thread overview]
Message-ID: <1165cdfe-b3e0-b1d6-76b7-30e32144601d@voskuil.org> (raw)
In-Reply-To: <20161117084405.GA12334@savin.petertodd.org>
[-- Attachment #1: Type: text/plain, Size: 1497 bytes --]
On 11/17/2016 12:44 AM, Peter Todd wrote:
> 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..
Almost certainly is not certainly. Hash collisions happen because of chance.
BIP30 is quite explicit:
> "Fully-spent transactions are allowed to be duplicated in order not to
hinder pruning at some point in the future. Not allowing any transaction
to be duplicated would require evidence to be kept for each transaction
ever made."
BIP34 motivations:
> "2. Enforce block and transaction uniqueness, and assist unconnected
block validation."
But it only specifies making collisions harder, not impossible (i.e.
explicitly rejected by consensus).
Are you proposing that we draft a new BIP that allows us all to not have
to code for this? If we do so it will be impossible to guard against a
chain split due to pruning, but you seem to think that's unimportant.
e
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
next prev parent reply other threads:[~2016-11-17 9:58 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-17 0:06 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 [this message]
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=1165cdfe-b3e0-b1d6-76b7-30e32144601d@voskuil.org \
--to=eric@voskuil$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=pete@petertodd$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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