📅 Original date posted:2012-02-28
📝 Original message: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/learndevnow-d2d
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120228/6ef43bce/attachment.html>;
Ben Reeves [ARCHIVE] /
npub1t2…pvrwu
2023-06-07 03:09:45
in reply to nevent1q…uwp3
Author Public Key
npub1t26xr0r383eh8xkmc4pluqs42wkqyml33eszv7sfn829llwr49psfpvrwuSeen on
wss://relay.nostr.bandPublished at
2023-06-07 03:09:45Event JSON
{
"id": "56472c2fb9324a3862c3b819bea85ce1acf706a9b59b6958d12e3097796f48c0",
"pubkey": "5ab461bc713c73739adbc543fe021553ac026ff18e60267a0999d45ffdc3a943",
"created_at": 1686107385,
"kind": 1,
"tags": [
[
"e",
"431de1b2053f2297a5c4d8abb946e01d3f305001a64415bafb02369c2320d799",
"",
"root"
],
[
"e",
"9bb8756a03b73969955c04dd2a455eac9da872c807f7c3cd4d0b38db26f0383d",
"",
"reply"
],
[
"p",
"5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6"
]
],
"content": "📅 Original date posted:2012-02-28\n📝 Original message: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.\n\nIf someone were to do this on the day of the P2SH switchover they could corrupt the database of all clients \u003c 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.\n\nThank You,\nBen Reeves\nwww.blockchain.info\n\n\nOn 28 Feb 2012, at 18:23, Luke-Jr wrote:\n\n\u003e On Tuesday, February 28, 2012 11:48:39 AM Pieter Wuille wrote:\n\u003e\u003e A simple way to fix this, is adding an extra protocol rule[1]:\n\u003e\u003e \n\u003e\u003e Do not allow blocks to contain a transaction whose hash is equal to\n\u003e\u003e that of a former transaction which has not yet been completely spent.\n\u003e\u003e \n\u003e\u003e I've written about it in BIP30[2]. There is a patch for the reference\n\u003e\u003e client, which has been tested and verified to make the attack\n\u003e\u003e impossible.\n\u003e \n\u003e Has it been verified to make even rocconor's complicated transaction-based \n\u003e version impossible?\n\u003e \n\u003e\u003e The purpose of this mail is asking for support for adding this rule to\n\u003e\u003e the protocol rules. If there is consensus this rule is the solution, I\n\u003e\u003e hope pools and miners can agree to update their nodes without lengthy\n\u003e\u003e coinbase-flagging procedure that would only delay a solution. So, who\n\u003e\u003e is in favor?\n\u003e \n\u003e Can we do this in two steps? First, prefer blocks which don't break the rule; \n\u003e once 55%+ are confirmed to have upgraded, then it is safe to treat it as a \n\u003e hard rule.\n\u003e \n\u003e ------------------------------------------------------------------------------\n\u003e Keep Your Developer Skills Current with LearnDevNow!\n\u003e The most comprehensive online learning library for Microsoft developers\n\u003e is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,\n\u003e Metro Style Apps, more. Free future releases when you subscribe now!\n\u003e http://p.sf.net/sfu/learndevnow-d2d\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120228/6ef43bce/attachment.html\u003e",
"sig": "76aaa2d88c0569c828718c03b55800b58984296ccbec5c6de368100ffc7a8f20c4db15480f708ca1887f3cff23a130eda1dd35c52b29145af6c48935c1e9787a"
}