Как майнеры подтверждают транзакцию, если у InputScript есть только Sig

Пожалуйста, помогите мне понять, как биткойн-клиент проверяет TX с помощью входного скрипта, состоящего только из Sig.

Например, TX 6D5DF6C0D66CFFC25CC1ABA3655952D7B081ED4E9EA3B70FCD964FDBBA01E91Eимеет один вход из D9A9C88110775B196CDAF6FC8113B33547C8E33E68519F60D9C9FF306E096473транзакции (8 выходов) с помощью Input Script 4730440220797681C6711BB3D97AE373FC5CFF47F06EEC928DD46B8A9892D92C30953C9DF3022079C36E9A4C32D4E36B9E3ACCED0D40D70D8F90890C0E9F8F4F9AC083AFFD21B301.

Этот скрипт имеет только Sig (r,s) и не имеет никакого представления открытого ключа или адреса.

Насколько я понимаю, Sigсоздается с помощью UnsignedTX doubleSHA256 hash, Random Numberи Private Key.

Sigпроверка с помощью UnsignedTX doubleSHA256 hashи Public Key, но здесь нет ничего из этого.

Также вопрос о «Где хранится UnsignedTX doubleSHA256 hash?». Потому что это не хэш транзакции, потому что хеш TX предназначен для подписанной транзакции.

Ответы (1)

Для проверки транзакции требуются предыдущие выходные данные транзакции, из которых транзакция тратит деньги. Выходной сценарий предыдущих выходов транзакции извлекается для каждого входа. Входной скрипт сначала запускается через интерпретатор скриптов. Полученный стек затем используется в качестве начального состояния для прохода скрипта вывода предыдущей транзакции через интерпретатор скрипта.

Для конкретной транзакции, которую вы выбрали, сценарий вывода предыдущей транзакции имеет вид

<pubkey> OP_CHECKSIG

и вход имеет форму

<sig>

Это означает, что подпись сначала помещается в стек. Затем открытый ключ помещается в стек, а затем OP_CHECKSIGприменяется к двум элементам стека. Открытый ключ находится в выходном скрипте. Для других типов вывода открытый ключ предоставляется во входном скрипте как часть затрат.

Хэш, подписанный как сообщение, создается самой расходной транзакцией. Он содержит данные, предоставленные в расходной транзакции и предыдущем скрипте вывода транзакции, поэтому его можно генерировать на лету. Вы можете проверить этот вопрос и ответить на него. Как определить, какую часть предыдущего TX мне нужно сделать хэшем для подписи для старого данного TX? который разбирает, как этот хэш генерируется для входных данных без SegWit.

как я понимаю из вашего ответа, неподписанная транзакция генерируется на лету, а затем делает двойной хэш sha256 для проверки Sig?
Да. Создается прообраз sighash (модифицированная версия неподписанной транзакции), который хешируется с помощью SHA256d. Этот хэш либо подписан, либо проверен, в зависимости от того, что вы хотите сделать.