<p>Most features are actually initiated by the receiver, in which case all feature negotiation does is <em>permit</em> (but not force) the other side to use a particular feature:</p>
<ul>
<li><a href="https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki" rel="nofollow noreferrer">BIP144</a> (&quot;Segregated Witness (Peer Services)&quot;) lets a node announce support for segwit serialized transactions/blocks using the <code>NODE_WITNESS</code> service flag. All this means is that the other side allowed (but not forced) to request blocks and transactions including witness data. It would be bizarre - but not impossible - to permit the other side to request witness data from you, but never ask for witness data yourself.</li>
<li><a href="https://%20%20%5B1%5D:%20https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki" rel="nofollow noreferrer">BIP152</a> (&quot;compact blocks&quot;) are negotiated using <code>sendcmpct</code>. Ignoring high-bandwidth mode, <code>sendcmpct</code> allows (but does not force) the other side to request BIP152-encoded blocks. It is perfectly possible to announce BIP152 support, but then never request compact blocks. The high bandwidth mode is a feature on top, which is effectively equivalent to a blanket &quot;auto-request compact blocks&quot; for future announced blocks until further notice.</li>
<li><a href="https://%20%20%5B1%5D:%20https://github.com/bitcoin/bips/blob/master/bip-0111.mediawiki" rel="nofollow noreferrer">BIP111</a> (&quot;NODE_BLOOM service bit&quot;) instructs nodes that support BIP37 <a href="https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki" rel="nofollow noreferrer">bloom filters</a> to set that service flag. All this means is that the other side is permitted, but not required, to use BIP37 filtering features. One can announce <code>NODE_BLOOM</code> without ever using the other side's filtering features (in fact, this is the case for Bitcoin Core today running with the <code>-peerbloomfilters</code> option).</li>
<li><a href="https://github.com/bitcoin/bips/blob/master/bip-0133.mediawiki" rel="nofollow noreferrer">BIP133</a> (&quot;feefilter message&quot;) adds an optional <code>feefilter</code> message a node can send to inform the other side it is not interested in transactions with a feerate below a certain value. There is no negotiation for it, and the message is available whenever both sides indicate protocol version 70013 or higher. There is no problem with honoring incoming <code>feefilter</code> messages without ever sending them.</li>
<li><a href="https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki" rel="nofollow noreferrer">BIP157</a> (&quot;Client Side Block Filtering&quot;), like BIP111, permits but does not force a node to announce support for the filtering feature. One can support BIP157 but never use the other side's filtering feature (or care about it being offered).</li>
</ul>
<p>In some case the feature is sender-initiated, but can still be negotiated separately in both directions:</p>
<ul>
<li><a href="https://github.com/bitcoin/bips/blob/master/bip-0155.mediawiki" rel="nofollow noreferrer">BIP155</a> (&quot;addrv2&quot;) is negotiated using a <code>sendaddrv2</code> message, which permits (but does not force) the other side to send <code>addrv2</code> messages instead of <code>addr</code> messages. From my reading, it is not an error to not send <code>sendaddrv2</code> yourself, but still honor one received from the other side.</li>
<li><a href="https://github.com/bitcoin/bips/blob/master/bip-0130.mediawiki" rel="nofollow noreferrer">BIP130</a> (&quot;sendheaders message&quot;) lets a node tell its peers that they can (but are not forced to) announce new blocks using <code>headers</code> rather than using <code>inv</code>. It is possible to not send <code>sendheaders</code> but still honor requests from others to receive block announcements using <code>headers</code>.</li>
</ul>
<p>So I think your observation is rather the exception than the norm. There are a few features which are all-or-nothing, in that they only work if supported by both peers, which then force different behavior on both:</p>
<ul>
<li><a href="https://github.com/bitcoin/bips/blob/master/bip-0330.mediawiki" rel="nofollow noreferrer">BIP330</a> (&quot;Transaction announcement reconciliation&quot;, the protocol change side of Erlay) is negotiated using <code>sendtxrcncl</code>, and only takes effect when both sides support it. In this case this is a hard requirement for the protocol as it is fundamentally bidirectional: instead of announce-&gt;request, both sides build sets of to-be-announced transactions, and then they run a set reconciliation protocol between those sets. This simply makes no sense unless both sides opt into it.</li>
<li><a href="https://github.com/bitcoin/bips/blob/master/bip-0324.mediawiki" rel="nofollow noreferrer">BIP324</a> (&quot;Version 2 P2P Encrypted Transport Protocol&quot;) fundamentally changes the protocol itself spoken between peers. It is announced using a service flag (prior to connection), but the connection attempt itself is already distinct. Earlier iterations of this idea involved starting the protocol normally, and then negotiating an upgrade, but this interfered with an important privacy design goal of the protocol. The only option is having the protocol be encrypted from the very beginning, though old peers can be detected and supported by reconnecting with the old protocol.</li>
<li><a href="https://github.com/bitcoin/bips/blob/master/bip-0339.mediawiki" rel="nofollow noreferrer">BIP339</a> (&quot;WTXID-based relay&quot;) is negotiated using a <code>wtxidrelay</code> message sent in both directions. When that succeeds, both sides must announce transactions using wtxids instead of txids (but may still request using txids).</li>
</ul>
<p>More fundamentally, the purpose of feature negotiation (rather than mandatory upgrades) is allowing client software to opt into what features they want to support individually. I don't think there is much point in adding protocol complexity to cater to the specific use case of only supporting a feature in one direction. If an implementation already bears the complexity cost of implementing the feature, why wouldn't they want to use it?</p>

CC BY-SA 4.0
2024-01-05T16:07:07.137Z
2024-01-05T16:32:53.390Z
2024-01-05T16:32:53.390Z
Pieter Wuille
<p>Why are there no responses to signaling messages (sendcmpct, sendheaders, wtxidrelay) that would indicate I offer a certain feature but do not want it applied to me?</p>
<p>What if I don't want messages to be sent to me using wtxid (only txid), but I have no problem sending wtxid to those who have sent me the wtxidrelay signal? If other node exclusively wants to communicate with nodes that will send wtxid, it will immediately reject me as unsuitable. The only signaling message that has this capability is <code>sendcmpct</code> (not sending it = not supporting cmpct, 0 = you will send but don't want to receive, 1 = you want both).</p>

<p2p>
Why are there no responses to signaling messages?
Cosmos
# Why are there no responses to signaling messages?

(Asked by: username_0 on 2024-01-04)

Why are there no responses to signaling messages (sendcmpct, sendheaders, wtxidrelay) that would indicate I offer a certain feature but do not want it applied to me?

What if I don't want messages to be sent to me using wtxid (only txid), but I have no problem sending wtxid to those who have sent me the wtxidrelay signal? If other node exclusively wants to communicate with nodes that will send wtxid, it will immediately reject me as unsuitable. The only signaling message that has this capability is `sendcmpct` (not sending it = not supporting cmpct, 0 = you will send but don't want to receive, 1 = you want both).

**Tags:** p2p


---

## 1 answers

### Answer by username_1 on 2024-01-05. Score: 4 | Accepted answer

Most features are actually initiated by the receiver, in which case all feature negotiation does is *permit* (but not force) the other side to use a particular feature:

* [BIP144](https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki) ("Segregated Witness (Peer Services)") lets a node announce support for segwit serialized transactions/blocks using the `NODE_WITNESS` service flag. All this means is that the other side allowed (but not forced) to request blocks and transactions including witness data. It would be bizarre - but not impossible - to permit the other side to request witness data from you, but never ask for witness data yourself.
* [BIP152](https://%20%20%5B1%5D:%20https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki) ("compact blocks") are negotiated using `sendcmpct`. Ignoring high-bandwidth mode, `sendcmpct` allows (but does not force) the other side to request BIP152-encoded blocks. It is perfectly possible to announce BIP152 support, but then never request compact blocks. The high bandwidth mode is a feature on top, which is effectively equivalent to a blanket "auto-request compact blocks" for future announced blocks until further notice.
* [BIP111](https://%20%20%5B1%5D:%20https://github.com/bitcoin/bips/blob/master/bip-0111.mediawiki) ("NODE\_BLOOM service bit") instructs nodes that support BIP37 [bloom filters](https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki) to set that service flag. All this means is that the other side is permitted, but not required, to use BIP37 filtering features. One can announce `NODE_BLOOM` without ever using the other side's filtering features (in fact, this is the case for Bitcoin Core today running with the `-peerbloomfilters` option).
* [BIP133](https://github.com/bitcoin/bips/blob/master/bip-0133.mediawiki) ("feefilter message") adds an optional `feefilter` message a node can send to inform the other side it is not interested in transactions with a feerate below a certain value. There is no negotiation for it, and the message is available whenever both sides indicate protocol version 70013 or higher. There is no problem with honoring incoming `feefilter` messages without ever sending them.
* [BIP157](https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki) ("Client Side Block Filtering"), like BIP111, permits but does not force a node to announce support for the filtering feature. One can support BIP157 but never use the other side's filtering feature (or care about it being offered).

In some case the feature is sender-initiated, but can still be negotiated separately in both directions:

* [BIP155](https://github.com/bitcoin/bips/blob/master/bip-0155.mediawiki) ("addrv2") is negotiated using a `sendaddrv2` message, which permits (but does not force) the other side to send `addrv2` messages instead of `addr` messages. From my reading, it is not an error to not send `sendaddrv2` yourself, but still honor one received from the other side.
* [BIP130](https://github.com/bitcoin/bips/blob/master/bip-0130.mediawiki) ("sendheaders message") lets a node tell its peers that they can (but are not forced to) announce new blocks using `headers` rather than using `inv`. It is possible to not send `sendheaders` but still honor requests from others to receive block announcements using `headers`.

So I think your observation is rather the exception than the norm. There are a few features which are all-or-nothing, in that they only work if supported by both peers, which then force different behavior on both:

* [BIP330](https://github.com/bitcoin/bips/blob/master/bip-0330.mediawiki) ("Transaction announcement reconciliation", the protocol change side of Erlay) is negotiated using `sendtxrcncl`, and only takes effect when both sides support it. In this case this is a hard requirement for the protocol as it is fundamentally bidirectional: instead of announce->request, both sides build sets of to-be-announced transactions, and then they run a set reconciliation protocol between those sets. This simply makes no sense unless both sides opt into it.
* [BIP324](https://github.com/bitcoin/bips/blob/master/bip-0324.mediawiki) ("Version 2 P2P Encrypted Transport Protocol") fundamentally changes the protocol itself spoken between peers. It is announced using a service flag (prior to connection), but the connection attempt itself is already distinct. Earlier iterations of this idea involved starting the protocol normally, and then negotiating an upgrade, but this interfered with an important privacy design goal of the protocol. The only option is having the protocol be encrypted from the very beginning, though old peers can be detected and supported by reconnecting with the old protocol.
* [BIP339](https://github.com/bitcoin/bips/blob/master/bip-0339.mediawiki) ("WTXID-based relay") is negotiated using a `wtxidrelay` message sent in both directions. When that succeeds, both sides must announce transactions using wtxids instead of txids (but may still request using txids).

More fundamentally, the purpose of feature negotiation (rather than mandatory upgrades) is allowing client software to opt into what features they want to support individually. I don't think there is much point in adding protocol complexity to cater to the specific use case of only supporting a feature in one direction. If an implementation already bears the complexity cost of implementing the feature, why wouldn't they want to use it?


---

