<html><head></head><body style="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="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="Apple-interchange-newline"><blockquote type="cite"><div>On Tuesday, February 28, 2012 11:48:39 AM Pieter Wuille wrote:<br><blockquote type="cite">A simple way to fix this, is adding an extra protocol rule[1]:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"> &nbsp;Do not allow blocks to contain a transaction whose hash is equal to<br></blockquote><blockquote type="cite">that of a former transaction which has not yet been completely spent.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I've written about it in BIP30[2]. There is a patch for the reference<br></blockquote><blockquote type="cite">client, which has been tested and verified to make the attack<br></blockquote><blockquote type="cite">impossible.<br></blockquote><br>Has it been verified to make even rocconor's complicated transaction-based <br>version impossible?<br><br><blockquote type="cite">The purpose of this mail is asking for support for adding this rule to<br></blockquote><blockquote type="cite">the protocol rules. If there is consensus this rule is the solution, I<br></blockquote><blockquote type="cite">hope pools and miners can agree to update their nodes without lengthy<br></blockquote><blockquote type="cite">coinbase-flagging procedure that would only delay a solution. So, who<br></blockquote><blockquote type="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="http://p.sf.net/sfu/learndevnow-d2d">http://p.sf.net/sfu/learndevnow-d2d</a><br>_______________________________________________<br>Bitcoin-development mailing list<br>Bitcoin-development@lists.sourceforge.net<br>https://lists.sourceforge.net/lists/listinfo/bitcoin-development<br></div></blockquote></div><br></div></body></html>