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

Merge bitcoin/bitcoin#36260: torcontrol: Use reconnect backoff after dropped connections

Public commit record

What the developer wrote

Authored by merge-script

100/100 · Strong
Merge bitcoin/bitcoin#36260: torcontrol: Use reconnect backoff after dropped connections

4556ef62675400a4702d73c0a3e1dd4c7061a077 torcontrol: Apply reconnect backoff after dropped connections (Fabian Jahr)

Pull request description:

Since #34158 the reconnect backoff was only applied when connecting to the Tor control port failed. When an established connection was dropped, for example by Tor closing it after a failed `AUTHENTICATE` because of a wrong password, the control thread reconnected immediately in a loop without any wait. This was resulting in us trying to make tons of connections to torcontrol and producing tons of log entries in very short time. The fix restores the pre-#34158 behavior where every reconnect waits for the backoff timeout by going through `disconnected_cb`, which now also does the waiting. Also adds a functional test to cover that the waiting behavior is actually applied.

ACKs for top commit:
willcl-ark:
reACK 4556ef62675400a4702d73c0a3e1dd4c7061a077
winterrdog:
tACK 4556ef62675400a4702d73c0a3e1dd4c7061a077
sedited:
ACK 4556ef62675400a4702d73c0a3e1dd4c7061a077

Tree-SHA512: bfc4cee5f2f5cd9d7c251ca4f1201a32bff05340986500a9b883dc80c73ddf313a4ae611cefcc3abf463ec6b729264d41794608175644d1d064d53985543e815
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This change fixes a bug in how Bitcoin Core reconnects to the Tor control port. A previous update accidentally removed the wait time between reconnect attempts when an already-established Tor control connection was dropped. Without the wait, Bitcoin Core would rapidly reconnect in a tight loop, creating a flood of connection attempts and log messages. The fix restores the intended pause between reconnect attempts. It is primarily a denial-of-service/operational-stability issue for the local node, not a remote code execution or theft vulnerability.

Recommended action

No immediate emergency action is required. Users and node operators running Tor-enabled Bitcoin Core should plan to update to a release containing this fix to avoid log/control-port noise and minor resource exhaustion if the Tor control connection is repeatedly dropped. Operators can also review Tor control port credentials to reduce AUTHENTICATE failures.

Security signals we found

01

Uncontrolled retry loop causing resource exhaustion and log flooding

02

Local-only Tor control port interaction; no remote attacker path by default

03

Regression introduced by prior refactor (#34158) and restored here

04

Functional test added to prevent future regression

Risk score

Why this scored 30/100

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