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:
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:
My second question:
- Where does the (concatenated?)
witness reserved valuecome 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.