From: Matt Corallo <bitcoin-list@bluematt•me>
To: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Duplicate transactions vulnerability
Date: Wed, 29 Feb 2012 17:38:13 -0500 [thread overview]
Message-ID: <1330555093.3202.2.camel@BMThinkPad.lan.bluematt.me> (raw)
In-Reply-To: <CAPBPUnqgV_hHYwFoB_1qXMvEaE1pM0vm8=V=AKe2n-rPFzz+mQ@mail.gmail.com>
In other words when we roll out the update, we have to make sure we have
>>50% not just 50%. Something like 60%-75% should do fine (IMHO). In
other words we just have to be very, very vocal about the change when it
happens and make sure miners are all on board.
Matt
On Wed, 2012-02-29 at 22:05 +0000, Ben Reeves wrote:
> Assuming 50% of hashing power adopts BIP30 but the actual client
> install base is relatively low the patch will likely result in a
> "hard" blockchain split if someone takes advantage.
>
> A malicious miner can produce a duplicate coinbase which the majority
> of clients will accept but the majority of hashing power won't.
> Spending the coinbase output after disconnection will cause the
> blockchain to fork. All none BIP30 clients on the short blockchain
> will be vulnerable to transaction reversal of 6 confirmations or more.
>
> It is a relatively inexpensive attack to perform (costing the attacker
> only one valid block ~$240) and could be quite disruptive. I think
> this should be patched in DisconnectBlock() (if it hasn't already?)
> before any protocol change - maybe a new mapByCoinbase multimap is
> needed.
>
> Thank You,
> Ben Reeves
> www.blockchain.info
>
> On Tue, Feb 28, 2012 at 4:48 PM, Pieter Wuille <pieter.wuille@gmail•com> wrote:
> > Hello all,
> >
> > 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'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.
> >
> > 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?
> >
> > [1] https://en.bitcoin.it/wiki/Protocol_rules
> > [2] https://en.bitcoin.it/wiki/BIP_0030
> >
> > --
> > Pieter
next prev parent reply other threads:[~2012-02-29 22:38 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 [this message]
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
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=1330555093.3202.2.camel@BMThinkPad.lan.bluematt.me \
--to=bitcoin-list@bluematt$(echo .)me \
--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