Pagpasok ng SegWit sa Bitcoin, may kinakailangang laman uli ang coinbase transaction, na nakalagay naman sa output. Ito ay ang paglalagay ng wTXID commitment.
Napag-usapan na natin ang TXID. Ang mga legacy TXID ay kasama ang witness data sa na double-SHA256. Subalit ang mga SegWit na TXIDs ay hindi isinasama ang witness sa hashing. Ito ay para nga matanggal ang transaction malleability na binanggit sa Kabanata 4.
Legacy transaction vs SegWit transaction
Sa SegWit, may double-SHA256 pa rin na kasama ang witness. Ito ang witness transaction IDs (wTXID). Kapag kinuha ang Merkle Root ng mga wTXIDs, ito ay tinatawag na witness root hash. Ang witness root hash ay dudugtungan ng witness reserved value, bago idaan sa huling double-SHA256 para Mabuo ang wTXID commitment. Ito na ang inilalagay sa isa sa mga output ng coinbase transaction, bilang commitment. Ito ay para kung sakali mang may malisyosong miners na magpalit ng witness data sa kahit isang transaksyon, hindi na magbabangga ang witness root hash kapag bineripika ng ibang nodes. Kaya ang block ay magiging imbalido.
Tandaan: sa mga legacy transactions, ang TXID at wTXID nito ay parehas, dahil nga sa pagsunod nito sa lumang paraan ng pagkuha ng TXID.
Ano naman ang witness reserved value? Ito ay espasyo ng witness sa input ng coinbase transaction, na maaaring may gamit sa hinaharap. Pero sa ngayon, ito ay 32 bytes na 0 lamang:
0000000000000000000000000000000000000000000000000000000000000000
Balikan natin ang pagtingin sa coinbase transaction, na napag-usapan sa nakaraang post:
Nasa OP_RETURN Output #1 ang wTXID commitment. Susunod sa OP_PUSHBYTES_36 ay:
- aa21a9ed – unang 4 bytes na constant para sa pag-indika na ito ay output na naglalaman ng commitment
- bfe7b90f093df4f15df23a94e4f57a2e135d6f826c96a5b91002656542b45dd3 – 32 bytes na wTXID commitment
Dahil sa mga nabanggit na alituntunin ng SegWit soft fork, nauuna ang pagkuha ng mga transaksyon sa mempool bago gawin ang coinbase transaction, kapag bumubuo ng block ang miner.
Kitakits sa ika-10