Received-SPF: pass (google.com: domain of support@pi.uk.com designates
	10.224.111.142 as permitted sender) client-ip=10.224.111.142; 
MIME-Version: 1.0
In-Reply-To: <CAAS2fgS2NMcdpyomSE76O8EuHV8Zw7NuvSjBuk8S+BSKX5ry=A@mail.gmail.com>
References: <CAPg+sBhb+gYMwp1OJuCHYt5=BU63=YBWOFaLLthHBkN_U-scaA@mail.gmail.com>
	<CAPBPUnqgV_hHYwFoB_1qXMvEaE1pM0vm8=V=AKe2n-rPFzz+mQ@mail.gmail.com>
	<CABsx9T1YbFLcuCLbZZvSJGPy9k0PRgWttOp-KPUW+99XSYTkQQ@mail.gmail.com>
	<CAPBPUnp61tCr5yVa36OGoqmO83hOJitnWJDyW3SihXyxy_FbYg@mail.gmail.com>
	<20120229232029.GA6073@vps7135.xlshosting.net>
	<20120229234558.GA6573@vps7135.xlshosting.net>
	<CAPBPUno7EaUeQHEb6jfR77k==p5_Q5Es8dGQiwmQW+DPSttDuA@mail.gmail.com>
	<CAPBPUnpj=u53Nvvvu54e2X462gPshLQ5rUcPosxvoNAXp6uN8w@mail.gmail.com>
	<CAAS2fgS2NMcdpyomSE76O8EuHV8Zw7NuvSjBuk8S+BSKX5ry=A@mail.gmail.com>
Date: Thu, 1 Mar 2012 17:20:41 +0000
Message-ID: <CAPBPUnr6aDJ-Bs-Sebeij=S_nNdGj+uFcsFcCXFT8v0JTyJyKQ@mail.gmail.com>
From: Ben Reeves <support@pi.uk.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [Bitcoin-development] Duplicate transactions vulnerability
Precedence: list

>I am not following you here, can you explain what you're thinking?

If I mine a duplicate coinbase of an old block (whether spent or not)
if that block is then invalidated DisconnectBlock() will erase both
the coinbase of the new block and of the old block. This leaves the
blockchain is in an inconsistent state because with the coinbase
missing the old block will no longer pass CheckBlock().

When affected clients are restarted LoadBlockIndex() will try and
verify all blocks in the main chain, failing at the block with the
missing coinbase.

1) If an attacker was to do this with an early block it would force
all affected clients to redownload the majority of the blockchain.
2) If the attacker was able to do this on a block after the March 1st
deadline (future block A). If they mined a fake copy of block A (block
B) with the same coinbase but a different hash clients who received
block B before block A will refuse to accept block A because of the
unspent duplicate coinbase in block B. The attacker can then fork the
chain at this point despite the real chain being longer.

I am just think out load here so I could be wrong, but maybe it would
be better to go for the full block height fix now?

On Thu, Mar 1, 2012 at 2:27 PM, Gregory Maxwell <gmaxwell@gmail.com> wrote:
> On Thu, Mar 1, 2012 at 8:09 AM, Ben Reeves <support@pi.uk.com> wrote:
>> One more thing to add. The implementation in the reference patch fixes
>> the blockchain forking issue however by still allowing spent coinbases
>> to be disconnected patched clients are still vulnerable to blockchain
>> corruption. While not an immediate issue it would mean
>> LoadBlockIndex() would error on restart and could cause problems for
>> new clients during the initial blockchain download.
>
> I am not following you here, can you explain what you're thinking?
>
>> Is there a reason not to disallow duplicate coinbases entirely?
>
> Because this would make it impossible for nodes to prune the vaules.
> They'd all forever have to keep a set of all the coinbase hashes in
> order to perform the test. The height-in-coinbase BIP will make
> duplicates effectively impossible to create, which is a much more
> clean behavior.