Note that I mentioned double-byte opcodes a few weeks ago on the forums; there's lots of people who know about this stuff and could have made that transaction.

I should also point out that the transaction appears to not only include a patch to fix Electrum, but at the same time also triggers the bug it patches. I think what happens is that the OP_INVALIDOPCODE triggers the broken double-wide code to advance a byte, ORing that byte with OP_INVALIDOPCODE << 8. Unfortunately that character is a PUSHDATA, which means that Electrum now processes the data as though it were opcodes. The next byte is 0x4e, or OP_PUSHDATA4, followed by the length of the data to be pushed, 0xffffffff=2^32 bytes. Of course there aren't 4GiB of data in the script, so it fails and Electrum gets stuck.

I think the OP_IF/OP_ENDIF was meant so that the transaction could be spent, but whomever did so forgot that PUSHDATA's > 520 bytes make a transaction invalid. Thus unless we change that limit - a hard-fork - the 15mBTC will be unspendable forever. (invalid opcodes are legal in an un-executed IF/ELSE/ENDIF branch, but oversized pushdata's are not)

I rather doubt that Satoshi would have made that mistake. 


That's just a reference to the previous commit ID the patch is meant to apply too. If you save that patch to a file you can apply it with git am patch.diff, it was probably created with git format-patch from the looks of it.