From: Pieter Wuille <pieter.wuille@gmail•com>
To: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Duplicate transactions vulnerability
Date: Fri, 2 Mar 2012 02:56:34 +0100 [thread overview]
Message-ID: <CAPg+sBj_zOvNS91BeAzJ8bFWmyYxk1CUhA=Y2_J8vFt4-fruyg@mail.gmail.com> (raw)
In-Reply-To: <CAPg+sBhb+gYMwp1OJuCHYt5=BU63=YBWOFaLLthHBkN_U-scaA@mail.gmail.com>
On Tue, Feb 28, 2012 at 17:48, Pieter Wuille <pieter.wuille@gmail•com> wrote:
> 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. The change is backward compatible in the same way BIP16
> is: if a supermajority of mining power implements it, old clients can
> continue to function without risk.
After some private discussion, Ben Reeves pointed out two potential
small weaknesses in the proposed patch, which seem viable to me.
First: disconnecting the same coinbase transaction twice would fail,
as EraseTxIndex will not find anything the second time. This is
extremely hard to pull off, as it requires reverting a chain of at
least 120 blocks long. Still, the fix is very easy imho: allow
EraseTxIndex to fail.
Second: assume the following order of events: block with coinbase A is
created, 120 blocks later, A:0 is spent in transaction B. Then, a dupe
of A is created, and another 120 blocks are waited. At this point, A:0
and B:0 are still spendable. Now a block is created with two
transactions: first C which spends B:0, followed by a dupe of B. This
dupe is accepted, as its former instance is completely spent now.
However, if this last block is disconnected again, B:0 is not
spendable anymore, causing a risk for chain split. Ben suggested
moving the check for dupes up, turning the new network rule into:
Blocks are not allowed to contain transactions whose hash matches
that of an earlier transaction in the same chain, unless that
transaction was already completely spent before said block.
I've updated the patch, and will update the BIP soon.
What do you all think? Can we still move forward with deploying this?
--
Pieter
next prev parent reply other threads:[~2012-03-02 1:56 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
2012-03-01 14:30 ` Pieter Wuille
2012-03-02 1:56 ` Pieter Wuille [this message]
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_zOvNS91BeAzJ8bFWmyYxk1CUhA=Y2_J8vFt4-fruyg@mail.gmail.com' \
--to=pieter.wuille@gmail$(echo .)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