<p>In Bitcoin Core, as of version 26.0, INV entries of unknown type are ignored and skipped (and optionally <a href="https://github.com/bitcoin/bitcoin/blob/v26.0/src/net_processing.cpp#L3916" rel="nofollow noreferrer">logged</a>, if &quot;net&quot; debugging is on); later entries in the same message are still processed.</p>
<p>On incoming INV messages, <code>MSG_WITNESS_TX</code> is <a href="https://github.com/bitcoin/bitcoin/blob/v26.0/src/protocol.h#L509L517" rel="nofollow noreferrer">treated the same</a> as <code>MSG_TX</code>, and <code>MSG_FILTERED_BLOCK</code>, <code>MSG_CMPCT_BLOCK</code> and <code>MSG_WITNESS_BLOCK</code> are treated the same as <code>MSG_BLOCK</code>.</p>

CC BY-SA 4.0
2023-12-19T00:35:30.457Z
Does it apply to all messages in which the given structure (INV) appears or are there exceptions?
Cosmos
CC BY-SA 4.0
2023-12-19T00:43:24.157Z
I ask because only MSG_TX and MSG_BLOCK should appear in INV messages, but what if MSG_WITNESS_TX or MSG_WITNESS_BLOCK appears. **They are a known type** to the segWit node, but should not appear in the INV message. Are such rows ignored or the message is considered as invalid and rejected?
Cosmos
CC BY-SA 4.0
2023-12-19T01:18:27.680Z
Updated my answer.
Pieter Wuille
CC BY-SA 4.0
2023-12-19T02:00:22.690Z
@MudjaAdjum My answer is specifically about Bitcoin Core 26.0, which does support segwit. "updating to segwit" has no meaning here; you need to talk about specific versions of specific software. There is no guarantee that any other version/implementation behaves similarly.
Pieter Wuille
CC BY-SA 4.0
2023-12-19T02:16:06.523Z
I meant Bitcoin Core. When I wrote "if it was not updated to segWit" I was referring to Bitcoin Core versions before segWit, and their behavior when they received in the INV message, for example, MSG_WITNESS_TX.
Cosmos
CC BY-SA 4.0
2023-12-19T03:38:05.360Z
But even within versions of Bitcoin Core, the situation is more complicated. E.g. (random example) it appears that 0.14.0 would not treat invs with `MSG_CMPCT_BLOCK` like `MSG_BLOCK` while 26.0 does. There are no specifications for how a node behaves when arbitrarily wrong data sent to it, so different pieces of software (even different versions) may behave differently.
Pieter Wuille
CC BY-SA 4.0
2023-12-19T04:25:21.833Z
MSG_WITNESS_TX and MSG_WITNESS_BLOCK were introduced with the SegWit update. Nodes that have not updated to SegWit do not know this INVENTORY type. Since you wrote that if a node receives INV entries of an unknown type, they are skipped, I wanted to add a note that if a non-SegWit node received such an entry in the INV message, it would be just ignored since for that (non-segWit) node MSG_WITNESS_TX is unknown and MSG_WITNESS_TX == MSG_TX is not true.
Cosmos
CC BY-SA 4.0
2023-12-19T08:30:22.450Z
@MudjaAdjum Yes, my point is that you have to be specific about what versions of what software you're talking about. E.g. 0.13.0 also treats MSG_WITNESS_TX as MSG_TX, but didn't have segwit active (that only happened in 0.13.1).
Pieter Wuille
CC BY-SA 4.0
2023-12-19T17:27:45.780Z
You are right. I should have denoted the version I was talking about. My bad
Cosmos
CC BY-SA 4.0
2023-12-19T00:33:29.810Z
2023-12-19T01:15:45.927Z
2023-12-19T01:15:45.927Z
Pieter Wuille
<p>If an INV type unknown to the node appears in an INV message, a GETDATA message or some other message where the INVETORY structure is used (e.g. MSG_WITNESS_TX for non-segWit nodes, MSG_WITNESS_TX in an INV message for segWit/non-segWit node, some random INV type, etc.) , is the whole message then considered invalid or only that &quot;row&quot; in the message is skipped/ignored, while the other rows and the rest of the message are processed?</p>

<p2p>
Does the whole message become invalid when the invalid INV type occurs in the message?
Cosmos
# Does the whole message become invalid when the invalid INV type occurs in the message?

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

If an INV type unknown to the node appears in an INV message, a GETDATA message or some other message where the INVETORY structure is used (e.g. MSG\_WITNESS\_TX for non-segWit nodes, MSG\_WITNESS\_TX in an INV message for segWit/non-segWit node, some random INV type, etc.) , is the whole message then considered invalid or only that "row" in the message is skipped/ignored, while the other rows and the rest of the message are processed?

**Tags:** p2p


---

## 1 answers

### Answer by username_1 on 2023-12-19. Score: 1 | Accepted answer

In Bitcoin Core, as of version 26.0, INV entries of unknown type are ignored and skipped (and optionally [logged](https://github.com/bitcoin/bitcoin/blob/v26.0/src/net_processing.cpp#L3916), if "net" debugging is on); later entries in the same message are still processed.

On incoming INV messages, `MSG_WITNESS_TX` is [treated the same](https://github.com/bitcoin/bitcoin/blob/v26.0/src/protocol.h#L509L517) as `MSG_TX`, and `MSG_FILTERED_BLOCK`, `MSG_CMPCT_BLOCK` and `MSG_WITNESS_BLOCK` are treated the same as `MSG_BLOCK`.

> **Comments:**
> **username_0**: Does it apply to all messages in which the given structure (INV) appears or are there exceptions?  
> **username_0**: I ask because only MSG_TX and MSG_BLOCK should appear in INV messages, but what if MSG_WITNESS_TX or MSG_WITNESS_BLOCK appears. **They are a known type** to the segWit node, but should not appear in the INV message. Are such rows ignored or the message is considered as invalid and rejected?  
> **username_1**: Updated my answer.  
> **username_1**: @MudjaAdjum My answer is specifically about Bitcoin Core 26.0, which does support segwit. "updating to segwit" has no meaning here; you need to talk about specific versions of specific software. There is no guarantee that any other version/implementation behaves similarly.  
> **username_0**: I meant Bitcoin Core. When I wrote "if it was not updated to segWit" I was referring to Bitcoin Core versions before segWit, and their behavior when they received in the INV message, for example, MSG_WITNESS_TX.  
> **username_1**: But even within versions of Bitcoin Core, the situation is more complicated. E.g. (random example) it appears that 0.14.0 would not treat invs with `MSG_CMPCT_BLOCK` like `MSG_BLOCK` while 26.0 does. There are no specifications for how a node behaves when arbitrarily wrong data sent to it, so different pieces of software (even different versions) may behave differently.  
> **username_0**: MSG_WITNESS_TX and MSG_WITNESS_BLOCK were introduced with the SegWit update. Nodes that have not updated to SegWit do not know this INVENTORY type. Since you wrote that if a node receives INV entries of an unknown type, they are skipped, I wanted to add a note that if a non-SegWit node received such an entry in the INV message, it would be just ignored since for that (non-segWit) node MSG_WITNESS_TX is unknown and MSG_WITNESS_TX == MSG_TX is not true.  
> **username_1**: @MudjaAdjum Yes, my point is that you have to be specific about what versions of what software you're talking about. E.g. 0.13.0 also treats MSG_WITNESS_TX as MSG_TX, but didn't have segwit active (that only happened in 0.13.1).  
> **username_0**: You are right. I should have denoted the version I was talking about. My bad  

---

