Topic: Testnet script which does not follow basic chunking rules... (Read 1091 times)

Now observed on the prodnet: http://blockexplorer.com/tx/ebc9fa1196a59e192352d76c0f6e73167046b9d37b8302b6bb6968dfd279b767
I think it is quite interesting that this is the first time in 4 years that we see something like that, and that it was a first for testnet 9 days ago.

Yes, but CScript::GetSigOpCount() simply quits counting if it runs into an invalid script.

Would be good to add more test-cases for that though... It's also kinda an odd decision by satoshi to count scriptPubKey sigops, as they aren't executed when a block is processed.

Does the SigOp count check not parse through scriptPubKey?

IsStandard() rules sure, but there's nothing stopping a miner from putting whatever they want in a scriptPubKey.

I was under the impression that there were some basic chunking encoding rules (except for maybe coinbase input scripts), especially since no scripts have ever broken them until recently.
So you are saying that those kind of output scripts also may occur on prodnet?

There's nothing in Bitcoin that checks the contents of a scriptPubKey until someone tries to spend it.

Don't assume anything about what's in one.

On testnet I have observed output scripts that do not follow (what I consider) the basic chunking rules.

First occurrence in the testnet block chain (October 14 2013):
 Block: 0000000001fd48a0089ed98737a9212c62e7708d8ddde3aea7a9f57a138f769d
 Transaction outpoint: 4fed625bfe36c2d17d839a6407be374663ad823c2cde7073319bb51b8025a221:0
 Script bytes: 0130323066643366303435313438356531306633383837363437356630643265396130393739343 3323535343137666531393164386239636232306534306438633330303264313734633365393063 6632343339323138376131303762363437333763393733313563393239326465343137373163656 5613062323563633534353732653302ae

According to chunk decoding rules it should have 5 chunks with lengths 1, 50, 1, 57, 49. At the last chunk it goes beyond the script length. 
Chunk 1 (length  1): 0x30
Chunk 2 (length 50): 3066643366303435313438356531306633383837363437356630643265396130393739343332353 534313766653139316438
Chunk 3 (length  1): 0x62 (OP_VER)
Chunk 4 (length 57): 6362323065343064386333303032643137346333653930636632343339323138376131303762363 43733376339373331356339323932646534
Chunk 5 (length 49): 373731636565613062323563633534353732653302ae (only 22 of 49 bytes available)

According to my code it has never happened before on testnet, and never on prodnet.

On testnet it happens 3 times in block 0000000001fd48a0089ed98737a9212c62e7708d8ddde3aea7a9f57a138f769d and once in block 0000000000b6f43e05f86dfe2007107fc88ace03457294d7f74d960b239dc8bf

I was under the impression that non-standard output scripts were accepted on testnet, but that they should follow basic chunking rules.
Since bitcoind accepts those output scripts on testnet I have adapted my code to be more lax when doing script validation.

Can anyone confirm whether this can also happen on prodnet?