Я узнал о Segregated Witness, но не смог найти информацию о том, как его разбить.
Я знаю, что обычно, когда используются устаревшие адреса, открытые ключи, например, будут находиться под расширением Scriptig
. С P2SH я вижу, что ScriptSig
содержит хэш, который redeemScript
должен соответствовать хешу адреса в выводе (я думаю). Но я не уверен в witness
данных.
Возьмем этот ТХ: 80975cddebaa93aa21a6477c0d050685d6820fa1068a2731db0f39b535cbd369
Какая информация в witness
, может кто разобрать, пожалуйста?
Эта структура содержит данные, необходимые для проверки достоверности транзакции, но не требуемые для определения последствий транзакции. В частности, в эту новую структуру перемещены сценарии и подписи.
Свидетель — это сериализация всех данных свидетеля транзакции. Каждый txin связан с полем-свидетелем. Поле-свидетель начинается с var_int, чтобы указать количество элементов стека для txin. За ним следуют элементы стека, каждый элемент начинается с var_int для указания длины. Данные свидетеля НЕ являются сценарием. См. BIP 141 .
Свидетельские данные зависят от типа транзакции.
Глядя на ввод транзакции № 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 | Сделка
Для вариантов вывода 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 здесь .
Роберт
OP_1
говорит: возьмите эти две подписи и добавьте их в стек .OP_2
инструктирует добавить следующие три pubKeys иOP_3
говорит , что для проверки этого TXOP_1
необходимы 2 из 3 подписей, соответствующих ? Или 2 из 3 подписей будут необходимы для завершения TX в следующем INPUT? ДекодированиеscriptSig
для входа 3 не приводит к multiSig.002044c55c1da36a576217259c3bc21b0c3943f7eb3ff4e3c381d9fd3502434b9e87
даетtype: scripthash
. Еще раз спасибо.Дж.Бачук
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 .Аллан Романато