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

blockstorage: return an error code from `ReadRawBlock()`

Public commit record

What the developer wrote

Authored by Roman Zeyde

85/100 · Strong
blockstorage: return an error code from `ReadRawBlock()`

It will enable different error handling flows for different error types.

Also, `ReadRawBlockBench` performance has decreased due to no longer reusing a vector
with an unchanging capacity - mirroring our production code behavior.

Co-authored-by: Hodlinator <172445034+hodlinator@users.noreply.github.com>
Co-authored-by: Lőrinc <pap.lorinc@gmail.com>
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
The short version

What changed, and why it matters

This commit refactors how Bitcoin Core reads raw block files from disk. Previously, the ReadRawBlock() function returned true/false and filled a caller-provided buffer. Now it returns a structured result that distinguishes I/O errors from success. The main observable security-relevant change is in the REST API: when a block cannot be read from disk due to an I/O problem, it now returns HTTP 500 (Internal Server Error) instead of HTTP 404 (Not Found). This is a correctness improvement that reduces the chance an attacker can trick the node into revealing whether a pruned block existed, but it is not a fix for an active vulnerability.

Recommended action

No urgent action required. Treat as a normal code-quality/refactor commit. Reviewers may want to confirm that all ReadRawBlock() callers handle the new util::Expected return correctly and that the REST 500 response is acceptable for existing API clients.

Security signals we found

01

REST endpoint error-code distinction between 'not found' and 'I/O error'

02

Potential minor information-disclosure reduction (404 vs 500) for pruned/disk-failure cases

03

Refactoring only; no change to block validation, deserialization, or network consensus rules

Risk score

Why this scored 19/100

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