<blockquote>
  <p>How are transactions that do not have witness data effected in the
  witness hash? Are they entirely omitted?</p>
</blockquote>

<p>It will still include transactions that are not witness, it will just compute the normal hash to use as a leaf in the tree. See <code>BlockWitnessMerkleRoot()</code> in <a href="https://github.com/bitcoin/bitcoin/blob/v0.17.0/src/consensus/merkle.cpp#L76" rel="nofollow noreferrer"><code>src/consensus/merkle.cpp</code></a> and <code>ComputeWitnessHash()</code> in <a href="https://github.com/bitcoin/bitcoin/blob/v0.17.0/src/primitives/transaction.cpp#L70" rel="nofollow noreferrer"><code>src/primitives/transaction.cpp</code></a>:</p>

<pre><code>uint256 CTransaction::ComputeWitnessHash() const
{
    if (!HasWitness()) {
        return hash;
    }
    return SerializeHash(*this, SER_GETHASH, 0);
}
</code></pre>

<p>Also, you are forgetting to reverse endianess, and hash the witness reserved value <code>0000000000000000000000000000000000000000000000000000000000000000</code> (from the last 32 bytes of the coinbase input witness). So step by step:</p>

<pre><code>$ reverse_endian 66beaceb4be99da1e9824448231ab4fd37bacaee912381e779b37cf0e1dadad7
d7dadae1f07cb379e7812391eecaba37fdb41a23484482e9a19de94bebacbe66

$ reverse_endian aecb37e25954e15489e25548eb663ffdfd8a1362cac757ad62e9614453d2a577
77a5d2534461e962ad57c7ca62138afdfd3f66eb4855e28954e15459e237cbae

$ reverse_endian 5b211bc589cbdf5ad86cab1e2fe91f01c8ab934d21536b35864d30a3ff778456
568477ffa3304d86356b53214d93abc8011fe92f1eab6cd85adfcb89c51b215b

$ hash256 0000000000000000000000000000000000000000000000000000000000000000d7dadae1f07cb379e7812391eecaba37fdb41a23484482e9a19de94bebacbe66
d822d7717f284b89ea6a97874af567e9887a26a9f7db449ce02377d8fae4643f

$ hash256 77a5d2534461e962ad57c7ca62138afdfd3f66eb4855e28954e15459e237cbae568477ffa3304d86356b53214d93abc8011fe92f1eab6cd85adfcb89c51b215b
c182a158773ea7fc7a252fa725fc726de2a171088b40528ca00de0569fe53afe

$ hash256 d822d7717f284b89ea6a97874af567e9887a26a9f7db449ce02377d8fae4643fc182a158773ea7fc7a252fa725fc726de2a171088b40528ca00de0569fe53afe
30d002641e0eb81b11c3d14f4b120e80b4c06bcb3d34d90a5a606ca85e90c841

$ hash256 30d002641e0eb81b11c3d14f4b120e80b4c06bcb3d34d90a5a606ca85e90c8410000000000000000000000000000000000000000000000000000000000000000
4a657fcaa2149342376247e2e283a55a6b92dcc35d4d89e4ac7b74488cb63be2
</code></pre>

<p>Which matches the op_return data in the second coinbase output: <code>RETURN PUSHDATA(36)[&lt;aa21a9ed&gt; &lt;4a657fcaa2149342376247e2e283a55a6b92dcc35d4d89e4ac7b74488cb63be2&gt;]</code></p>

<blockquote>
  <p>Where does the (concatenated?) witness reserved value come from?</p>
</blockquote>

<p>I alluded to this before, but it is in the witness field of the coinbase input:</p>

<blockquote>
  <p>the coinbase's input's witness must consist of a single 32-byte array
  for the witness reserved value - <a href="https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#commitment-structure" rel="nofollow noreferrer">BIP 141</a></p>
</blockquote>

CC BY-SA 4.0
2020-10-29T00:14:42.687Z
so, is the commitment header random? "aa21a9ed" doesnt decode to anything meaningful in ascii, but Bitcoin headers usually do.
Sachin Meier
CC BY-SA 4.0
2020-12-18T16:11:56.857Z
@Pillagr As the BIP 141 states, the commitment header is fixed.
lk_vc
CC BY-SA 4.0
2018-10-02T14:10:07.400Z
2018-10-02T14:24:02.490Z
2018-10-02T14:24:02.490Z
JBaczuk
<p>From my understanding, every SegWit enabled block has an added output script which is used as a place to store the &quot;Witness commitment&quot; specified in <a href="https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#commitment-structure" rel="nofollow noreferrer">BIP 141</a>.</p>
<p>One issue I've stumbled upon was calculating the <code>commitment hash</code> value only given the raw block/transaction data.</p>
<p>For example, I've chosen <a href="https://www.blockchain.com/btc/block/000000000000000000143a2c56c0214236dadfd30df41d4a0345492ad6d861ec" rel="nofollow noreferrer">Block #542213</a> as it only has 4 total transactions (including the coinbase generation)</p>
<p>Coinbase witness commitment script:</p>
<pre><code>OP_RETURN OP_PUSHDATA(36) [aa21a9ed4a657fcaa2149342376247e2e283a55a6b92dcc35d4d89e4ac7b74488cb63be2]
</code></pre>
<p>BIP141 states that the pushed data can be broken down to the following:</p>
<pre><code>0xaa21a9ed - Commitment header (seemingly random)
0x4a657fcaa2149342376247e2e283a55a6b92dcc35d4d89e4ac7b74488cb63be2 - SHA256(SHA256(witness root hash|witness reserved value))
</code></pre>
<p>The documentation mentions that the <code>witness root hash</code> can be derived similarly to the merkle root in a block header, where each <code>wtxid</code> acts as the <code>txid</code> would in a traditional header merkle root.</p>
<p>To test this, I'm using <a href="https://bitcoin.stackexchange.com/questions/43565/how-can-i-make-this-php-merkle-root-script-recursive/43575#43575">this PHP script</a> 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).</p>
<p>Our example block has 4 transactions. Only two of which have witness data (<a href="https://www.blockchain.com/btc/tx/c399a9d747a422c9fc9261934f96c406cec3ca136280812f8abb8a3b9fdd868d" rel="nofollow noreferrer">coinbase</a> and <a href="https://www.blockchain.com/btc/tx/6c6e3849acf1b570db352dc08f7776e99c344a56fbb2f019e1865d1b6e044889" rel="nofollow noreferrer">this tx</a>).
The commitment structure states that the <code>wtxid</code> of the coinbase transaction is always:</p>
<pre><code>0x0000000000000000000000000000000000000000000000000000000000000000
</code></pre>
<p>and every other <code>wtxid</code> act as a leaf.</p>
<h2>My first question:</h2>
<ul>
<li>How are transactions that do not have witness data effected in the witness hash? Are they entirely omitted?</li>
</ul>
<p>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  <code>wtxid</code> into the array like so:</p>
<pre><code>$txids = array(
    '0000000000000000000000000000000000000000000000000000000000000000',
    '6c6e3849acf1b570db352dc08f7776e99c344a56fbb2f019e1865d1b6e044889',
);
</code></pre>
<p>The result being: <code>3a84e2f2f1bcd42141b58f2acd9497296c9f2d710cc2164669ef6d7e3870dfe9</code></p>
<h2>My second question:</h2>
<ul>
<li>Where does the (concatenated?) <code>witness reserved value</code> come from?</li>
</ul>
<p><a href="https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#extensible-commitment-structure" rel="nofollow noreferrer">Here</a> it states:</p>
<blockquote>
<p>The witness reserved value currently has no consensus meaning, but in the future allows new commitment values for future softforks</p>
</blockquote>
<p>But it is still unclear to me what this value <em>actually is</em> before the hash is computed.</p>
<p>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.</p>

<segregated-witness><merkle-tree><witness-commitment>
How do I calculate the witness commitment hash for a given block?
Mason Ticehurst
# How do I calculate the witness commitment hash for a given block?

(Asked by: username_0 on 2018-10-02)

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](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#commitment-structure).

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](https://www.blockchain.com/btc/block/000000000000000000143a2c56c0214236dadfd30df41d4a0345492ad6d861ec) 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](https://bitcoin.stackexchange.com/questions/43565/how-can-i-make-this-php-merkle-root-script-recursive/43575#43575) 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](https://www.blockchain.com/btc/tx/c399a9d747a422c9fc9261934f96c406cec3ca136280812f8abb8a3b9fdd868d) and [this tx](https://www.blockchain.com/btc/tx/6c6e3849acf1b570db352dc08f7776e99c344a56fbb2f019e1865d1b6e044889)).
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](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#extensible-commitment-structure) 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.

**Tags:** segregated-witness, merkle-tree, witness-commitment


---

## 1 answers

### Answer by username_1 on 2018-10-02. Score: 2 | Accepted answer

> How are transactions that do not have witness data effected in the
> witness hash? Are they entirely omitted?

It will still include transactions that are not witness, it will just compute the normal hash to use as a leaf in the tree. See `BlockWitnessMerkleRoot()` in [`src/consensus/merkle.cpp`](https://github.com/bitcoin/bitcoin/blob/v0.17.0/src/consensus/merkle.cpp#L76) and `ComputeWitnessHash()` in [`src/primitives/transaction.cpp`](https://github.com/bitcoin/bitcoin/blob/v0.17.0/src/primitives/transaction.cpp#L70):

```
uint256 CTransaction::ComputeWitnessHash() const
{
    if (!HasWitness()) {
        return hash;
    }
    return SerializeHash(*this, SER_GETHASH, 0);
}

```

Also, you are forgetting to reverse endianess, and hash the witness reserved value `0000000000000000000000000000000000000000000000000000000000000000` (from the last 32 bytes of the coinbase input witness). So step by step:

```
$ reverse_endian 66beaceb4be99da1e9824448231ab4fd37bacaee912381e779b37cf0e1dadad7
d7dadae1f07cb379e7812391eecaba37fdb41a23484482e9a19de94bebacbe66

$ reverse_endian aecb37e25954e15489e25548eb663ffdfd8a1362cac757ad62e9614453d2a577
77a5d2534461e962ad57c7ca62138afdfd3f66eb4855e28954e15459e237cbae

$ reverse_endian 5b211bc589cbdf5ad86cab1e2fe91f01c8ab934d21536b35864d30a3ff778456
568477ffa3304d86356b53214d93abc8011fe92f1eab6cd85adfcb89c51b215b

$ hash256 0000000000000000000000000000000000000000000000000000000000000000d7dadae1f07cb379e7812391eecaba37fdb41a23484482e9a19de94bebacbe66
d822d7717f284b89ea6a97874af567e9887a26a9f7db449ce02377d8fae4643f

$ hash256 77a5d2534461e962ad57c7ca62138afdfd3f66eb4855e28954e15459e237cbae568477ffa3304d86356b53214d93abc8011fe92f1eab6cd85adfcb89c51b215b
c182a158773ea7fc7a252fa725fc726de2a171088b40528ca00de0569fe53afe

$ hash256 d822d7717f284b89ea6a97874af567e9887a26a9f7db449ce02377d8fae4643fc182a158773ea7fc7a252fa725fc726de2a171088b40528ca00de0569fe53afe
30d002641e0eb81b11c3d14f4b120e80b4c06bcb3d34d90a5a606ca85e90c841

$ hash256 30d002641e0eb81b11c3d14f4b120e80b4c06bcb3d34d90a5a606ca85e90c8410000000000000000000000000000000000000000000000000000000000000000
4a657fcaa2149342376247e2e283a55a6b92dcc35d4d89e4ac7b74488cb63be2

```

Which matches the op\_return data in the second coinbase output: `RETURN PUSHDATA(36)[<aa21a9ed> <4a657fcaa2149342376247e2e283a55a6b92dcc35d4d89e4ac7b74488cb63be2>]`

> Where does the (concatenated?) witness reserved value come from?

I alluded to this before, but it is in the witness field of the coinbase input:

> the coinbase's input's witness must consist of a single 32-byte array
> for the witness reserved value - [BIP 141](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#commitment-structure)

> **Comments:**
> **username_2**: so, is the commitment header random? "aa21a9ed" doesnt decode to anything meaningful in ascii, but Bitcoin headers usually do.  
> **username_3**: @Pillagr As the BIP 141 states, the commitment header is fixed.  

---

