<p>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. </p>

CC BY-SA 4.0
2018-12-18T15:33:19.793Z
Thank you! I guess I'm on the right path! YEAH! :)
My Quid Pro Quo
CC BY-SA 4.0
2018-12-18T22:22:43.797Z
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
CC BY-SA 4.0
2018-12-19T00:14:03.947Z
@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.
My Quid Pro Quo
CC BY-SA 4.0
2018-12-18T15:31:14.533Z
2018-12-18T15:39:34.560Z
2018-12-18T15:39:34.560Z
Claris
<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

CC BY-SA 4.0
2018-12-19T11:48:51.240Z
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?
My Quid Pro Quo
CC BY-SA 4.0
2018-12-19T00:23:29.923Z
2018-12-19T00:23:29.923Z
G. Maxwell
<p>I was trying to manually parse a raw Bitcoin transaction in order to better understand how it works.</p>

<p>This is how it starts:
"0200000000010141035625cd030eca667c95d1729a"</p>

<p>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?  </p>

<p>If so in BIP 144:</p>

<blockquote>
  <p>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.</p>
</blockquote>

<p>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?</p>

<p>Sorry for the messy question.</p>

<segregated-witness><bip><soft-fork>
BIP 144 transaction format and soft-forks and old nodes
My Quid Pro Quo
# BIP 144 transaction format and soft-forks and old nodes

(Asked by: username_0 on 2018-12-18)

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.

**Tags:** segregated-witness, bip, soft-fork


---

## 2 answers

### Answer by username_1 on 2018-12-18. Score: 2 | Accepted answer

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.

> **Comments:**
> **username_0**: Thank you! I guess I'm on the right path! YEAH! :)  
> **username_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.  
> **username_0**: @G.username_2 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.  

---

### Answer by username_2 on 2018-12-19. Score: 2

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.

> **Comments:**
> **username_0**: 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?  

---

