Ben Reeves [ARCHIVE] on Nostr: 📅 Original date posted:2012-02-28 📝 Original message:I might be wrong but I ...
📅 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>;
📝 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>;