При попытке написать свой собственный интерпретатор для языка сценариев Bitcoin, я наткнулся на странный p2sh примера. Это выход 0 ТХ 00a9a38678ea3fe0308a9e04a777402b16ba43e3a1d9d3fcee9a67a2513c226d и был погашен в качестве входных данных 1 c51ffaf08188859669571f897f119b6d39ea48a9334212f554bf4927401b71f3.

Сценарий, чтобы позволить ему быть потрачены состоит из 81, а затем 603 0, затем 76, 201, и, наконец, 201 175-х годов. Это создает стек с 1, 603 пустыми массивами, а затем массив с 201 OP_CHECKMULTISIGVERIFY лет. Именно это 201 OP_CHECKMULTISIGVERIFY о том, что хэши дать адрес p2sh, как и ожидалось. После этого (видимо) 201 OP_CHECKMULTISIGVERIFY являются оценены и по существу все эти 603 пустые массивы извлекаются из стека. Каждый раз, когда OP_CHECKMULTISIGVERIFY оценивается два из 0 указывают, что это multisig 0-о-0, а затем дополнительно 0 выталкивается из-за OP_CHECKMULTISIG ошибки. После того, как все это произошло, все, что остается в стеке начальные 1 в стек до того, как это началось.

(Я должен кредитовать http://webbtc.com/script/c51ffaf08188859669571f897f119b6d39ea48a9334212f554bf4927401b71f3:1 с помогая мне прийти к этой интерпретации того, что происходит.)

Очевидно, кто-то может потратить от этого адреса. (Его баланс в настоящее время 0)

Во-первых, кто-нибудь знает историю позади этого примера? Было ли это, чтобы продемонстрировать что-то? Это только кажется странным.

Во-вторых, я не в состоянии понять что-то о том, почему этот сценарий успешно. Я бы ожидать, что это удастся (как я описал выше) если OP_CHECKMULTISIG были использованы вместо OP_CHECKMULTISIGVERIFY. Однако, не если OP_VERIFY вызвать сценарий на неудачу? В конце концов, когда первый OP_VERIFY после первого OP_CHECKMULTISIG оценивается, пустой массив находится в верхней части стека, а не 1.

В-третьих, я полагаю, кто-то может использовать дополнительные "ошибка" аргумент OP_CHECKMULTISIG для кодирования произвольных данных в сценарии без создания unspendable выходов и без использования OP_RETURN. Есть ли защититься от этого?