Все термины, которые я нахожу, кажутся довольно запутанными в отношении того, что что объясняет, и они обычно пропускают несколько шагов.
Пример: транзакция 82d62d5f4e69ae8338c39b7ae2e1d33db59bdf62c869ded7344adc936bab8653.
Найдено по адресу https://blockchain.info/tx/82d62d5f4e69ae8338c39b7ae2e1d33db59bdf62c869ded7344adc936bab8653.
Показывает «Входной сценарий»:
3045022100d52330113ccd033ccb1aaa3b759e9696c216e802922e5f1902cd5ada69c612e5022057880205319dccb05eebbe34323a852ee82653f09f81253ddccd08a810e9d42d01 03e5b9f0bb669b289efb8d2826487a24ef5f3985624c8bc3a3e34f6bd54e080b27
Итак, какие части есть что, и как я могу определить, какие части являются чем в «входном сценарии» этой транзакции, а также в других?
3045022100d52330113ccd033ccb1aaa3b759e9696c216e802922e5f1902cd5ada69c612e5022057880205319dccb05eebbe34323a852ee82653f09f81253ddccd08a810
Является подписью ECDSA в кодировке DER. Я сломаю это:
30
указывает, что следует составная структура (подписи ECDSA рассматриваются как составные из двух целых чисел, r и s)
45
общая длина составной структуры (исключая 2 байта заголовка, 30 45), 69.
02
начало содержимого составной структуры, 02 указывает целое число (значение r подписи)
21
33 байта
00d52330113ccd033ccb1aaa3b759e9696c216e802922e5f1902cd5ada69c612e5
целочисленное значение, закодированное в 33 байтах с обратным порядком байтов. Первый байт равен нулю, так как без него он интерпретировался бы как отрицательное число (см. нотацию дополнения до 2).
02
следует другое целое число (s)
20
32 байта
57880205319dccb05eebbe34323a852ee82653f09f81253ddccd08a810e9d42d
32 байта, кодирующие значение s
01
это байт sighash, добавленный Биткойном, и технически он не является частью подписи ECDSA. Таким образом, он не считается частью длины 69 (байт 45) в начале. Он указывает, какие поля транзакции подписаны. 01 означает «все».
подпись: 483045022100d52330113ccd033ccb1aaa3b759e9696c216e802922e5f1902cd5ada69c612e5022057880205319dccb05eebbe34323a852ee82653f09d09a4dccd018581ddccd0
и его разложение:
##################################################################
### tcls_in_sig_script.sh: decode SIG_script OPCODES from a TX ###
##################################################################
48: OP_DATA_0x48: push hex 48 (decimal 72) bytes as data
30: OP_SEQUENCE_0x30: type tag indicating SEQUENCE, begin sigscript
45: OP_LENGTH_0x45: length of R + S
02: OP_INT_0x02: type tag indicating INTEGER
21: OP_LENGTH_0x21: this is SIG R
00D52330113CCD03:3CCB1AAA3B759E96
96C216E802922E5F:1902CD5ADA69C612
E5
02: OP_INT_0x02: type tag indicating INTEGER
20: OP_LENGTH_0x20: this is SIG S
57880205319DCCB0:5EEBBE34323A852E
E82653F09F81253D:DCCD08A810E9D42D
01: OP_SIGHASHALL: this terminates the ECDSA signature (ASN1-DER structure)
3045022100d52330113ccd033ccb1aaa3b759e9696c216e802922e5f1902cd5ada69c612e5022057880205319dccb05eebbe34323a852ee82653f09f81253ddccd08a810
является подписью ECDSA с ключом отправителя.
03e5b9f0bb669b289efb8d2826487a24ef5f3985624c8bc3a3e34f6bd54e080b27
является открытым ключом отправителя (чей хэш хранится в адресе, на который ранее были отправлены монеты).
Однако, чтобы интерпретировать их, вам нужно посмотреть на расходуемый результат, а именно:
OP_DUP OP_HASH160 6ffdc2e9e69434a7832208db5a6148c67563e8ae OP_EQUALVERIFY OP_CHECKSIG
Это сценарий, который принимает в качестве входных данных открытый ключ и подпись, проверяет, является ли хэш открытого ключа 6ffdc2e9e69434a7832208db5a6148c67563e8ae
, а затем сверяет подпись с этим открытым ключом.
В общем, чтобы знать, что к чему в скрипте Sig, нужно смотреть на расходуемый вывод. Вывод дает условия, при которых он может быть потрачен (в виде скрипта), а ввод просто содержит «переменные», переданные в процедуру проверки вывода.
Мой
Питер Уилле
Мой
мешколлайдер
Питер Уилле