LLMQ: Bound pending signature shares

[navidR]

Bound unverified pending signature shares per peer and globally with constant-time accounting. Add boundary and cleanup coverage for all counted-map mutation paths.

Upstream: Dash PR #7415.

[codeant-ai]

🤖 CodeAnt AI — Review Status

Status	Commit	Started (UTC)	Finished (UTC)
✅ Incremental review completed	5af4b8c	Sep 30, 2026 · 10:13	10:14
✅ Reviewed your PR	a7c392a	Aug 30, 2026 · 14:55	14:59

[codeant-ai]

---

Thanks for using CodeAnt! 🎉

We're free for open-source projects. if you're enjoying it, help us grow by sharing.

Share on X ·
Reddit ·
LinkedIn

[coderabbitai]

Navigate logical layers of code changes, visualize relationships, and explore their blast radius.

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Advanced

Run ID: 34da67d2-458e-4a29-a525-e8e63833f6df

📥 Commits

Reviewing files that changed from the base of the PR and between 745ff35 and 5af4b8c.

📒 Files selected for processing (4)

• src/llmq/quorums_signing_shares.cpp
• src/llmq/quorums_signing_shares.h
• src/test/CMakeLists.txt
• src/test/quorums_signing_pending_tests.cpp

Included review availability: This review used your included allowance. Your plan provides up to 4 included reviews per hour; 3 remain after this review.

---

Summary by CodeRabbit

• Improvements
  • Incoming signing shares are now subject to per-node and overall pending-share limits, helping prevent excessive queue growth.
  • Shares from banned nodes are rejected, and capacity is available again when pending shares are removed.
  • Pending-share counts are tracked more efficiently, supporting quicker handling as queues change.

Walkthrough

The change adds entry-count tracking to signature-share maps and limits pending incoming shares to 1,000 per node and 10,000 total. It routes batched shares through an admission helper and adds tests for map accounting and admission limits.

Changes

Pending signature-share accounting and admission

Layer / File(s)	Summary
Counted signature-share storage src/llmq/quorums_signing_shares.h, src/test/quorums_signing_pending_tests.cpp	SigShareMap uses a bucket-map wrapper that maintains entry counts. Tests cover insertion, duplicate insertion, erasure, clearing, and pending counts after session removal.
Bounded pending-share admission src/llmq/quorums_signing_shares.h, src/llmq/quorums_signing_shares.cpp, src/test/quorums_signing_pending_tests.cpp, src/test/CMakeLists.txt	Batched shares pass through TryAddPendingIncomingSigShare, which rejects banned nodes and enforces per-node and total pending-share limits. Tests cover the limits, erasure, and banned-node behavior.

Priority: ⬇️ Low

Estimated code review effort: 3 (Moderate) | ~20 minutes

Change: Bug fix

Suggested reviewers: reubenyap

Merge Risk: ⚪ Minimal · up to 5af4b

The change bounds pending signature shares per node and globally and keeps size accounting constant-time. No concrete merge-blocking issue was identified in the supplied context.

Security Architecture Review

Security architecture risk: 🟡 Moderate · up to 5af4b

The new limits reduce memory-exhaustion exposure, but a requested share discarded at capacity can lose its normal retry path from the original peer. Recovery then depends on another peer or later lifecycle recovery, potentially delaying signing progress. No new authority escalation or signature-validation bypass was identified.

Retained concerns

• Medium · security · inferred: Capacity rejection can strand a requested share. The response handler erases the per-peer request before bounded admission and ignores rejection. Request issuance already cleared that peer's announcement, while the global request record still names it. Freeing pending capacity therefore does not make the share retryable from the original peer; timeout recovery requires a different announcing peer. Peer-driven saturation can consequently discard valid responses and delay signature recovery compared with the previous direct-insertion behavior.

Security review details

Security Blast Radius

• inferred — The directly affected availability domain is one active masternode's signature-share manager. Its global pending cap is shared across peer states and signing sessions, so pressure from some peers can reject shares arriving from others.

Security Findings and Attack Paths

• inferred — A connected peer with an accepted session can submit structurally acceptable shares without an outstanding-request requirement in preverification. If pending capacity is occupied when a legitimate requested response arrives, that response can be discarded after its retry bookkeeping has been consumed. Signing impact is conditional on whether other peers can supply sufficient shares.

Trust Boundaries and Controls

• observed — Existing controls require an active quorum, local quorum membership, available verification data, and valid, distinct member indices. Message-level share counts are bounded, and deferred cryptographic verification can ban invalid sources. The new caps supplement these controls rather than authorizing unverified shares as valid.

Resilience and Maintainability Implications

• observed — Randomized draining limits each verification collection to 32 actual shares and frees pending capacity. Alternate-peer requests can replace timed-out global request ownership. These mechanisms mitigate pressure, but neither automatically restores a cap-dropped response from the original peer.
• observed — The added tests cover map mutation counts, repeated session removal, exact capacity boundaries, admission after freeing capacity, and banning. They exercise the admission helper directly rather than the full response-to-retry transition.

Hardening Proposals

• proposed — Make capacity rejection an explicit recoverable transition: preserve or restore request eligibility, including global ownership and the relevant announcement state, without treating the rejected share as received. Validate recovery from the original peer after capacity becomes available.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 3.13% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 32 functions across 3 files. (1 skipped: 1…	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely describes the primary change: bounding pending signature shares in LLMQ.
Description check	✅ Passed	The description explains the intent, the main implementation changes, the test coverage, and the upstream reference. It does not use the template headings, but it contains the required information.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

Full details: Docstring Coverage

Explanation

Docstring coverage is 3.13% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 32 functions across 3 files. (1 skipped: 1 unsupported.)

• Fix all pre-merge checks with AI

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create a new PR

---

_{Comment @coderabbitai help to get the list of available commands.}

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-08-30T14:57:47.705241Z	a7c392a	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to 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" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[codeant-ai]

User description

Bound unverified pending signature shares per peer and globally with constant-time accounting. Add boundary and cleanup coverage for all counted-map mutation paths.

---

CodeAnt-AI Description

Limit pending signature shares per peer and globally

What Changed

• Unverified pending signature shares are rejected after reaching 1,000 shares from one peer or 10,000 shares across all peers
• Pending shares are removed from the limits when processed, deleted, or when a peer is banned
• Share counts remain accurate after individual, session-based, filtered, and bulk removals
• Added coverage for per-peer limits, global limits, cleanup, and duplicate entries

Impact

✅ Bounded memory use from pending signature shares
✅ Reduced exposure to signature-share flooding
✅ Accurate capacity after pending-share cleanup

💡 Usage Guide

Checking Your Pull Request

Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.

Talking to CodeAnt AI

Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:

@codeant-ai ask: Your question here

This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.

Example

@codeant-ai ask: Can you suggest a safer alternative to storing this secret?

Preserve Org Learnings with CodeAnt

You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:

@codeant-ai: Your feedback here

This helps CodeAnt AI learn and adapt to your team's coding style and standards.

Example

@codeant-ai: Do not flag unused imports.

Retrigger review

Ask CodeAnt AI to review the PR again, by typing:

@codeant-ai: review

Check Your Repository Health

To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.

[codeant-ai]

Suggestion: The return value is ignored, so a cap-rejected share is permanently dropped after its request was cleared and its announcement bit was consumed. [incomplete implementation]

Assessment: 🟠 Major · 🔁 Occurrence: Sometimes

Prompt for AI Agent 🤖

This is a comment left during a code review.

**Path:** src/llmq/quorums_signing_shares.cpp
**Line:** 541:541
**Comment:**
	*Incomplete Implementation: The return value is ignored, so a cap-rejected share is permanently dropped after its request was cleared and its announcement bit was consumed.

Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix

👍 | 👎

[codeant-ai]

Suggestion: Each share scans every node while holding cs; a peer can send repeated batches and cause expensive lock-held work that delays other signing messages. [performance]

Assessment: 🟠 Major · 🔁 Occurrence: Sometimes

Prompt for AI Agent 🤖

This is a comment left during a code review.

**Path:** src/llmq/quorums_signing_shares.cpp
**Line:** 559:562
**Comment:**
	*Performance: Each share scans every node while holding `cs`; a peer can send repeated batches and cause expensive lock-held work that delays other signing messages.

Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix

👍 | 👎

[navidR]

This is not from upstream, but something I think we should address:

  diff --git a/src/llmq/quorums_signing_shares.cpp b/src/llmq/quorums_signing_shares.cpp
  @@ -505,18 +505,19 @@
           for (size_t i = 0; i < batchedSigShares.sigShares.size(); i++) {
               CSigShare sigShare = RebuildSigShare(sessionInfo, batchedSigShares, i);
  -            nodeState.requestedSigShares.Erase(sigShare.GetKey());

               if (this->sigShares.Has(sigShare.GetKey())) {
  +                nodeState.requestedSigShares.Erase(sigShare.GetKey());
                   continue;
               }

               if (quorumSigningManager->HasRecoveredSigForId(
                       (Consensus::LLMQType)sigShare.llmqType, sigShare.id)) {
  +                nodeState.requestedSigShares.Erase(sigShare.GetKey());
                   continue;
               }

  @@ -538,6 +539,11 @@
       }
       auto& nodeState = it->second;
       for (auto& s : sigShares) {
  +        if (this->sigShares.Has(s.GetKey()) ||
  +            quorumSigningManager->HasRecoveredSigForId(
  +                (Consensus::LLMQType)s.llmqType, s.id)) {
  +            nodeState.requestedSigShares.Erase(s.GetKey());
  +            continue;
  +        }
           TryAddPendingIncomingSigShare(pfrom->id, nodeState, s);
       }
       return true;
  @@ -550,9 +556,27 @@
       if (nodeState.banned) {
           return false;
       }
  +    const auto& key = sigShare.GetKey();
  +    if (nodeState.pendingIncomingSigShares.Has(key)) {
  +        nodeState.requestedSigShares.Erase(key);
  +        return false;
  +    }
  +
  +    const auto rearmRequest = [&]() {
  +        if (!nodeState.requestedSigShares.Has(key)) {
  +            return;
  +        }
  +        if (auto session = nodeState.GetSessionBySignHash(key.first)) {
  +            session->announced.Set(key.second, true);
  +        }
  +        nodeState.requestedSigShares.Erase(key);
  +        sigSharesRequested.Erase(key);
  +    };
  +
       if (nodeState.pendingIncomingSigShares.Size() >= MAX_PENDING_SIG_SHARES_PER_NODE) {
           LogPrint("llmq-sigs", "CSigSharesManager::%s -- per-node pending sig shares cap reached (%d), dropping sigShare. node=%d\n",
               __func__, MAX_PENDING_SIG_SHARES_PER_NODE, nodeId);
  +        rearmRequest();
           return false;
       }

  @@ -563,10 +587,15 @@
       if (total >= MAX_PENDING_SIG_SHARES_TOTAL) {
           LogPrint("llmq-sigs", "CSigSharesManager::%s -- global pending sig shares cap reached (%d), dropping sigShare. node=%d\n",
               __func__, MAX_PENDING_SIG_SHARES_TOTAL, nodeId);
  +        rearmRequest();
           return false;
       }

  -    return nodeState.pendingIncomingSigShares.Add(sigShare.GetKey(), sigShare);
  +    const bool added = nodeState.pendingIncomingSigShares.Add(key, sigShare);
  +    if (added) {
  +        nodeState.requestedSigShares.Erase(key);
  +    }
  +    return added;
   }

[reubenyap]

I reviewed the pending-share admission path, every counted-map mutation path (single, bucket, predicate, and full clear), the per-peer/global boundaries, and ban/session cleanup. I also traced the request bookkeeping and the existing discussion; I found no additional actionable defect beyond the issues already raised on this PR. The focused regression coverage and full CI matrix are green.

[codeant-ai]

User description

Bound unverified pending signature shares per peer and globally with constant-time accounting. Add boundary and cleanup coverage for all counted-map mutation paths.

Upstream: Dash PR #7415.

---

CodeAnt-AI Description

Bound pending signature shares to prevent unverified data from exhausting resources

What Changed

• Limits unverified pending signature shares to 1,000 per peer and 10,000 across all peers; excess shares are dropped.
• Keeps banned peers from adding shares and clears their pending shares when they are banned.
• Tracks pending-share counts accurately as shares are added, removed, cleared, or discarded with a session.
• Adds coverage for per-peer limits, the global limit, cleanup, duplicate handling, and count consistency.

Impact

✅ Bounded memory use from pending signature shares
✅ Reduced exposure to excessive peer-supplied data
✅ Accurate pending-share cleanup

💡 Usage Guide

Checking Your Pull Request

Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.

Talking to CodeAnt AI

Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:

@codeant-ai ask: Your question here

This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.

Example

@codeant-ai ask: Can you suggest a safer alternative to storing this secret?

Preserve Org Learnings with CodeAnt

You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:

@codeant-ai: Your feedback here

This helps CodeAnt AI learn and adapt to your team's coding style and standards.

Example

@codeant-ai: Do not flag unused imports.

Retrigger review

Ask CodeAnt AI to review the PR again, by typing:

@codeant-ai: review

Check Your Repository Health

To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.