path: root/c2/a94b28927b80a9b7d926fa7ff20d49e7676e18

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 1S2UEx-0004fp-6X
	for bitcoin-development@lists.sourceforge.net;
	Tue, 28 Feb 2012 21:05:43 +0000
Received: from mail-we0-f175.google.com ([74.125.82.175])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1S2UEw-0007Ub-4v
	for bitcoin-development@lists.sourceforge.net;
	Tue, 28 Feb 2012 21:05:43 +0000
Received: by wera1 with SMTP id a1so2296872wer.34
	for <bitcoin-development@lists.sourceforge.net>;
	Tue, 28 Feb 2012 13:05:36 -0800 (PST)
Received-SPF: pass (google.com: domain of support@pi.uk.com designates
	10.180.86.9 as permitted sender) client-ip=10.180.86.9; 
Authentication-Results: mr.google.com;
	spf=pass (google.com: domain of support@pi.uk.com
	designates 10.180.86.9 as permitted sender)
	smtp.mail=support@pi.uk.com
Received: from mr.google.com ([10.180.86.9])
	by 10.180.86.9 with SMTP id l9mr42686381wiz.15.1330463136053 (num_hops
	= 1); Tue, 28 Feb 2012 13:05:36 -0800 (PST)
Received: by 10.180.86.9 with SMTP id l9mr33774699wiz.15.1330461307920;
	Tue, 28 Feb 2012 12:35:07 -0800 (PST)
Received: from [192.168.2.207] (52.238.187.81.in-addr.arpa. [81.187.238.52])
	by mx.google.com with ESMTPS id 9sm52708251wid.2.2012.02.28.12.35.06
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 28 Feb 2012 12:35:07 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_0EC2EE24-0A89-472C-A522-FA814BFFD407"
From: Ben Reeves <support@pi.uk.com>
In-Reply-To: <201202281323.02976.luke@dashjr.org>
Date: Tue, 28 Feb 2012 20:35:05 +0000
Message-Id: <736F8531-28F8-4219-9DE9-3F201FC7DCF4@pi.uk.com>
References: <CAPg+sBhb+gYMwp1OJuCHYt5=BU63=YBWOFaLLthHBkN_U-scaA@mail.gmail.com>
	<201202281323.02976.luke@dashjr.org>
To: Luke-Jr <luke@dashjr.org>
X-Mailer: Apple Mail (2.1257)
X-Gm-Message-State: ALoCoQnmoW+wsYAdWurtnKsbUL6H0GTZWJpiZt4+xVR+6yQgRwKOQmsaKNCoExJvWkMcXzMNEsrs
X-Spam-Score: -0.5 (/)
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
	1.0 HTML_MESSAGE           BODY: HTML included in message
X-Headers-End: 1S2UEw-0007Ub-4v
Cc: bitcoin-development@lists.sourceforge.net
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: Tue, 28 Feb 2012 21:05:43 -0000


--Apple-Mail=_0EC2EE24-0A89-472C-A522-FA814BFFD407
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


I might be wrong but I think perhaps it would help to get this fix out =
before the p2sh protocol change. Otherwise a miner could combine a =
duplicate coinbase and an invalid P2SH transaction to create a block =
which can have excellent network propagation and still be guaranteed to =
be orphaned. This makes the attack significantly easier to perform.

If someone were to do this on the day of the P2SH switchover they could =
corrupt the database of all clients < 0.6 with only a single block. If =
it was done on an early block and was widespread enough it would make it =
difficult for new clients to find a genuine non-corrupted copy of the =
blockchain to download.

Thank You,
Ben Reeves
www.blockchain.info


On 28 Feb 2012, at 18:23, Luke-Jr wrote:

> On Tuesday, February 28, 2012 11:48:39 AM Pieter Wuille wrote:
>> A simple way to fix this, is adding an extra protocol rule[1]:
>>=20
>>  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.
>>=20
>> 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.
>=20
> Has it been verified to make even rocconor's complicated =
transaction-based=20
> version impossible?
>=20
>> 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?
>=20
> Can we do this in two steps? First, prefer blocks which don't break =
the rule;=20
> once 55%+ are confirmed to have upgraded, then it is safe to treat it =
as a=20
> hard rule.
>=20
> =
--------------------------------------------------------------------------=
----
> 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


--Apple-Mail=_0EC2EE24-0A89-472C-A522-FA814BFFD407
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br>I =
might be wrong but I think perhaps it would help to get this fix out =
before the p2sh protocol change. Otherwise a miner could combine a =
duplicate coinbase and an invalid P2SH transaction to create a block =
which can have excellent network propagation and still be guaranteed to =
be orphaned. This makes the attack significantly easier to =
perform.<br><br>If someone were to do this on the day of the P2SH =
switchover they could corrupt the database of all clients &lt; 0.6 with =
only a single block. If it was done on an early block and was widespread =
enough it would make it difficult for new clients to find a genuine =
non-corrupted copy of the blockchain to download.<br><br>Thank =
You,<br>Ben Reeves<br><a =
href=3D"http://www.blockchain.info/">www.blockchain.info</a><div><br></div=
><div><br><div><div>On 28 Feb 2012, at 18:23, Luke-Jr wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div>On =
Tuesday, February 28, 2012 11:48:39 AM Pieter Wuille =
wrote:<br><blockquote type=3D"cite">A simple way to fix this, is adding =
an extra protocol rule[1]:<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite"> &nbsp;Do not =
allow blocks to contain a transaction whose hash is equal =
to<br></blockquote><blockquote type=3D"cite">that of a former =
transaction which has not yet been completely =
spent.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">I've written =
about it in BIP30[2]. There is a patch for the =
reference<br></blockquote><blockquote type=3D"cite">client, which has =
been tested and verified to make the attack<br></blockquote><blockquote =
type=3D"cite">impossible.<br></blockquote><br>Has it been verified to =
make even rocconor's complicated transaction-based <br>version =
impossible?<br><br><blockquote type=3D"cite">The purpose of this mail is =
asking for support for adding this rule to<br></blockquote><blockquote =
type=3D"cite">the protocol rules. If there is consensus this rule is the =
solution, I<br></blockquote><blockquote type=3D"cite">hope pools and =
miners can agree to update their nodes without =
lengthy<br></blockquote><blockquote type=3D"cite">coinbase-flagging =
procedure that would only delay a solution. So, =
who<br></blockquote><blockquote type=3D"cite">is in =
favor?<br></blockquote><br>Can we do this in two steps? First, prefer =
blocks which don't break the rule; <br>once 55%+ are confirmed to have =
upgraded, then it is safe to treat it as a <br>hard =
rule.<br><br>-------------------------------------------------------------=
-----------------<br>Keep Your Developer Skills Current with =
LearnDevNow!<br>The most comprehensive online learning library for =
Microsoft developers<br>is just $99.99! Visual Studio, SharePoint, SQL - =
plus HTML5, CSS3, MVC3,<br>Metro Style Apps, more. Free future releases =
when you subscribe now!<br><a =
href=3D"http://p.sf.net/sfu/learndevnow-d2d">http://p.sf.net/sfu/learndevn=
ow-d2d</a><br>_______________________________________________<br>Bitcoin-d=
evelopment mailing =
list<br>Bitcoin-development@lists.sourceforge.net<br>https://lists.sourcef=
orge.net/lists/listinfo/bitcoin-development<br></div></blockquote></div><b=
r></div></body></html>=

--Apple-Mail=_0EC2EE24-0A89-472C-A522-FA814BFFD407--