Как работают транзакции «Pay to Script Hash»?

BIP16 дает следующий пример, чтобы объяснить «Платить за хэш сценария»:

scriptSig:    [signature] {[pubkey] OP_CHECKSIG}
scriptPubKey: OP_HASH160 [20-byte-hash of {[pubkey] OP_CHECKSIG} ] OP_EQUAL

Но я не понимаю, что здесь происходит. Я попытался выполнить скрипт на бумаге (и предположил, что части в квадратных/фигурных скобках рассматриваются как константы):

  1. [signature]и {[pubkey] OP_CHECKSIG}помещаются в стек
  2. OP_HASH160хеши{[pubkey] OP_CHECKSIG}
  3. Тот же хеш поступает из scriptPubKeyв стек
  4. Следовательно, OP_EQUALдаетTrue
  5. Это [signature]вообще не проверяется!

Если {[pubkey] OP_CHECKSIG}выполняется, то scriptSig выдаст только True, что имеет еще меньше смысла.

Чтобы сформулировать четкий вопрос: как работают сценарии «Pay to Script Hash», особенно в этом примере?

Ответы (1)

Вы правы до сих пор, вы просто остановились, прежде чем закончили. Как сказано в BIP16, он «определяет дополнительные правила проверки, которые применяются только к новым транзакциям» — в частности, «{сериализованный скрипт} извлекается из исходного стека, и транзакция снова проверяется с использованием извлеченного стека и десериализованного скрипта в качестве скриптPubKey."

Так:

1) Скрипт извлекается из стека, остается только [signature]в стеке.

2) Добавляется десериализованный скрипт, оставляя [signature] [pubkey] OP_CHECKSIG.

2) Транзакция снова проверяется, то есть происходит обычная проверка подписи по указанному открытому ключу.

Я хотел бы более подробное руководство или ссылку на него. я все еще не понимаю.
На самом деле это вообще не отвечает на вопрос о том, как выполняются отправленные байты сценария. Я предполагаю, что BIP16 где-то в своем сложном языке не дает определения тому, как сеть идентифицирует «сериализованный сценарий», поскольку это просто данные. Почему нельзя пытаться интерпретировать подписи, открытые ключи и т. д. как сценарии, учитывая это определение?