Как OP_CHECKSIG знает источник подписи в транзакции хеширования оплаты для публичного ключа

https://en.bitcoin.it/wiki/Script#Standard_Transaction_to_Bitcoin_address_.28pay-to-pubkey-hash.29

Последним этапом транзакции pay to хэш pubkey является проверка подписи хэша tx и pubkey предыдущей транзакции.

Но как интерпретатор сценария узнает, что сиг является подписью предыдущего хэша перехода, что, если сиг является подписью какого-то другого контента?

Ответы (1)

Но откуда интерпретатор скрипта знает, что сиг — это сигнатура предыдущего хэша перехода, что, если сиг — это сигнатура какого-то другого контента?

Он также сравнивает подписанные данные с самим хешем транзакции. В общем, так работают цифровые подписи. Если данные не подписаны правильным ключом и хэш данных не совпадает , то подпись недействительна. См. src/script/interpreter.cpp L#1264 .

Этот процесс проверки гарантирует две вещи:
1. У человека есть закрытый ключ, который соответствует предоставленному открытому ключу.
2. Данные не были изменены.

Код в SignatureHash() выглядит так, будто реконструирует (l1217~1235) часть транзакции и снова хеширует. Затем используйте pubKey для проверки хэша и подписи. Являются ли «данные», о которых вы упоминали выше, реконструированным списком байтов?
На самом деле это не просто, но здесь есть хорошее объяснение того, что хешируется и подписывается: bitcoin.stackexchange.com/a/5241/60443
Еще один вопрос, на шаге 9, почему отправитель будет определять комиссию (0,001) в процессе ввода генерации. Если это правда, как верификатор мог узнать, какова плата за хеш-код? На самом деле, из кода в GitHub похоже, что он использует исходную сумму напрямую, а в gitbub он выводит сумму, а затем последовательность (FFFFFFFF), но в этом посте сначала порядок, подобный сумме, а затем вывод скрипта в шаге 9 и шаг 10.
Как OP_CHECKSIG знает источник подписи в транзакции хеширования оплаты для публичного ключа
СпросиСетьПолитика конфиденциальности1y, 0v