AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Low 28 Bitcoin

p2p: first addr self-announcement in separate msg

Public commit record

What the developer wrote

Authored by 0xb10c

76/100 · Adequate
p2p: first addr self-announcement in separate msg

This makes sure the initial address self-announcement a node sends to
a peer happends in a separate P2P message. This has benefits for both
inbound and outbound connections:

For inbound connections from a peer to us, previously, we might send
the self-announcement along with our response to a GETADDR request.
However, the self-announcement might replace an address from the
GETADDR response. This isn't clean.

For outbound connections from us to a peer, previously, it could have
happend that we send the self-announcement along with other addresses.
Since shortly after connection open, the peer might only have one
rate-limiting token for us, and the addresses are shuffeld on arrival,
it's possible that the self-announcement gets rate-limited. However,
note that these rate-limitings seem to be rare in practice.

This is inspired by and based on https://github.com/bitcoin/bitcoin/pull/33699#issuecomment-3462287763

Co-Authored-By: Anthony Towns <aj@erisian.com.au>
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This Bitcoin Core change tweaks how a node tells other nodes about its own internet address when they first connect. Previously, the node's own address could get bundled with other addresses in the same network message. Because new connections only get one temporary 'token' that lets a single address through, the node's own address could accidentally be dropped by the peer's rate limiter. The fix sends the first self-announcement in its own dedicated message so it isn't crowded out by other addresses. It also makes the initial address exchange cleaner for inbound connections.

Recommended action

No immediate action required beyond normal review and testing. This is a hardening/cleanup change. Operators and downstream maintainers should include it in the next release cycle.

Security signals we found

01

P2P address propagation reliability improvement

02

Rate-limiting token exhaustion avoidance for first self-announcement

03

Reduced chance of self-announcement being dropped on new peer connections

04

Clean separation of GETADDR response and self-announcement for inbound peers

Risk score

Why this scored 28/100

Our methodology →
Potential impact 5/30
Exploitability 3/25
Stealth signal 4/15
Affected reach 6/15
Confidence 7/10
Evidence quality 3/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.