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

v2transport: refactor responder setup

Public commit record

What the developer wrote

Authored by Boris Nagaev

58/100 · Thin
v2transport: refactor responder setup

In this commit, we split the responder handshake into transport
classification, key setup, and wire completion phases. This lets callers
install a narrow admission interface after the full v2 candidate is
available, while preserving NewPeer compatibility and the existing
transcript.

We also propagate handshake write failures, reject short writes, and
cover v1 fallback, incomplete candidates, admission lifetime, and
end-to-end v2 interoperability.
✓ Descriptive subject✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit refactors how btcd handles incoming Bitcoin v2 transport handshakes. It adds a new admission-control hook so a responder can decide whether to spend CPU on a v2 handshake only after it has seen enough bytes to confirm the peer is actually attempting v2, not v1. It also fixes two smaller robustness issues: handshake write failures are now propagated to callers, and short writes are explicitly rejected. The change is defensive in nature and appears aimed at preventing CPU-exhaustion attacks and improving error handling, not at introducing new functionality.

Recommended action

Review the admission interface design to ensure it cannot be bypassed by callers that supply a no-op admission policy. Confirm that the responderReady flag and refactored CompleteHandshake ordering do not introduce race conditions in concurrent handshake paths. Consider whether the new Send short-write behavior changes any existing caller assumptions.

Security signals we found

01

Adds CPU admission control for responder v2 handshake to bound expensive cryptography

02

Ensures v1 fallback and incomplete candidates do not trigger key generation or admission consumption

03

Propagates handshake write failures instead of silently dropping them

04

Rejects short writes explicitly via io.ErrShortWrite

05

Adds tests for v1 fallback, incomplete candidates, wrong-network v1, admission rejection, admission lease timing, and end-to-end v2 interoperability

Risk score

Why this scored 38/100

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