If you look at the output scripts of the transaction, this is a patch for the bug that was used to embed the patch in the transaction in the first place. Clever.
I'm not versed enough in bitcoin script to say definitively, but just guessing, it may be that the bug is that this is a way to get a non-standard txn mined.
The block containing the transaction was mined by Eligius. The Eligius pool allows non standard transactions if the transation is relayed to it directly (plus a fee for the service I think).
v_64, nesting is too deep to reply directly, but it doesn't need to be a merged miner for it to accept non standard transactions. Transactions are coded in a mini scripting language. A 'standard' transaction is one using opcodes in a particular format for normal transactions. 'non-standard' transactions allow for a number of different things but because bitcoin developers are cautious they're not relayed between peers by default.
They are accepted and valid in blocks though. So any miner can include them in their blocks. What Eligius, and some other pools do, is they allow accepting the transaction directly. So you connect your node to it directly and send the transaction as normal. It won't be relayed to other peers as they reject it. But those running a modified client will and can include it in a block.
Interesting. Is Eligius what you would call a merged miner (see [1])? Why would someone pay to have their non-standard txn mined? Is it just for examples/bug demos such as these, or are there other reasons? And I assume these just end up living in their own alternative chain[1]?
