fix: limit signing share sessions per peer#7351
Conversation
|
@coderabbitai review |
✅ Action performedReview finished.
|
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
WalkthroughThis PR enforces per-peer session limits for LLMQ signing shares. It adds GetMaxSessionsForPeer and related constants, four Sequence Diagram(s)sequenceDiagram
participant Peer
participant CSigSharesManager
participant CSigSharesNodeState
participant TimeSeenStore
Peer->>CSigSharesManager: CSigSesAnn(llmqType, signHash)
CSigSharesManager->>CSigSharesManager: Params().GetLLMQ(llmqType)
CSigSharesManager->>CSigSharesNodeState: CanCreateSessionFromAnn(ann, maxSessions)
alt below cap
CSigSharesNodeState-->>CSigSharesManager: true
CSigSharesManager->>TimeSeenStore: timeSeenForSessions.try_emplace(signHash)
CSigSharesManager-->>Peer: accept announcement
else at or over cap
CSigSharesNodeState-->>CSigSharesManager: false
CSigSharesManager-->>Peer: reject announcement (logged)
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Suggested reviewers
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
✅ No Merge Conflicts DetectedThis PR currently has no conflicts with other open PRs. |
thepastaclaw
force-pushed
the
fix/qsigsesann-session-cap
branch
from
99be933 to
f54c9b7
Compare
|
@coderabbitai review |
|
Follow-up pushed in f54c9b7: kept the per-peer signing-session cap bounded, but added a minimum cap of 100 sessions so small test/devnet quorums do not exhaust the limit during normal ChainLock/InstantSend bursts before session cleanup runs. Validation:
@coderabbitai review |
✅ Action performedReview finished.
|
|
✅ Action performedReview finished.
|
thepastaclaw
force-pushed
the
fix/qsigsesann-session-cap
branch
from
f54c9b7 to
e5e8d1e
Compare
|
CI follow-up pushed in What changed:
Validation:
Note: the prior |
|
@coderabbitai review |
✅ Action performedReview finished.
|
|
✅ Review complete (commit 76a6fd7) |
|
@coderabbitai review |
✅ Action performedReview finished.
|
|
Follow-up pushed in 6595948 to avoid the |
|
@coderabbitai review |
✅ Action performedReview finished.
|
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 6595948482
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| return false; | ||
| } | ||
| auto& session = nodeState.GetOrCreateSessionFromAnn(ann); | ||
| timeSeenForSessions.insert_or_assign(ann.buildSignHash().Get(), GetTime<std::chrono::seconds>().count()); |
There was a problem hiding this comment.
When a peer periodically re-announces an already-known QSIGSESANN before SESSION_NEW_SHARES_TIMEOUT, insert_or_assign refreshes timeSeenForSessions, and cleanup only expires sessions by comparing the current time to that stored value. That lets announcement-only sessions stay alive indefinitely, so an attacker can keep its capped session slots and the corresponding per-peer state pinned forever; seed this timestamp only when the signHash is first inserted rather than on refresh.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Addressed in f6aa12a: QSIGSESANN announcements now seed timeSeenForSessions only on first insert (try_emplace) instead of refreshing it on repeat announcements. Actual sig-share receipt still refreshes the timestamp via ProcessSigShare, so announcement-only sessions expire normally.
|
@coderabbitai review |
✅ Action performedReview finished.
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f6aa12a20f
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
|
|
||
| bool CSigSharesNodeState::CanCreateSessionFromAnn(const llmq::CSigSesAnn& ann, size_t maxSessions) const | ||
| { | ||
| return sessions.count(ann.buildSignHash().Get()) != 0 || GetSessionCount(ann.getLlmqType()) < maxSessions; |
There was a problem hiding this comment.
When this node already has maxSessions sessions for a peer that were created locally for outgoing traffic (for example CollectSigSharesToAnnounce calls GetOrCreateSessionFromShare for that peer before SendMessages assigns a send session), this count rejects the peer's first unrelated QSIGSESANN even though the new limit is meant to constrain sessions created from announcements. NetSigning::ProcessMessage treats this false return as a ban, so under a busy signing backlog an honest peer can be banned because our own send-side sessions filled the per-peer count; the cap should exclude send-only sessions or track announcement-created sessions separately.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Addressed in 03dddee: the session cap now counts only sessions that were actually introduced by QSIGSESANN announcements. Send-only sessions created locally via sig shares no longer consume the announcement-session budget, while existing-session announcements are still accepted and then marked as announcement-backed.
Validation:
git diff --checkmake -C src -j8 test/test_dashsrc/test/test_dash --run_test=llmq_utils_tests --catch_system_errors=no
|
Follow-up pushed in Validation:
|
|
@coderabbitai review |
✅ Action performedReview finished.
|
| if (!nodeState.CanCreateSessionFromAnn(ann, maxSessions)) { | ||
| LogPrint(BCLog::LLMQ_SIGS, "CSigSharesManager::%s -- too many sessions. cnt=%d, max=%d, llmqType=%d, node=%d\n", | ||
| __func__, nodeState.GetAnnouncementSessionCount(llmqType), maxSessions, static_cast<int>(llmqType), pfrom.GetId()); | ||
| return false; |
There was a problem hiding this comment.
Not sure we should ban here. Wouldn't ignoring it be safer?
| return false; | |
| return true; |
thepastaclaw
left a comment
thepastaclaw
left a comment
There was a problem hiding this comment.
Code Review
Targeted DoS-hardening change with appropriate scope and unit coverage. No correctness or security issues. Three nitpick-level observations from Claude on documentation, an O(n) scan on a hot path, and operation sequencing — none block the PR.
💬 3 nitpick(s)
| constexpr size_t MAX_SESSIONS_PER_PEER_FACTOR{4}; | ||
| constexpr size_t MIN_SESSIONS_PER_PEER{100}; |
There was a problem hiding this comment.
💬 Nitpick: Document the cap factor and floor
MAX_SESSIONS_PER_PEER_FACTOR{4} and MIN_SESSIONS_PER_PEER{100} lack any rationale. With LLMQ_400_* (size=400) the per-peer cap is 1600 announcement-derived sessions; each Session carries three quorum-sized CSigSharesInv bitsets plus several uint256s and a CQuorumCPtr. A short comment tying these constants to the threat model in the PR description would help future maintainers reason about adjustments and explain why the 100 floor exists even though no current LLMQ size requires it.
source: ['claude']
| bool CSigSharesNodeState::CanCreateSessionFromAnn(const llmq::CSigSesAnn& ann, size_t maxSessions) const | ||
| { | ||
| return sessions.count(ann.buildSignHash().Get()) != 0 || GetAnnouncementSessionCount(ann.getLlmqType()) < maxSessions; | ||
| } | ||
|
|
||
| size_t CSigSharesNodeState::GetSessionCount() const | ||
| { | ||
| return sessions.size(); | ||
| } | ||
|
|
||
| size_t CSigSharesNodeState::GetSessionCount(Consensus::LLMQType llmqType) const | ||
| { | ||
| return std::ranges::count_if(sessions, [&](const auto& kv) { return kv.second.llmqType == llmqType; }); | ||
| } | ||
|
|
||
| size_t CSigSharesNodeState::GetAnnouncementSessionCount(Consensus::LLMQType llmqType) const | ||
| { | ||
| return std::ranges::count_if(sessions, [&](const auto& kv) { | ||
| return kv.second.receivedAnnouncement && kv.second.llmqType == llmqType; | ||
| }); | ||
| } |
There was a problem hiding this comment.
💬 Nitpick: Linear scan per announcement, recomputed on rejection
GetAnnouncementSessionCount(llmqType) is O(n) over sessions and runs from CanCreateSessionFromAnn on every QSIGSESANN. On the rejection path it is then recomputed for the LogPrint at line 266, doubling the cost exactly when a peer is being throttled. A per-llmq-type counter on CSigSharesNodeState (maintained when receivedAnnouncement transitions false→true and on session removal) would make admission O(1). At minimum, cache the count in a local in ProcessMessageSigSesAnn so the rejection log reuses it.
source: ['claude']
|
|
||
| LOCK(cs); | ||
| auto& nodeState = nodeStates[pfrom.GetId()]; | ||
| const size_t maxSessions = GetMaxSessionsForPeer(*llmq_params_opt); | ||
| if (!nodeState.CanCreateSessionFromAnn(ann, maxSessions)) { | ||
| LogPrint(BCLog::LLMQ_SIGS, "CSigSharesManager::%s -- too many sessions. cnt=%d, max=%d, llmqType=%d, node=%d\n", | ||
| __func__, nodeState.GetAnnouncementSessionCount(llmqType), maxSessions, static_cast<int>(llmqType), pfrom.GetId()); | ||
| return true; | ||
| } |
There was a problem hiding this comment.
💬 Nitpick: Quorum lookup precedes the cap check
qman.GetQuorum(llmqType, ann.getQuorumHash()) runs at line 253, before the per-peer cap check at line 264. A peer flooding QSIGSESANN with valid quorum hashes still pays the quorum-lookup cost on every announcement after it has been throttled. Moving the cap gate ahead of the quorum resolution (the gate only needs the llmqType and the existing cs lock) would make the throttle cheaper to enforce. Minor sequencing improvement that compounds with addressing the linear scan above.
source: ['claude']
2 participants
fix: limit signing share sessions per peer
Issue being fixed or feature implemented
Peers can announce many distinct QSIGSESANN signing sessions. Without a per-peer
cap, a peer can make its node state grow with announcement-only sessions.
What was done?
accepted.
refreshing that timeout on repeated announcements.
How Has This Been Tested?
Tested on macOS arm64.
git diff --check upstream/develop...HEADmake -j8 src/test/test_dashsrc/test/test_dash --run_test=llmq_signing_shares_testsshipBreaking Changes
None.
Checklist