<p>That would be a violation of BIP144.</p>
<p>Support for segwit is signalled by having NODE_WITNESS in the services advertized in the version packet. If a peer does not signal NODE_WITNESS, it cannot be sent MSG_WITNESS_TX or MSG_BLOCK_TX invs.</p>
<p>Nodes are not required to understand these inv types if they don't signal support for segwit. For example, Bitcoin Core 0.12.x (and probably many versions before it) would just ignore such invs.</p>

CC BY-SA 4.0
2023-12-18T22:20:25.193Z
Is the checking of inv types generally in Bitcoin core at the bit level (like checking flags, e.g. services advertized) or is the entire value checked as a single (e.g. whether is it or not  0x40000001-1073741825 for MSG_WITNESS_TX)?
Cosmos
CC BY-SA 4.0
2023-12-18T22:29:32.343Z
The implementation checks the entire value
Pieter Wuille
CC BY-SA 4.0
2023-12-18T20:03:50.703Z
2023-12-18T20:13:30.017Z
2023-12-18T20:13:30.017Z
Pieter Wuille
<p>Unknown services flag are ignored by node that don't know them, but what about GETDATA messages and identifiers?</p>
<p>For services flag, if node is not updated e.g to segWit, it will just not check (1&lt;&lt;3) bit in services field.</p>
<p>What happens if non-segWit node gets MSG_WITNESS_TX as one of the identifier in GETDATA message? MSG_WITNESS_TX is same as MSG_TX but with (1&lt;&lt;30) bit set. <strong>Are these identifiers and their bits treated as flags (like services flag -&gt; bits are checked), so non-segWit node won't even check (1&lt;&lt;30) bit and will send back TX message or they are treated as values, so it will understand MSG_WITNESS_TX as an wrong value and reject the message?</strong></p>
<p>Same for MSG_WITNESS_BLOCK.</p>

<segregated-witness><p2p>
What happens when we send MSG_WITNESS_TX/MSG_WITNESS_BLOCK to non-segWit node?
Cosmos
# What happens when we send MSG_WITNESS_TX/MSG_WITNESS_BLOCK to non-segWit node?

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

Unknown services flag are ignored by node that don't know them, but what about GETDATA messages and identifiers?

For services flag, if node is not updated e.g to segWit, it will just not check (1<<3) bit in services field.

What happens if non-segWit node gets MSG\_WITNESS\_TX as one of the identifier in GETDATA message? MSG\_WITNESS\_TX is same as MSG\_TX but with (1<<30) bit set. **Are these identifiers and their bits treated as flags (like services flag -> bits are checked), so non-segWit node won't even check (1<<30) bit and will send back TX message or they are treated as values, so it will understand MSG\_WITNESS\_TX as an wrong value and reject the message?**

Same for MSG\_WITNESS\_BLOCK.

**Tags:** segregated-witness, p2p


---

## 1 answers

### Answer by username_1 on 2023-12-18. Score: 3 | Accepted answer

That would be a violation of BIP144.

Support for segwit is signalled by having NODE\_WITNESS in the services advertized in the version packet. If a peer does not signal NODE\_WITNESS, it cannot be sent MSG\_WITNESS\_TX or MSG\_BLOCK\_TX invs.

Nodes are not required to understand these inv types if they don't signal support for segwit. For example, Bitcoin Core 0.12.x (and probably many versions before it) would just ignore such invs.

> **Comments:**
> **username_0**: Is the checking of inv types generally in Bitcoin core at the bit level (like checking flags, e.g. services advertized) or is the entire value checked as a single (e.g. whether is it or not  0x40000001-1073741825 for MSG_WITNESS_TX)?  
> **username_1**: The implementation checks the entire value  

---

