<p>Found it in <a href="https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki" rel="nofollow noreferrer">bip 144</a>:</p>

<blockquote>
  <p><strong>Rationale for the 0x01 flag byte in between</strong>: this will allow us to easily add more extra non-committed data to transactions (like txouts being spent, ...). It can be interpreted as a bitvector.</p>
</blockquote>

<p>So the <code>0x01</code> flag is indicating that the witness data should be included in the (bip144) transaction serialization.</p>

CC BY-SA 4.0
2019-01-28T07:28:03.630Z
I still don't fully understand. The 0x00 marker already prevents parsing by non-witness aware nodes. I suppose the 0x01 flag individual bits can signal inclusion of future data, such as prevouts? So up to 7 additional "data types" which can be included? Also, this data would be non-committed to the merkle root, but committed to the witness root hash, yes?
James C.
CC BY-SA 4.0
2019-01-29T09:44:16.307Z
@James C. All correct. It's intended for future extensibility with other types of witness data. Such new witnesses would need their own new witness commitments in the coinbase as well, as the existing wtxid would not cover them.
Pieter Wuille
CC BY-SA 4.0
2019-01-29T09:49:33.520Z
@PieterWuille Perfect, I will look at how this is parsed again in the implementation, I didn’t think about new “wtxid” being required, but logical, thx!
James C.
CC BY-SA 4.0
2019-01-28T05:35:25.303Z
2019-01-28T05:35:25.303Z
esneider
<p>According to <a href="https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki" rel="nofollow noreferrer">bip 141</a>, the segwit transaction serialization format (used to compute the wtxid) is:</p>

<pre><code>[nVersion][marker][flag][txins][txouts][witness][nLockTime]
</code></pre>

<p>The bip mentions that the <code>flag</code> field MUST currently be <code>0x01</code>. What's the purpose of this field? Is it some kind of upgrading mechanism of the serialization format?</p>

<transactions><segregated-witness><raw-transaction><soft-fork>
What's the segwit transaction serialization "flag" field for?
esneider
# What's the segwit transaction serialization "flag" field for?

(Asked by: username_0 on 2019-01-28)

According to [bip 141](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki), the segwit transaction serialization format (used to compute the wtxid) is:

```
[nVersion][marker][flag][txins][txouts][witness][nLockTime]

```

The bip mentions that the `flag` field MUST currently be `0x01`. What's the purpose of this field? Is it some kind of upgrading mechanism of the serialization format?

**Tags:** transactions, segregated-witness, raw-transaction, soft-fork


---

## 1 answers

### Answer by username_0 on 2019-01-28. Score: 2 | Accepted answer

Found it in [bip 144](https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki):

> **Rationale for the 0x01 flag byte in between**: this will allow us to easily add more extra non-committed data to transactions (like txouts being spent, ...). It can be interpreted as a bitvector.

So the `0x01` flag is indicating that the witness data should be included in the (bip144) transaction serialization.

> **Comments:**
> **username_1**: I still don't fully understand. The 0x00 marker already prevents parsing by non-witness aware nodes. I suppose the 0x01 flag individual bits can signal inclusion of future data, such as prevouts? So up to 7 additional "data types" which can be included? Also, this data would be non-committed to the merkle root, but committed to the witness root hash, yes?  
> **username_2**: @username_1 C. All correct. It's intended for future extensibility with other types of witness data. Such new witnesses would need their own new witness commitments in the coinbase as well, as the existing wtxid would not cover them.  
> **username_1**: @username_2 Perfect, I will look at how this is parsed again in the implementation, I didn’t think about new “wtxid” being required, but logical, thx!  

---

