<p>Legacy transaction parsers do not consider segwit transactions to be valid. They will fail to parse the transaction when read the marker byte as indicating 0 inputs.</p>
<p>Part of the way that segwit maintains backwards compatibility is that software that is aware of segwit will specifically indicate that they are, and thus such software can also tell if a peer they are communicating with is not segwit aware. Since it is trivial to strip out the segwit data from a segwit transaction so that it can be parsed by legacy parsers, such nodes will do that prior to relaying any blocks and transactions to the non-segwit nodes.</p>

CC BY-SA 4.0
2024-05-05T04:10:38.280Z
2024-05-05T04:10:38.280Z
Ava Chow
<p>Segwit nodes strip Segwit information (marker, flag witness) from transactions before sending them to pre-Segwit nodes. Therefore, pre-Segwit nodes do not see, or need to interpret, the marker/flag. They see stripped confirmed Segwit transactions as &quot;spent anyone can spend&quot; transactions.</p>
<p>If a pre-Segwit node did for some reason receive a Segwit transaction (with marker+flag+witness) it would see it as invalid for the reason you mention. However, a pre-Segwit node could incorporate a &quot;Segwit-stripper&quot; script to remove the marker/flag/witness fields relatively easily.</p>
<p>If the pre-Segwit node wanted to be a block-author for potential new blocks, it would not include the stripped Segwit transactions as it cannot verify them.</p>

CC BY-SA 4.0
2024-05-05T08:00:10.503Z
2024-05-05T13:49:27.830Z
2024-05-05T13:49:27.830Z
Lee
<p>The marker byte is interpreted by a legacy transaction parser as number of inputs in the transaction and is always 0. My question is, why is a transaction with 0 inputs considered valid by a legacy transaction parser?</p>
<p><a href="https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch06_transactions.adoc#extended-marker-and-flag" rel="nofollow noreferrer">Mastering Bitcoin</a> book mentions marker byte interpretation by legacy transaction parser</p>
<blockquote>
<p>In legacy serialization, the marker byte would have been interpreted
as the number of inputs (zero). A transaction can’t have zero inputs,
so the marker signals to modern programs that extended serialization
is being used. The flag field provides a similar signal and also
simplifies the process of updating the serialization format in the
future.</p>
</blockquote>
<p>Also this <a href="https://bitcoin.stackexchange.com/questions/105703/why-does-decoded-block-data-not-match-coinbase-transaction-input/105708#105708">answer by Ava Chow</a> mentions the same:</p>
<blockquote>
<p>Specifically, what you are missing is that the field immediately
following the version number is a single 0 byte (referred to as the
marker byte), instead of the input count. This was done specifically
to make a transaction appear as if it has no inputs to a legacy
transaction parser.</p>
</blockquote>
<p>My understanding is that the minimum number of inputs for a transaction is 1, so why does a legacy transaction parser that sees a transaction with 0 inputs (the marker byte) consider the transaction valid?</p>

CC BY-SA 4.0
2024-05-06T03:39:00.703Z
yes that answered my question thank you!
mon
<segregated-witness>
marker byte interpretation by legacy transaction parser
mon
# marker byte interpretation by legacy transaction parser

(Asked by: username_0 on 2024-05-05)

The marker byte is interpreted by a legacy transaction parser as number of inputs in the transaction and is always 0. My question is, why is a transaction with 0 inputs considered valid by a legacy transaction parser?

[Mastering Bitcoin](https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch06_transactions.adoc#extended-marker-and-flag) book mentions marker byte interpretation by legacy transaction parser

> In legacy serialization, the marker byte would have been interpreted
> as the number of inputs (zero). A transaction can’t have zero inputs,
> so the marker signals to modern programs that extended serialization
> is being used. The flag field provides a similar signal and also
> simplifies the process of updating the serialization format in the
> future.

Also this [answer by username_1](https://bitcoin.stackexchange.com/questions/105703/why-does-decoded-block-data-not-match-coinbase-transaction-input/105708#105708) mentions the same:

> Specifically, what you are missing is that the field immediately
> following the version number is a single 0 byte (referred to as the
> marker byte), instead of the input count. This was done specifically
> to make a transaction appear as if it has no inputs to a legacy
> transaction parser.

My understanding is that the minimum number of inputs for a transaction is 1, so why does a legacy transaction parser that sees a transaction with 0 inputs (the marker byte) consider the transaction valid?

**Tags:** segregated-witness

> **Comments:**
> **username_0**: yes that answered my question thank you!  

---

## 2 answers

### Answer by username_1 on 2024-05-05. Score: 2 | Accepted answer

Legacy transaction parsers do not consider segwit transactions to be valid. They will fail to parse the transaction when read the marker byte as indicating 0 inputs.

Part of the way that segwit maintains backwards compatibility is that software that is aware of segwit will specifically indicate that they are, and thus such software can also tell if a peer they are communicating with is not segwit aware. Since it is trivial to strip out the segwit data from a segwit transaction so that it can be parsed by legacy parsers, such nodes will do that prior to relaying any blocks and transactions to the non-segwit nodes.


---

### Answer by username_2 on 2024-05-05. Score: 1

Segwit nodes strip Segwit information (marker, flag witness) from transactions before sending them to pre-Segwit nodes. Therefore, pre-Segwit nodes do not see, or need to interpret, the marker/flag. They see stripped confirmed Segwit transactions as "spent anyone can spend" transactions.

If a pre-Segwit node did for some reason receive a Segwit transaction (with marker+flag+witness) it would see it as invalid for the reason you mention. However, a pre-Segwit node could incorporate a "Segwit-stripper" script to remove the marker/flag/witness fields relatively easily.

If the pre-Segwit node wanted to be a block-author for potential new blocks, it would not include the stripped Segwit transactions as it cannot verify them.


---

