<p><strong>sendcmpct(0)</strong> simply informs the peer that compact block support is available. Without it, the peer wouldn't know that MSG_CMPCT_BLOCK is supported by us.</p>
<p>So:</p>
<ul>
<li><strong>sendcmpct(0)</strong> means &quot;You can ask me for compact blocks&quot;.</li>
<li><strong>sendcmpct(1)</strong> means &quot;You can ask me for compact blocks, and also please send them to me without me asking&quot;</li>
</ul>

CC BY-SA 4.0
2023-12-23T18:43:29.570Z
But if I send MSG_CMPCT_BLOCK in *getdata* message it means that I am supporting it (since I am requesting it). If I am not supporting it, I would not send *getdata* with that type, but with MSG_BLOCK or MSG_WITNESS_BLOCK. And peer would have known if it was supported based on the version when establishing the connection. If the version is greater than or equal to 70014, it means that we support it
Cosmos
CC BY-SA 4.0
2023-12-23T19:12:54.993Z
No, `sendcmpct` is how you let your peer know that you support compact blocks. Protocol version 70014 simply means the `sendcmpct` command exists, not that compact blocks are actually supported. BIP152 states you're not allowed to use MSG_WITNESS_BLOCK or any of the other compact-block related messages unless you've received a `sendcmpct` message.
Pieter Wuille
CC BY-SA 4.0
2023-12-23T21:14:22.823Z
I thought that the version messages that are exchanged when establishing a connection between two nodes and the version field within them indicate what each node supports. I do not understand this: "Protocol version 70014 simply means the `sendcmpct` command exists, not that compact blocks are actually supported.". If the command exists, then compact blocks are supported?
Cosmos
CC BY-SA 4.0
2023-12-23T21:27:12.547Z
No, if you set the protocol version to 70014, it means your software should not misbehave when it receives a `sendcmpct` message. You can support 70014 by just ignoring `sendcmpct`, and not otherwise implementing compact blocks.
Pieter Wuille
CC BY-SA 4.0
2023-12-23T21:36:51.927Z
Unfortunately, I don't understand the purpose of exchanging the protocol version then. The 70014 protocol version includes support for BIP152 and you say that my software should not misbehave if it receives `sendcmpct` message (**I agree with that**), but that I can support the 70014 protocol version as well by ignoring `sendcmpct` and not implementing BIP152 (**???**)? This is contradictory to me. I don't understand what does it mean? To implement other futures related to 70014?
Cosmos
CC BY-SA 4.0
2023-12-23T21:44:48.357Z
70014 does not require you to support compact blocks. It just enables the negotiation thereof. To take an example, BIP339; it adds a feature called wtxid-based relay, in protocol 70016 or higher. It would be unacceptable if any node that wishes to support wtxid-based relay also was forced to implement compact blocks, just because there is no way to signal support for wtxidrelay without supporting compact blocks. Therefore, the protocol version number just controls which messages can be sent, but not actual feature support. That's negotiated using feature-specific messages like `sendcmpct`.
Pieter Wuille
CC BY-SA 4.0
2023-12-23T21:54:15.127Z
Ah, I think I understand now. So the version number only means that some future version "maybe" is supported by me/my peer (in sense that we can negotiate about it), but it does not necessarily mean that it is actually supported. We can establish whether something is really supported through negotiations, for example, through additional messages (eg sendcmpct) or through service flags or something else. If the version is smaller, then we don't have anything to negotiate, since that future was introduced only in the next (future) versions, which I/my peer don't even support. That's the point?
Cosmos
CC BY-SA 4.0
2023-12-23T18:40:14.797Z
2023-12-23T19:35:48.597Z
2023-12-23T19:35:48.597Z
Pieter Wuille
<p>BIP152 explains two types of block announcing:</p>
<ul>
<li>High Bandwidth Relaying (<strong>sendcmpct(1)</strong>)</li>
<li>Low Bandwidth Relaying (<strong>sendcmpct(0)</strong>)</li>
</ul>
<p>I understand why we need <em>sendcmpct</em> message for the first case. In this way, we inform the peer that we want it to notify us by sending us a compact block. Similar to when we send a <em>sendheaders</em> message indicating that we want announcing via the header, not the inv.</p>
<p>I don't understand why the <em>sendcmpct</em> message is needed for the second case. In second case, notifying is done via header/inv, and then if we want a compact block, we need to send <em>getdata(MSG_CMPCT_BLOCK)</em>. If we don't want to, we send MSG_BLOCK or MSG_WITNESS_BLOCK. Therefore, everything would work the same if we previously didn't send a <em>sendcmpct</em> message first.</p>

<p2p><message>
Why do we need sendcmpct for getdata(CMPCT) - Low Bandwidth Relaying?
Cosmos
# Why do we need sendcmpct for getdata(CMPCT) - Low Bandwidth Relaying?

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

BIP152 explains two types of block announcing:

* High Bandwidth Relaying (**sendcmpct(1)**)
* Low Bandwidth Relaying (**sendcmpct(0)**)

I understand why we need *sendcmpct* message for the first case. In this way, we inform the peer that we want it to notify us by sending us a compact block. Similar to when we send a *sendheaders* message indicating that we want announcing via the header, not the inv.

I don't understand why the *sendcmpct* message is needed for the second case. In second case, notifying is done via header/inv, and then if we want a compact block, we need to send *getdata(MSG\_CMPCT\_BLOCK)*. If we don't want to, we send MSG\_BLOCK or MSG\_WITNESS\_BLOCK. Therefore, everything would work the same if we previously didn't send a *sendcmpct* message first.

**Tags:** p2p, message


---

## 1 answers

### Answer by username_1 on 2023-12-23. Score: 4 | Accepted answer

**sendcmpct(0)** simply informs the peer that compact block support is available. Without it, the peer wouldn't know that MSG\_CMPCT\_BLOCK is supported by us.

So:

* **sendcmpct(0)** means "You can ask me for compact blocks".
* **sendcmpct(1)** means "You can ask me for compact blocks, and also please send them to me without me asking"

> **Comments:**
> **username_0**: But if I send MSG_CMPCT_BLOCK in *getdata* message it means that I am supporting it (since I am requesting it). If I am not supporting it, I would not send *getdata* with that type, but with MSG_BLOCK or MSG_WITNESS_BLOCK. And peer would have known if it was supported based on the version when establishing the connection. If the version is greater than or equal to 70014, it means that we support it  
> **username_1**: No, `sendcmpct` is how you let your peer know that you support compact blocks. Protocol version 70014 simply means the `sendcmpct` command exists, not that compact blocks are actually supported. BIP152 states you're not allowed to use MSG_WITNESS_BLOCK or any of the other compact-block related messages unless you've received a `sendcmpct` message.  
> **username_0**: I thought that the version messages that are exchanged when establishing a connection between two nodes and the version field within them indicate what each node supports. I do not understand this: "Protocol version 70014 simply means the `sendcmpct` command exists, not that compact blocks are actually supported.". If the command exists, then compact blocks are supported?  
> **username_1**: No, if you set the protocol version to 70014, it means your software should not misbehave when it receives a `sendcmpct` message. You can support 70014 by just ignoring `sendcmpct`, and not otherwise implementing compact blocks.  
> **username_0**: Unfortunately, I don't understand the purpose of exchanging the protocol version then. The 70014 protocol version includes support for BIP152 and you say that my software should not misbehave if it receives `sendcmpct` message (**I agree with that**), but that I can support the 70014 protocol version as well by ignoring `sendcmpct` and not implementing BIP152 (**???**)? This is contradictory to me. I don't understand what does it mean? To implement other futures related to 70014?  
> **username_1**: 70014 does not require you to support compact blocks. It just enables the negotiation thereof. To take an example, BIP339; it adds a feature called wtxid-based relay, in protocol 70016 or higher. It would be unacceptable if any node that wishes to support wtxid-based relay also was forced to implement compact blocks, just because there is no way to signal support for wtxidrelay without supporting compact blocks. Therefore, the protocol version number just controls which messages can be sent, but not actual feature support. That's negotiated using feature-specific messages like `sendcmpct`.  
> **username_0**: Ah, I think I understand now. So the version number only means that some future version "maybe" is supported by me/my peer (in sense that we can negotiate about it), but it does not necessarily mean that it is actually supported. We can establish whether something is really supported through negotiations, for example, through additional messages (eg sendcmpct) or through service flags or something else. If the version is smaller, then we don't have anything to negotiate, since that future was introduced only in the next (future) versions, which I/my peer don't even support. That's the point?  

---

