Что такое Witness и какие данные он содержит?

Я узнал о Segregated Witness, но не смог найти информацию о том, как его разбить.

Я знаю, что обычно, когда используются устаревшие адреса, открытые ключи, например, будут находиться под расширением Scriptig. С P2SH я вижу, что ScriptSigсодержит хэш, который redeemScriptдолжен соответствовать хешу адреса в выводе (я думаю). Но я не уверен в witnessданных.

Возьмем этот ТХ: 80975cddebaa93aa21a6477c0d050685d6820fa1068a2731db0f39b535cbd369

Какая информация в witness, может кто разобрать, пожалуйста?

Ответы (3)

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

Свидетель — это сериализация всех данных свидетеля транзакции. Каждый txin связан с полем-свидетелем. Поле-свидетель начинается с var_int, чтобы указать количество элементов стека для txin. За ним следуют элементы стека, каждый элемент начинается с var_int для указания длины. Данные свидетеля НЕ являются сценарием. См. BIP 141 .

Свидетельские данные зависят от типа транзакции.

Вход 3

Глядя на ввод транзакции № 3 в необработанном json :
script =a914771962306e72e479245d48e879dd2a1862225b4c87

Это имеет структуру транзакции Pay to Script Hash (P2SH). Из-за данных-свидетелей это, вероятно, мультиподписной P2WSH, вложенный в BIP16 P2SH :

witness:      0 <signature1> <1 <pubkey1> <pubkey2> 2 CHECKMULTISIG>
scriptSig:    <0 <32-byte-hash>>
              (0x220020{32-byte-hash})
scriptPubKey: HASH160 <20-byte-hash> EQUAL
              (0xA914{20-byte-hash}87)

свидетель:
04(4 элемента стека)

00(1-й элемент стека, 0 байт)

47(2-й элемент стека, первая подпись, шестнадцатеричный: 0x47, десятичный: 71 байт)304402202c3f94e5daf4057377d9f16d45b57e962de42fb42cb7e95a0382b7c66624980a02204098f6acd43b0391ea1b4a8102797e78895848fb7e883f98d207d14d45945a6901

47(3-й элемент стека, вторая подпись, шестнадцатеричный: 0x47, десятичный: 71 байт)30440220448460edd5291a548c571ccf3a72caf47b02364035dc84f420d311e3a0c5494802205bb1cc89f20dc1e2c1f6eadb74898f8eecc46fbf488b676636b45fafaeb96e0f01

69(4-й элемент стека, сценарий с несколькими знаками 2 из 3, шестнадцатеричный: 0x69, десятичный: 105 байт)
<52 OP_2>
21(33 байта)
<021e6617e06bb90f621c3800e8c37ab081a445ae5527f6c5f68a022e7133f9b5fe pubkey1>
21(33 байта)
<03bea1a8ce6369435bb74ff1584a136a7efeebfe4bc320b4d59113c92acd869f38 pubkey2>
21(33 байта)
<0280631b27700baf7d472483fadfe1c4a7340a458f28bf6bae5d3234312d684c65 pubkey3> <53 OP_3><ae OP_CHECKMULTISIG>

Обратите внимание, что OP_2и OP_3указывают, что это сценарий транзакции с мультиподписью 2 из 3. См. Pay-to-Script-Hash | Сделка

Спасибо! Теперь я намного лучше понимаю данные свидетелей. Последнее уточнение, пожалуйста. Итак, команда OP_1говорит: возьмите эти две подписи и добавьте их в стек . OP_2инструктирует добавить следующие три pubKeys и OP_3говорит , что для проверки этого TX OP_1необходимы 2 из 3 подписей, соответствующих ? Или 2 из 3 подписей будут необходимы для завершения TX в следующем INPUT? Декодирование scriptSigдля входа 3 не приводит к multiSig. 002044c55c1da36a576217259c3bc21b0c3943f7eb3ff4e3c381d9fd3502434b9e87дает type: scripthash. Еще раз спасибо.
Кто-то должен будет исправить меня, если я ошибаюсь, но я считаю, что 0x04 говорит вам, что есть 4 элемента стека, нет OP_1 (есть пустой элемент стека, не знаю почему), формат мультиподписи P2SH такой : m-of-n multi-signature transaction: scriptSig: 0 <sig1> ... <script> script: OP_m <pubKey1> ... OP_n OP_CHECKMULTISIGСм . en.bitcoin.it/wiki/Transaction#Pay-to-Script-Hash .
Я знаю, что это старая тема, но я хотел бы получить немного больше информации о 4-м элементе стека, поскольку я видел, что это сценарий выкупа, но как только я использую публичные ключи для создания ключа мультиподписи, он отличается. Есть предположения?

Для вариантов вывода segwit (P2PKH становится P2WPKH, а P2SH становится P2WSH) свидетель содержит те же данные, что и в scriptSig. Для P2PKH в scriptSig у вас будет подпись и открытый ключ. То же самое и в свидетеле для P2WPKH.

Для P2SH у вас будет redeemScript, подписи и другие вещи в scriptSig. Для P2WSH они находятся в свидетеле, а redeemScript в свидетеле называется свидетелем.

Важно отметить, что свидетель будет выглядеть иначе, чем scriptSig. Это потому, что на самом деле это не скрипт, а набор элементов. Стандартный scriptSig — это тот, который только помещает элементы в стек. Свидетель делает еще один шаг вперед, предоставляя стек для использования вместо того, чтобы выполнять сценарий, который создает тот же стек.

В дополнение к JBaczuk и Andrew Chow, вот подробная расшифровка tx. Это смешанная транзакция с тремя «обычными» входами и 4-м входом типа segwit (TX_IN[3]). Поэтому после поля версии tx мы видим байты «0001», где 0x01 указывает на то, что структура данных segwit включена в tx. В разделе ввода есть три следующих «стандартных» элемента, также с многозначными подписями. Четвертый входной элемент (TX_IN[3]) — это часть segwit. Скрипты заполнены без подписей, только структура 0x0020{32-byte scripthash}.

В конце следует 0x00000004, каждый байт — это количество элементов segwit на вход. Таким образом, первые три байта равны «0», что означает, что для этих входных данных не используется структура segwit, а затем четвертый байт равен 0x04, что указывает на четыре элемента данных-свидетелей: «0x00» для компенсации удаления элемента стека во время оценки скрипта, подпись, еще одна подпись и сценарий выкупа.

VERSION 01000000
SEGWIT (BIP141):       this is a segwit tx, marker=00
       (BIP141):       flag=01
TX_IN COUNT [var_int]: hex=04, decimal=4
 TX_IN[0]
  TX_IN[0] OutPoint hash  08A1266CED5EF064741BD4BC51C1202456F22509AE030231860D6E9BEF4ACD5E
  TX_IN[0] OutPoint index hex=62000000, reversed=00000062, decimal=98
  TX_IN[0] Script Length  hex=FC, decimal=252
  TX_IN[0] Script Sig     0047304402207E38831ECA394E472E...555C0E2D7A9D9915D6986BFC200453AE 
  TX_IN[0] Sequence       FFFFFFFF
 TX_IN[1]
  TX_IN[1] OutPoint hash  AD4C8508B8D5EECE6FD100B58D667DEA9C7A8C178C1B06602C1E3358D8105C0B
  TX_IN[1] OutPoint index hex=7D000000, reversed=0000007D, decimal=125
  TX_IN[1] Script Length  hex=FC, decimal=252
  TX_IN[1] Script Sig     0047304402203299B925B1F2C87282...ABDC12E55B0F545FFF14667A515F53AE 
  TX_IN[1] Sequence       FFFFFFFF
 TX_IN[2]
  TX_IN[2] OutPoint hash  C8066B798384B502F225BD89F7EB405265357CB0BDC0C169FE96B013310629B2
  TX_IN[2] OutPoint index hex=A3000000, reversed=000000A3, decimal=163
  TX_IN[2] Script Length  hex=00FD, decimal=253
  TX_IN[2] Script Sig     0047304402204D4DA5303BE178D649...B5A43BC43D60C844F65DB8FB78AD53AE 
  TX_IN[2] Sequence       FFFFFFFF
 TX_IN[3]
  TX_IN[3] OutPoint hash  D80FF02D0D9EB2DA8C8A1C47AB099901F447DD197E34220EA13ECA72D7D6D21D
  TX_IN[3] OutPoint index hex=9A000000, reversed=0000009A, decimal=154
  TX_IN[3] Script Length  hex=23, decimal=35
  TX_IN[3] Script Sig     22002044C55C1DA36A576217259C3BC21B0C3943F7EB3FF4E3C381D9FD3502434B9E87 
  TX_IN[3] Sequence       FFFFFFFF
TX_OUT COUNT, hex=05, decimal=5
 TX_OUT[0]
  TX_OUT[0] Value         hex=C0D4010000000000, reversed_hex=000000000001D4C0, dec=120000
  TX_OUT[0] PK_Script Len hex=17, dec=23
  TX_OUT[0] pk_script     A914A1932CFD432D928311B4ADA550BBC468D1E909B787
 TX_OUT[1]
  TX_OUT[1] Value         hex=A086010000000000, reversed_hex=00000000000186A0, dec=100000
  TX_OUT[1] PK_Script Len hex=17, dec=23
  TX_OUT[1] pk_script     A9146B0E7A66416F1D8598B5956576ADB22DAF79853E87
 TX_OUT[2]
  TX_OUT[2] Value         hex=3A4A000000000000, reversed_hex=0000000000004A3A, dec=19002
  TX_OUT[2] PK_Script Len hex=17, dec=23
  TX_OUT[2] pk_script     A914EC4C73145428ABBE0B1C40FBF58C59F0EF3C29F487
 TX_OUT[3]
  TX_OUT[3] Value         hex=382C050000000000, reversed_hex=0000000000052C38, dec=339000
  TX_OUT[3] PK_Script Len hex=17, dec=23
  TX_OUT[3] pk_script     A914ABB18A298E5B629BF5652F341D2CD8207CCC214A87
 TX_OUT[4]
  TX_OUT[4] Value         hex=8010020000000000, reversed_hex=0000000000021080, dec=135296
  TX_OUT[4] PK_Script Len hex=19, dec=25
  TX_OUT[4] pk_script     76A91438D769CF2899983022B5611AB4D35BF7907DAE2088AC

WITNESS TXIN[0] stack elements: hex=00, decimal=0
WITNESS TXIN[1] stack elements: hex=00, decimal=0
WITNESS TXIN[2] stack elements: hex=00, decimal=0
WITNESS TXIN[3] stack elements: hex=04, decimal=4
 WITNESS data[0]: 00
 WITNESS data[1]: 4730440220...D207D14D45945A6901
 WITNESS data[2]: 4730440220...36B45FAFAEB96E0F01
 WITNESS data[3]: 695221021E...3234312D684C6553AE

LOCK_TIME 00000000

Хорошее резюме всех деталей segwit здесь .

Спасибо за ответ. Могу я спросить, что вы используете для декодирования TX с такой детализацией? Я использую chainquery.com
Я узнал из книги Андреаса и форума здесь, поэтому я написал несколько сценариев оболочки unixoid. А если самомаркетинг разрешен (бессовестно), то код можно найти здесь: github.com/pebwindkraft/trx_cl_suite . В пакете транзакций есть инструмент (скрипт оболочки) «tcls_tx2txt.sh» для декодирования, как показано выше (а затем я немного украсил его, так что лучше подходит для форума здесь).
Отличный. Скоро поиграю со скриптом на bash, спасибо! Это полезно для всех, кто интересуется сообществом, поэтому я не думаю, что это похоже на рекламу :)