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/learndevnow-d2d_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development