net_processing: reorder the code that handles the VERSION message
What the developer wrote
Authored by Vasil Dimov
net_processing: reorder the code that handles the VERSION message
Change the order in which code snippets are executed as a result of
receiving the `VERSION` message. Move the snippets that do
`MakeAndPushMessage()` near the end. This makes it easier to interrupt
the execution when no messages should be sent as a response to the
`VERSION` messages, in private broadcast connections.
This is a non-functional change.
What changed, and why it matters
This commit simply rearranges the order of steps inside the code that handles a peer's VERSION message in Bitcoin Core. It moves the sending of two optional follow-up messages (WTXIDRELAY and SENDADDRV2) to a later point in the same function. The commit message explicitly calls this a non-functional change, and the diff shows no logic changes—only moved code blocks.
No security action required. Treat as a routine refactor. Review any follow-up commits that actually add the short-circuit logic for private broadcast connections, as those may carry security relevance.
Security signals we found
No strong security signals were identified.
Evidence from the diff
In src/net_processing.cpp, the ProcessMessage handler for NetMsgType::VERSION was refactored so that MakeAndPushMessage calls for WTXIDRELAY and SENDADDRV2 occur after service-flag parsing, address setup, and tx relay flag handling, instead of before. The conditional guards and message contents are unchanged. The stated purpose is to make it easier in future work to short-circuit outgoing responses for private broadcast connections. No behavior change is introduced by this patch alone.
Changed components
src/net_processing.cppVERSION message handling in PeerManagerImpl::ProcessMessageInspect captured patch +13 / −13
diff --git a/src/net_processing.cpp b/src/net_processing.cpp
index 54156470..14c2d5aa 100644
--- a/src/net_processing.cpp
+++ b/src/net_processing.cpp
@@ -3541,19 +3541,6 @@ void PeerManagerImpl::ProcessMessage(CNode& pfrom, const std::string& msg_type,
pfrom.SetCommonVersion(greatest_common_version);
pfrom.nVersion = nVersion;
- if (greatest_common_version >= WTXID_RELAY_VERSION) {
- MakeAndPushMessage(pfrom, NetMsgType::WTXIDRELAY);
- }
-
- // Signal ADDRv2 support (BIP155).
- if (greatest_common_version >= 70016) {
- // BIP155 defines addrv2 and sendaddrv2 for all protocol versions, but some
- // implementations reject messages they don't know. As a courtesy, don't send
- // it to nodes with a version before 70016, as no software is known to support
- // BIP155 that doesn't announce at least that protocol version number.
- MakeAndPushMessage(pfrom, NetMsgType::SENDADDRV2);
- }
-
pfrom.m_has_all_wanted_services = HasAllDesirableServiceFlags(nServices);
peer->m_their_services = nServices;
pfrom.SetAddrLocal(addrMe);
@@ -3580,6 +3567,19 @@ void PeerManagerImpl::ProcessMessage(CNode& pfrom, const std::string& msg_type,
if (fRelay) pfrom.m_relays_txs = true;
}
+ if (greatest_common_version >= WTXID_RELAY_VERSION) {
+ MakeAndPushMessage(pfrom, NetMsgType::WTXIDRELAY);
+ }
+
+ // Signal ADDRv2 support (BIP155).
+ if (greatest_common_version >= 70016) {
+ // BIP155 defines addrv2 and sendaddrv2 for all protocol versions, but some
+ // implementations reject messages they don't know. As a courtesy, don't send
+ // it to nodes with a version before 70016, as no software is known to support
+ // BIP155 that doesn't announce at least that protocol version number.
+ MakeAndPushMessage(pfrom, NetMsgType::SENDADDRV2);
+ }
+
if (greatest_common_version >= WTXID_RELAY_VERSION && m_txreconciliation) {
// Per BIP-330, we announce txreconciliation support if:
// - protocol version per the peer's VERSION message supports WTXID_RELAY;
Why this scored 13/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.