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 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 Ava Chow 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?

  • yes that answered my question thank you!
    – mon
    Commented May 6 at 3:39

2 Answers 2


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.


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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.