0

Reading at the Specification chapter in the BIP-0144 document, there seems to be conflicting statements.

The Description of the marker field in the table says "Must be zero"

Field Size Name Type Description
... ... ... ...
1 marker char Must be zero
... ... ... ...

However, what follows description is:

Rationale for not using just a single 0x00 byte as marker: that would lead to empty transactions (no inputs, no outputs, which are used in some tests) to be interpreted as new serialized data

As I understand it, the marker would need to be 0 for old nodes to treat the transaction as valid. So it looks like the 'not' should be removed from this sentence. Is there something I'm missing?

Would you also point me in the direction of where to look in the Bitcoin Core code?

1 Answer 1

2

the marker would need to be 0 for old nodes to treat the transaction as valid. [...] Is there something I'm missing?

What you may be missing is that old (pre-segwit) nodes never see segwit data, when segwit nodes send data to pre-segwit nodes they edit out all the segwit fields.

Part of the protocol handshake identifies segwit nodes

Consequently the marker is always zero and the only currently defined value for the flag is 1 (as far as I know). When parsing I rely on the marker being zero, to distinguish it from an input count, but I allow for any non zero value of flag.


Rationale for not using just a single 0x00 byte as marker: that would lead to empty transactions (no inputs, no outputs, which are used in some tests) to be interpreted as new serialized data

This says that the 0x00 marker is necessary but is not sufficient to reliably distinguish pre-segwit transaction serialisation from segwit transaction serialisation.

I believe it claims you need the additional flag to distinguish a segwit transaction (with any number of inputs) from a pre-segwit transaction that has no inputs (input count = 0).

I don't think this is actually true for mainnet†. I think there are no transactions using the pre-segwit serialisation that have no inputs. Perhaps it is true for one of the other Bitcoin networks (testnet etc). I wrote a parser that would fail if fed a pre-segwit transaction with no inputs - It hasn't failed but admittedly I haven't tested it against every transaction in the whole mainnet blockchain.


Related


Footnotes

† Minimum number of inputs

  1. https://developer.bitcoin.org/devguide/transactions.html says

    Each transaction has at least one input

  2. How to create a bitcoin transaction without inputs

    Only the coinbase transaction is allowed to have a null, or non-existent input [...] Coinbase transactions have inputs. They just reference null outpoints

3
  • Thank you for your response. I understand why it needs to be 0. The point I'm confused about is the 'not' in the "Rationale for not using just a single 0x00 bytes as marker." As English is not my first language and I'm newbie in Bitcoin dev space, so I'm not sure if I understood correctly. Is it correct that this word 'not' should be deleted? Additionally, can you give me a hint to help me check it in the code? Commented Apr 2, 2023 at 15:25
  • 1
    The "not" applies to the "single" - I'll update my answer to elaborate a bit how I interpret this. Commented Apr 2, 2023 at 15:44
  • 2
    This is correct. Just a zero byte marker would be insufficient, which is why there is a marker plus a flag byte. And @RedGrittyBrick is technically right that 0-input transaction are strictly speaking illegal anyway, however they are (or at least were) common when dealing with incomplete/unsigned transactions that were being passed around before people were done adding inputs/outputs to them. Even though these are never allowed on chain, we needed to be unambiguous w.r.t. those as well. Commented Apr 2, 2023 at 23:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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