While trying to write my own interpreter for the Bitcoin script language, I came across a strange p2sh example. It is output 0 of tx 00a9a38678ea3fe0308a9e04a777402b16ba43e3a1d9d3fcee9a67a2513c226d and was redeemed as input 1 of c51ffaf08188859669571f897f119b6d39ea48a9334212f554bf4927401b71f3.
The script to allow it to be spent consists of 81, followed by 603 0's, then 76, 201, and finally 201 175's. This builds a stack with 1, 603 empty arrays, and then an array with 201 OP_CHECKMULTISIGVERIFY's. It's this 201 OP_CHECKMULTISIGVERIFY's that hashes to give the p2sh address, as expected. After that (apparently) the 201 OP_CHECKMULTISIGVERIFY's are evaluated and essentially all these 603 empty arrays are popped off the stack. Each time OP_CHECKMULTISIGVERIFY is evaluated two of the 0's indicate it is a 0-of-0 multisig and then an extra 0 is popped off due to the OP_CHECKMULTISIG bug. After all this has happened, all that remains on the stack is the initial 1 pushed onto the stack before any of this started.
(I should credit
http://webbtc.com/script/c51ffaf08188859669571f897f119b6d39ea48a9334212f554bf4927401b71f3:1 with helping me come to this interpretation of what happens.)
Obviously anyone can spend from this address. (Its balance is currently 0.)
Firstly, does anyone know the story behind this example? Was it to demonstrate something? It just seems odd.
Secondly, I'm failing to understand something about why this script succeeds. I would expect it to succeed (as I described above)
if OP_CHECKMULTISIG were used instead of OP_CHECKMULTISIGVERIFY. However, shouldn't the OP_VERIFY cause the script to fail? After all, when the first OP_VERIFY after the first OP_CHECKMULTISIG is evaluated, the empty array is at the top of the stack, not 1.
Thirdly, I suppose someone could use the extra "bug" argument of OP_CHECKMULTISIG to encode arbitrary data into scripts without creating unspendable outputs and without using OP_RETURN. Is there a guard against this?
