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 ) 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 ; 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 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: <201202281323.02976.luke@dashjr.org> To: Luke-Jr 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
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]:

 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.

Has it been verified to = make even rocconor's complicated transaction-based
version = impossible?

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?

Can we do this in two steps? First, prefer = blocks which don't break the rule;
once 55%+ are confirmed to have = upgraded, then it is safe to treat it as a
hard = rule.

-------------------------------------------------------------= -----------------
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/learndevn= ow-d2d
_______________________________________________
Bitcoin-d= evelopment mailing = list
Bitcoin-development@lists.sourceforge.net
https://lists.sourcef= orge.net/lists/listinfo/bitcoin-development
= --Apple-Mail=_0EC2EE24-0A89-472C-A522-FA814BFFD407--