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

blockchain: tolerate trailing bytes when loading stored blocks

Public commit record

What the developer wrote

Authored by Olaoluwa Osuntokun

73/100 · Adequate
blockchain: tolerate trailing bytes when loading stored blocks

In this commit, we relax the strict block deserialization introduced as
part of the trailing byte hardening. Databases written by older
versions of btcd may have persisted blocks with trailing bytes, so
refusing to load them would prevent a node from ever starting (or
serving such a block) after an upgrade, with no recovery path short of
a full resync.

We instead introduce a new dbBlockFromBytes helper, used by both
initChainState and dbFetchBlockByNode, that deserializes the block
leniently: any trailing bytes are logged, ignored, and excluded from
the serialization cached on the returned block, so downstream consumers
of the raw bytes never observe them.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit changes btcd so that when it reads old blocks from its own database, it ignores any extra bytes tacked onto the end of the stored block data instead of refusing to start. Older versions of btcd sometimes saved blocks with extra trailing bytes, and a previous stricter change made the node unable to start after an upgrade. The fix logs a warning, drops the extra bytes, and makes sure any cached copy of the block no longer contains them. It does not change how blocks received from the network or RPC are checked.

Recommended action

Treat as a compatibility/recovery fix rather than a vulnerability. Review that DBBlockFromBytes is used only for database reads and never for network/RPC input, and confirm downstream consumers of block.Bytes() cannot be confused by the prior trailing-byte state. No immediate patching is required, but operators should monitor logs for warnings about trailing bytes and consider database cleanup if they persist.

Security signals we found

01

Relaxation of strict deserialization for locally stored blocks

02

Trailing bytes are logged, ignored, and excluded from cached serialization

03

Block size metric recomputed from cleaned serialization

04

Explicit scope restriction: only for node's own database, not p2p/RPC

05

Previous test expected rejection; updated test now expects tolerance

Risk score

Why this scored 34/100

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