wTXID

wTXID е хеш на цялата трансакция, включително witness. TXID хешира същата трансакция без witness. Блоковете ползват wTXID-ите, за да се ангажират с данните на witness, а вие все още ползвате TXID, за да намерите трансакция във веригата.

За трансакция без witness двете стойности са еднакви.

С какво се различава wTXID от TXID?

TXID обхваща версията, входовете, изходите и locktime. Пропуска маркера, флага и witness. wTXID обхваща цялата сурова трансакция, включително и тези три части.

Разликата съществува само при SegWit трансакциите. Стара (legacy) трансакция няма маркер, флаг или witness, така че wTXID и TXID са една и съща стойност.

Как се изчислява wTXID?

wTXID се получава, като се приложи HASH256 върху сериализираната трансакция. HASH256 означава SHA-256, приложен два пъти. В нотацията на BIP 141 изглежда така:

wTXID = HASH256(version | marker | flag | inputs | outputs | witness | locktime)

Биткойн показва хешовете с обърнат ред на байтовете, затова стойността, която връща хеш функцията, се обръща, преди да я видите. Същото правило важи и за TXID.

Ето изчислението на Python. Нужна е само стандартната библиотека, а raw_hex е пълната сериализирана трансакция, както я връща нодът:

import hashlib

def hash256(data: bytes) -> bytes:
    return hashlib.sha256(hashlib.sha256(data).digest()).digest()

raw = bytes.fromhex(raw_hex)        # цялата трансакция, включително witness
wtxid = hash256(raw)[::-1].hex()    # обръщаме байтовете за показване

TXID изисква още една стъпка. Входът му е същата трансакция без маркера, флага и witness, затова програмата, която го смята, първо трябва да премахне тези полета.

Пример със SegWit

Вземете SegWit трансакцията c06aaaa2…. Суровата ѝ форма е 225 байта. Ако премахнем маркера, флага и witness, получаваме TXID:

TXID:  c06aaaa2753dc4e74dd4fe817522dc3c126fd71792dd9acfefdaff11f8ff954d
wTXID: f12d56f2234e809129dbf59392961bbe7a89b6250651f6aea7852cc00ced63ff

Двете стойности се различават, защото wTXID хешира и witness. Само wTXID се променя, ако някой редактира подпис.

Пример със стара (legacy) трансакция

Старата трансакция 25346687… няма witness, така че TXID и wTXID са еднакви:

25346687d5d10239c25a88193c97228327826a4ff66a36c4ba7e038f3e2ae9ed

Ако работите със собствен нод, bitcoin-cli getrawtransaction <txid> 1 връща поле hash. То съдържа wTXID, който за стара трансакция е равен на TXID.

Къде се ползват wTXID-ите?

wTXID-ите се ползват на едно място: в ангажимента на witness в блока. Блок, чиито трансакции носят witness данни, трябва да се ангажира с тях. Ангажиментът идва от меркъл дърво, построено върху wTXID-ите, и се нарича witness merkle root.

Стъпките вървят в ред:

1. Вземете wTXID на всяка трансакция в блока. Coinbase е изключението: нейният wTXID се брои като 32 нулеви байта, защото самата тя съдържа ангажимента.
2. Построете меркъл корен върху този списък. Резултатът е witness merkle root.
3. Хеширайте witness merkle root заедно с 32-байтовата резервна стойност на witness, която днес е от нули. Резултатът е ангажиментът за wTXID.
4. Сложете ангажимента в изход на coinbase трансакцията, след 4-байтовата заглавна част. Ако повече от един изход има тази форма, важи този с най-голям индекс.

Пример: блок 553,724

Блок 553,724 има четири трансакции. Първите три използват SegWit, а последната не. Таблицата показва всяка стойност така, както я показват експлорърите. Самото дърво работи с обратния ред, тоест с естествения байтов ред на хеша.

Позиция	Трансакция	Стойност в дървото на witness
0	coinbase 2d4cdcd2…	32 нулеви байта
1	d367b86c…	wTXID 8700d546…
2	76d11f7e…	wTXID c54bab59…
3	e51de361…	нейният TXID, защото е стара (legacy)

Хеширането на witness merkle root с резервната стойност дава този ангажимент:

6502e8637ba29cd8a820021915339c7341223d571e5e8d66edd83786d387e715

Вторият изход на coinbase трансакцията го съдържа в тази форма:

OP_RETURN  OP_PUSHBYTES_36  aa21a9ed  6502e8637ba29cd8a820021915339c7341223d571e5e8d66edd83786d387e715

Заглавието aa21a9ed показва, че изходът е ангажимент за witness, а последните 32 байта съдържат самия ангажимент. Ние сме пресметнали корена отново от четирите трансакции в този блок и ангажиментът е съвпаднал с изхода на coinbase.

Тъй като ангажиментът покрива всеки witness в блока, промяна на подпис където и да е в блока го прави невалиден.

Защо TXID все още се ползва за търсене на трансакции?

TXID хешира какво прави трансакцията: монетите, които харчи, и изходите, които създава. Witness-ът само доказва, че харченето е разрешено. Подписите могат да се променят, без да се променя този ефект, така че TXID остава стабилен там, където wTXID не би.

Затова търсачките, портфейлите и експлорърите ползват TXID. Нашият експлорър отваря трансакцията на /tx/<txid>, така че wTXID никога не трябва да се въвежда.

Защо изобщо има два идентификатора?

Преди SegWit един идентификатор е бил достатъчен, а TXID се променяше, когато се промени подпис. SegWit премести подписите извън обхвата на TXID, което е решило този проблем. wTXID съществува, за да принадлежат witness данните към блока чрез ангажимента.

Щом трансакцията бъде потвърдена, изходите ѝ чакат в множеството UTXO, докато някой ги похарчи. Страницата за UTXO обяснява как нодовете ги следят.

Източници

• BIP 141: Segregated Witness дефинира wTXID, witness merkle root и ангажимента.
• BIP 141, структура на ангажимента описва изхода и заглавната част.