На testnet я наблюдал выходные сценарии, которые не следуют (что я считаю) основные правила отрывов.

Первое появление в testnet блока цепи (14 октября 2013):
 Блок: 0000000001fd48a0089ed98737a9212c62e7708d8ddde3aea7a9f57a138f769d
 минуса Сделка: 4fed625bfe36c2d17d839a6407be374663ad823c2cde7073319bb51b8025a221: 0
 байт сценария: 0130323066643366303435313438356531306633383837363437356630643265396130393739343 3323535343137666531393164386239636232306534306438633330303264313734633365393063 6632343339323138376131303762363437333763393733313563393239326465343137373163656 5613062323563633534353732653302ae

Согласно правилам декодирования кусок он должен иметь 5 кусков с длиной 1, 50, 1, 57, 49. На последнем куске он выходит за пределы длины сценария. 
Кусок 1 (длина 1): 0x30
Кусок 2 (длина 50): 3066643366303435313438356531306633383837363437356630643265396130393739343332353 534313766653139316438
Кусок 3 (длина 1): 0x62 (OP_VER)
Кусок 4 (длина 57): 6362323065343064386333303032643137346333653930636632343339323138376131303762363 43733376339373331356339323932646534
Кусок 5 (длина 49): 373731636565613062323563633534353732653302ae (только 22 из 49 байт доступно)

По словам моего кода она никогда раньше не случалось на testnet, и никогда на prodnet.

На testnet это происходит 3 раза в блоке 0000000001fd48a0089ed98737a9212c62e7708d8ddde3aea7a9f57a138f769d и один раз в блоке 0000000000b6f43e05f86dfe2007107fc88ace03457294d7f74d960b239dc8bf

Я был под впечатлением, что нестандартные сценарии выдачи были приняты на testnet, но они должны следовать основным правилам отрывов.
Поскольку bitcoind принимает эти выходные сценарии на testnet я адаптировал свой код, чтобы быть более гибкими при выполнении проверки сценария.

Может кто-нибудь подтвердить, действительно ли это может случиться на prodnet?