From: Pieter Wuille <pieter.wuille@gmail•com>
To: "Brautigam Róbert" <robert.brautigam@netmind•hu>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Duplicate transactions vulnerability
Date: Tue, 28 Feb 2012 18:18:12 +0100 [thread overview]
Message-ID: <CAPg+sBj==4kaeoQJ8YDHSCSr9H4Frbu6zDz8qDAwwLAF4mefJg@mail.gmail.com> (raw)
In-Reply-To: <4F4D0AEC.8060400@netmind.hu>
On Tue, Feb 28, 2012 at 18:12, Brautigam Róbert
<robert.brautigam@netmind•hu> wrote:
>> A simple way to fix this, is adding an extra protocol rule[1]:
>>
>> Do not allow blocks to contain a transaction whose hash is equal to
>> that of a former transaction which has not yet been completely spent.
>
> I don't know whether I understand this correctly, but there should be no
> duplicate transaction hashes at all. So the rule should be: Do not allow
> blocks to contain transaction hashes which are already present in that
> branch.
As explained in the BIP, that would prevent pruning, as it would
require each full node to keep a database with all transaction hashes
ever.
> If by a freak accident a transaction has the same hash as another
> transaction in the chain, shouldn't the transaction be "tweaked" in some
> way to avoid collision (generate a new target address for it or
> something)? In any case this seams very-very unlikely to happen, or am I
> missing something?
It won't happen by accident. Duplicate coinbase transactions are
possible however (by badly written software, or malicious intent).
Transactions that spend duplcate coinbases can be made to have the
same hash as well.
--
Pieter
next prev parent reply other threads:[~2012-02-28 17:18 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-28 16:48 Pieter Wuille
2012-02-28 17:12 ` Brautigam Róbert
2012-02-28 17:18 ` Pieter Wuille [this message]
2012-02-28 18:10 ` Gavin Andresen
2012-02-28 18:23 ` Luke-Jr
2012-02-28 20:24 ` Pieter Wuille
2012-02-28 20:35 ` Ben Reeves
2012-02-29 1:41 ` Zooko Wilcox-O'Hearn
2012-02-29 16:47 ` Pieter Wuille
2012-02-29 17:02 ` Amir Taaki
2012-02-29 21:00 ` Stefan Thomas
2012-02-29 22:05 ` Ben Reeves
2012-02-29 22:38 ` Matt Corallo
2012-02-29 22:46 ` Gavin Andresen
2012-02-29 23:00 ` Ben Reeves
[not found] ` <20120229232029.GA6073@vps7135.xlshosting.net>
2012-02-29 23:45 ` Pieter Wuille
2012-03-01 10:15 ` Ben Reeves
2012-03-01 13:09 ` Ben Reeves
2012-03-01 14:27 ` Gregory Maxwell
2012-03-01 17:20 ` Ben Reeves
2012-03-01 14:30 ` Pieter Wuille
2012-03-02 1:56 ` Pieter Wuille
2012-03-03 16:41 ` Pieter Wuille
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='CAPg+sBj==4kaeoQJ8YDHSCSr9H4Frbu6zDz8qDAwwLAF4mefJg@mail.gmail.com' \
--to=pieter.wuille@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=robert.brautigam@netmind$(echo .)hu \
/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