path: root/99/9e31ea7d916b604d0db5f3a4da3a82049e2377

Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <support@pi.uk.com>) id 1S2s1Q-00029Y-Dm
	for bitcoin-development@lists.sourceforge.net;
	Wed, 29 Feb 2012 22:29:20 +0000
Received: from mail-qy0-f175.google.com ([209.85.216.175])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-MD5:128)
	(Exim 4.76) id 1S2s1O-0003e1-3A
	for bitcoin-development@lists.sourceforge.net;
	Wed, 29 Feb 2012 22:29:20 +0000
Received: by qcso7 with SMTP id o7so1968784qcs.34
	for <bitcoin-development@lists.sourceforge.net>;
	Wed, 29 Feb 2012 14:29:12 -0800 (PST)
Received-SPF: pass (google.com: domain of support@pi.uk.com designates
	10.229.76.208 as permitted sender) client-ip=10.229.76.208; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of support@pi.uk.com
	designates 10.229.76.208 as permitted sender)
	smtp.mail=support@pi.uk.com
Received: from mr.google.com ([10.229.76.208])
	by 10.229.76.208 with SMTP id d16mr622922qck.112.1330554552689
	(num_hops = 1); Wed, 29 Feb 2012 14:29:12 -0800 (PST)
MIME-Version: 1.0
Received: by 10.229.76.208 with SMTP id d16mr516938qck.112.1330553155235; Wed,
	29 Feb 2012 14:05:55 -0800 (PST)
Received: by 10.229.226.139 with HTTP; Wed, 29 Feb 2012 14:05:55 -0800 (PST)
X-Originating-IP: [81.187.238.52]
In-Reply-To: <CAPg+sBhb+gYMwp1OJuCHYt5=BU63=YBWOFaLLthHBkN_U-scaA@mail.gmail.com>
References: <CAPg+sBhb+gYMwp1OJuCHYt5=BU63=YBWOFaLLthHBkN_U-scaA@mail.gmail.com>
Date: Wed, 29 Feb 2012 22:05:55 +0000
Message-ID: <CAPBPUnqgV_hHYwFoB_1qXMvEaE1pM0vm8=V=AKe2n-rPFzz+mQ@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
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQnPrLCk5uf9djJk0uLyziy/A7TGPaFQa1fM5AveTXwTQQv6v0H2wwGvOXKprwyZpqtVxQqf
X-Spam-Score: -1.0 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.5 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1S2s1O-0003e1-3A
Subject: Re: [Bitcoin-development] Duplicate transactions vulnerability
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Wed, 29 Feb 2012 22:29:20 -0000

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> wr=
ote:
> 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]:
>
> =A0Do 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?
>
> =A0[1] https://en.bitcoin.it/wiki/Protocol_rules
> =A0[2] https://en.bitcoin.it/wiki/BIP_0030
>
> --
> Pieter
>
> -------------------------------------------------------------------------=
-----
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development