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

net: use the proxy if overriden when doing v2->v1 reconnections

Public commit record

What the developer wrote

Authored by Vasil Dimov

73/100 · Adequate
net: use the proxy if overriden when doing v2->v1 reconnections

`OpenNetworkConnection()` supports overriding the proxy to use for
connecting. However when v2 connection is attempted and it fails a v1
connection is tried without that proxy.

Store the override proxy in `CNode` and pass it to
`CConnman::m_reconnections` to be used for v1 retries.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit fixes a bug in Bitcoin Core's networking code. When a user or operator had configured a specific proxy (a privacy-routing middleman) to be used for a particular outgoing connection, that proxy was correctly used on the first connection attempt. But if the modern v2 transport protocol handshake failed and Bitcoin Core automatically fell back to the older v1 protocol, the fallback connection ignored the specified proxy and used the global/default proxy instead. The fix stores the requested proxy override inside the peer object so the fallback reconnection remembers to use it.

Recommended action

Treat as a low-to-moderate privacy fix. Users relying on per-connection proxy overrides (e.g., for I2P/CJDNS/isolated outbound peers) should upgrade so that v2->v1 fallbacks do not leak connections through the wrong proxy. No emergency action is indicated; no memory corruption or remote code execution is present.

Security signals we found

01

Privacy/routing-policy bypass: per-connection proxy override ignored on fallback reconnection

02

Network-layer behavior inconsistency between initial connection and v2->v1 reconnection

03

Fix is targeted and state-preserving: stores override in CNode and reconnection queue

Risk score

Why this scored 35/100

Our methodology →
Potential impact 8/30
Exploitability 5/25
Stealth signal 6/15
Affected reach 5/15
Confidence 7/10
Evidence quality 4/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.