OP_CHECKSIG: обоснование построения подписанного сообщения
Я внимательно изучил заслуженно известное объяснение OP_CHECKSIG, найденное здесь , включая найденную диаграмму . В этом объяснении подробно описывается, как создать сообщение, подписанное через ECDSA, создавая цифровую подпись для SigScript. Все хорошо.
В качестве резюме вышеупомянутое сообщение представляет собой объединение новой строящейся транзакции (с ее выпиской из ScriptSigs) и scriptPubKey из вывода транзакции sourcing. Для ясности, «вывод транзакции источника» - это тот, который указан в строящемся транзакции по полю «Транзакционное хеширование» и его поле «Выходной индекс». Все хорошо.
МОЙ ВОПРОС: в новой строящейся транзакции его поле транзакционного хэша уже «отпечатывает» вывод транзакции источника. Зачем пытаться вставить вышеупомянутый scriptPubKey из вывода транзакции sourcing в сообщение? . Это кажется излишним, учитывая, что хеш-дайджест в поле транзакционного хеша отпечатывает всю транзакцию sourcing.
Я задаю этот вопрос, чтобы более подробно понять логику сложной конструкции сообщения, подписанного через ECDSA.
1 ответ
Я думаю, так как с некоторыми типами sighash скриптPubKey не является частью txid. Поэтому он не учитывается автоматически, когда txid уже является частью хэша.