From my understanding, every SegWit enabled block has an added output script which is used as a place to store the "Witness commitment" specified in BIP 141.
One issue I've stumbled upon was calculating the commitment hash
value only given the raw block/transaction data.
For example, I've chosen Block #542213 as it only has 4 total transactions (including the coinbase generation)
Coinbase witness commitment script:
OP_RETURN OP_PUSHDATA(36) [aa21a9ed4a657fcaa2149342376247e2e283a55a6b92dcc35d4d89e4ac7b74488cb63be2]
BIP141 states that the pushed data can be broken down to the following:
0xaa21a9ed - Commitment header (seemingly random)
0x4a657fcaa2149342376247e2e283a55a6b92dcc35d4d89e4ac7b74488cb63be2 - SHA256(SHA256(witness root hash|witness reserved value))
The documentation mentions that the witness root hash
can be derived similarly to the merkle root in a block header, where each wtxid
acts as the txid
would in a traditional header merkle root.
To test this, I'm using this PHP script kindly provided on a different thread. This generates the merkle root used in the block header perfectly (that is not what I am trying to do, but what I have done to verify the code actually works).
Our example block has 4 transactions. Only two of which have witness data (coinbase and this tx).
The commitment structure states that the wtxid
of the coinbase transaction is always:
0x0000000000000000000000000000000000000000000000000000000000000000
and every other wtxid
act as a leaf.
My first question:
- How are transactions that do not have witness data effected in the witness hash? Are they entirely omitted?
Assuming that the non-witness transactions are just omitted entirely from the merkle tree, I simply add the coinbase and the one transaction with witness data's wtxid
into the array like so:
$txids = array(
'0000000000000000000000000000000000000000000000000000000000000000',
'6c6e3849acf1b570db352dc08f7776e99c344a56fbb2f019e1865d1b6e044889',
);
The result being: 3a84e2f2f1bcd42141b58f2acd9497296c9f2d710cc2164669ef6d7e3870dfe9
My second question:
- Where does the (concatenated?)
witness reserved value
come from?
Here it states:
The witness reserved value currently has no consensus meaning, but in the future allows new commitment values for future softforks
But it is still unclear to me what this value actually is before the hash is computed.
Please feel free to correct any inconsistencies or problems with my train of thought so I can improve my understanding for this part of segregated witness.