public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Ben Reeves <support@pi•uk.com>
To: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Duplicate transactions vulnerability
Date: Thu, 1 Mar 2012 17:20:41 +0000	[thread overview]
Message-ID: <CAPBPUnr6aDJ-Bs-Sebeij=S_nNdGj+uFcsFcCXFT8v0JTyJyKQ@mail.gmail.com> (raw)
In-Reply-To: <CAAS2fgS2NMcdpyomSE76O8EuHV8Zw7NuvSjBuk8S+BSKX5ry=A@mail.gmail.com>

>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.



  reply	other threads:[~2012-03-01 17:20 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
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 [this message]
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='CAPBPUnr6aDJ-Bs-Sebeij=S_nNdGj+uFcsFcCXFT8v0JTyJyKQ@mail.gmail.com' \
    --to=support@pi$(echo .)uk.com \
    --cc=bitcoin-development@lists$(echo .)sourceforge.net \
    /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