Message-ID: <4F4D0AEC.8060400@netmind.hu>
Date: Tue, 28 Feb 2012 18:12:12 +0100
From: =?ISO-8859-1?Q?Brautigam_R=F3bert?= <robert.brautigam@netmind.hu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <CAPg+sBhb+gYMwp1OJuCHYt5=BU63=YBWOFaLLthHBkN_U-scaA@mail.gmail.com>
In-Reply-To: <CAPg+sBhb+gYMwp1OJuCHYt5=BU63=YBWOFaLLthHBkN_U-scaA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Bitcoin-development] Duplicate transactions vulnerability
Precedence: list

On 02/28/2012 05:48 PM, Pieter Wuille wrote:
> Hello all,

Hi,

> as some of you may know, a vulnerability has been found in how the
> Bitcoin reference client deals with duplicate transactions. Exploiting
> it is rather complex, requires some hash power, and has no financial
> benefit for the attacker. Still, it's a security hole, and we'd like
> to fix this as soon as possible.
>
> 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.

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?

Robert.