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

hold silent payment notifications arriving before the subscribe response is recorded, discarding those of a replaced subscription

Public commit record

What the developer wrote

Authored by Craig Raw

50/100 · Thin
hold silent payment notifications arriving before the subscribe response is recorded, discarding those of a replaced subscription
✓ Specific, descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
The short version

What changed, and why it matters

This commit fixes a race condition in Sparrow Wallet's silent-payments scanning. When the wallet subscribes to a server to scan for silent payments, the server's first notification can arrive before the wallet has finished recording the subscription's official start height. Without the fix, that early notification could be ignored (potentially leaving the scan stuck waiting forever) or a notification from an old, replaced subscription could be wrongly applied (showing incorrect transaction history). The change holds early notifications in a small queue until the start height is known, then applies only the ones that belong to the current subscription, in the correct order.

Recommended action

Treat as a reliability/integrity fix. Review the new sequence-numbering logic for correctness under reconnects and concurrent subscriptions, run the added unit tests, and consider whether the 1000-notification cap is appropriate for all server latencies. No immediate emergency response is indicated, but users relying on silent payments should update once the release is available.

Security signals we found

01

Race condition between subscribe RPC response and asynchronous silent-payment notifications

02

Possible indefinite wait / scan hang from dropped completion notification

03

Possible application of stale/replaced-subscription history leading to incorrect wallet state

04

Ordering fix for event posting to prevent replay/live notification inversion

05

New unit tests cover held-notification, stale-notification, overflow, and widening-failure scenarios

Risk score

Why this scored 47/100

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