From: "Luke-Jr" <luke@dashjr.org>
To: bitcoin-development@lists.sourceforge.net
Date: Tue, 28 Feb 2012 13:23:01 -0500
User-Agent: KMail/1.13.7 (Linux/3.2.2-gentoo; KDE/4.7.4; x86_64; ; )
References: <CAPg+sBhb+gYMwp1OJuCHYt5=BU63=YBWOFaLLthHBkN_U-scaA@mail.gmail.com>
In-Reply-To: <CAPg+sBhb+gYMwp1OJuCHYt5=BU63=YBWOFaLLthHBkN_U-scaA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201202281323.02976.luke@dashjr.org>
Subject: Re: [Bitcoin-development] Duplicate transactions vulnerability
Precedence: list

On Tuesday, February 28, 2012 11:48:39 AM Pieter Wuille 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've written about it in BIP30[2]. There is a patch for the reference
> client, which has been tested and verified to make the attack
> impossible.

Has it been verified to make even rocconor's complicated transaction-based 
version impossible?

> The purpose of this mail is asking for support for adding this rule to
> the protocol rules. If there is consensus this rule is the solution, I
> hope pools and miners can agree to update their nodes without lengthy
> coinbase-flagging procedure that would only delay a solution. So, who
> is in favor?

Can we do this in two steps? First, prefer blocks which don't break the rule; 
once 55%+ are confirmed to have upgraded, then it is safe to treat it as a 
hard rule.