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

Daemon RPC: getblocks.bin block_ids_exclusive req param

Public commit record

What the developer wrote

Authored by j-berman

73/100 · Adequate
Daemon RPC: getblocks.bin block_ids_exclusive req param

When the request includes block_ids, the daemon uses
find_blockchain_supplement to identify the highest block hash
passed in block_ids that the daemon also knows about, and then
serves subsequent blocks contiguous to that block.

When block_ids_skip_exclusive is false (default current
behavior), the daemon includes the highest block requested in the
response, in addition to contiguous blocks after it.

When block_ids_skip_exclusive is true (new param), the daemon
serves blocks starting from the block 1 higher than the highest
known block included in block_ids. Thus, the daemon skips the
common block known to the client and daemon. Clients can make sure
the daemon is serving expected contiguous blocks to its highest
known block by checking the first block's prev_id included in the
response, and making sure it is equivalent to the block the client
already knows about that was included in block_ids. This avoids
the daemon serving 1 extra block it does not need to serve to the
client, since the client should already know about that block.

bl
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit adds a new optional flag to the Monero daemon's binary RPC for fetching blocks. When enabled, the daemon skips sending the one block the client already knows about, reducing bandwidth. The change is backward-compatible (default is the old behavior) and appears to be a routine protocol optimization, not a security fix.

Recommended action

No immediate security action required. Treat as a normal feature/protocol optimization. If deploying, ensure client implementations understand the new optional flag and validate the prev_id of the first returned block as described in the commit message.

Security signals we found

01

New optional RPC parameter with safe default (false) preserving prior behavior

02

Added CHECK_AND_ASSERT_MES(total_height > start_height, ...) invariant

03

Potential for empty response when start_height reaches total_height under exclusive mode

04

No input validation changes for block_ids list itself

Risk score

Why this scored 24/100

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