AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Informational 18 Cryptographic libraries

blockchain_db/rpc: faster is_key_image_spent

Public commit record

What the developer wrote

Authored by jeffro256

58/100 · Thin
blockchain_db/rpc: faster is_key_image_spent

Does the following to speedup the `/is_key_image_spent` RPC endpoint:
- Reads all on-chain key images in one LMDB read transacion
- Uses `cryptonote_core::are_key_images_spent_in_pool()` instead of `cryptonote_core::get_pool_transactions_and_spent_keys_info()` for pool querying. This only does a LMDB read per key image if in the pool.
- Filters known on-chain spent key images before querying for key images spent in pool

This RPC endpoint was causing major daemon slowdowns in the Carrot/FCMP++ Alpha Stressnet when using the `rescan_spent` command, especially for large wallets.
The effect was much worse if the mempool was full.
✓ Descriptive subject✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit is a performance optimization for a Monero daemon RPC endpoint called /is_key_image_spent. It speeds up wallet rescan operations by reading on-chain key images in a single database transaction and by querying the memory pool more efficiently. The change is framed as a fix for severe daemon slowdowns during stress testing, not as a security vulnerability. There is no direct evidence in the commit of a security flaw, but the prior behavior could be abused to cause denial of service by sending many expensive queries.

Recommended action

Treat as a performance hardening patch rather than a critical security fix. Operators running public RPC nodes should deploy it to mitigate potential denial-of-service from expensive is_key_image_spent requests, especially when the mempool is large. No immediate incident response is warranted absent additional disclosure.

Security signals we found

01

Performance degradation / denial-of-service vector in RPC endpoint

02

Reduction in per-key-image LMDB transaction overhead

03

Reduction in mempool data exposure per RPC call

04

No memory safety, cryptographic, or authorization changes observed

Risk score

Why this scored 18/100

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