I was trying to manually parse a raw Bitcoin transaction in order to better understand how it works.

This is how it starts: "0200000000010141035625cd030eca667c95d1729a"

I think I've parsed the Tx version just fine but then the next byte was 00. I imagine this has something to do with BIP144. Correct?

If so in BIP 144:

Parsers supporting this BIP will be able to distinguish between the old serialization format (without the witness) and this one. The marker byte is set to zero so that this structure will never parse as a valid transaction in a parser that does not support this BIP. If parsing were to succeed, such a transaction would contain no inputs and a single output.

Does this means that old nodes do not relay Segwit transactions? They will think they are invalid? But once they are put in a block it's already in a format that an old-node can understand?

Sorry for the messy question.

2 Answers 2


This is correct. As an upgrade mechanism, nodes do not relay or mine transactions which they know that they can not correctly validate. The P2P network expressly avoids situations in which it could cause invalid transactions to be included in a block. It will however accept these transactions in a block.

  • 2
    Thank you! I guess I'm on the right path! YEAH! :) Dec 18, 2018 at 15:33
  • 2
    This response is correct in what it says but it's a little misleading. The reason old nodes don't accept/relay segwit using txn is unrelated to the format, it's because they violate the cleanstack standardness rule. The reason that they're accepted in a block is because they get a copy of the block recoded into the old format.
    – G. Maxwell
    Dec 18, 2018 at 22:22
  • @G.Maxwell could you elaborate the answer or point me to some more detailed information? Maybe even write your own answer if you feel like it. Thank you very much. Dec 19, 2018 at 0:14

When an old node connects to a new node the new node detects that the old node doesn't support the new transaction format and so it converts any transaction it sends it-- e.g. segwit transactions in blocks-- to the old format. The old format does have the witness data fields in it, but old nodes don't have any requirements for witness data so they don't mind.

The format nodes send transactions to each other is not a property of the Bitcoin consensus... you and I could use a totally different format than some other nodes. No one else would even need to know if we used some other encoding... so long as it didn't prevent us from communicating every valid txn.

New nodes also don't forward segwit using transactions outside of blocks to old nodes at all. They could-- but old nodes would just drop them because they can detect that they're using "future functionality". Nodes don't relay, mine, or show in their wallets transactions that use intentionally backwards compatible extensions because they know they don't know how to adequately validate those rules. This prevents an unupgraded miner, for example, from accidentally mining an invalid transaction that was invalid due to a newly introduced rule. If txn using 'future functionality' show up in blocks they'll happily accept them so long as they're otherwise consistent with all the rules the node knows how to enforce.

There are several kinds of 'future functionality' some examples are NOP opcodes and unprocessed data being left on the script stack. Old nodes see segwit transactions as leaving data on the stack.

  • OK, I think I'll have to give it some more thought before it gets crystal clear. Thank you! Just as a quick question. > so it converts any transaction it sends it-- e.g. segwit transactions in blocks-- to the old format. I was under the impression that the serialized format from getrawtransaction was the same going through the p2p network and getting in the blocks? So that is wrong? Dec 19, 2018 at 11:48

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.