Из каких частей состоит скрипт «Ввод» биткойн-транзакции?

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

Пример: транзакция 82d62d5f4e69ae8338c39b7ae2e1d33db59bdf62c869ded7344adc936bab8653.

Найдено по адресу https://blockchain.info/tx/82d62d5f4e69ae8338c39b7ae2e1d33db59bdf62c869ded7344adc936bab8653.

Показывает «Входной сценарий»:

3045022100d52330113ccd033ccb1aaa3b759e9696c216e802922e5f1902cd5ada69c612e5022057880205319dccb05eebbe34323a852ee82653f09f81253ddccd08a810e9d42d01 03e5b9f0bb669b289efb8d2826487a24ef5f3985624c8bc3a3e34f6bd54e080b27

Итак, какие части есть что, и как я могу определить, какие части являются чем в «входном сценарии» этой транзакции, а также в других?

Ответы (3)

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 означает «все».

Это было фантастически! Только одна последняя часть; Являются ли эти значения всегда одинаковым количеством шестнадцатеричных символов? IE: всегда ли «02», обозначающие целое число, представлены во входных сценариях в биткойн-транзакциях двузначным числом? Могу ли я посмотреть на другие входные биткойн-скрипты для транзакций и просто подсчитать количество шестнадцатеричных чисел/букв, чтобы определить, какая часть какая? Значения r и s в этом примере представляют собой 64 шестнадцатеричных символа каждое. Это всегда так?
Да, может незначительно отличаться только длина байтов.
Что такое «байты длины» по сравнению с фактическим количеством шестнадцатеричных символов?
+1 к обоим вашим ответам за очень четкое и подробное объяснение :)
45, 21 и 20 — это дескрипторы длины.

подпись: 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, нужно смотреть на расходуемый вывод. Вывод дает условия, при которых он может быть потрачен (в виде скрипта), а ввод просто содержит «переменные», переданные в процедуру проверки вывода.

Спасибо, это действительно помогает некоторым, но это не то же самое, что первое определенное количество чисел, ссылающихся на что-то конкретное, а затем внутри него есть еще 2-3 части? Вот что меня интересует в этом вопросе. Вы сказали, что ввод содержит только «переменные», какие его части являются переменными и какие это переменные?
Я добавлю еще один ответ для этого.