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

headerssync: retain Elements identity and proof fields

Public commit record

What the developer wrote

Authored by Byron Hambly

73/100 · Adequate
headerssync: retain Elements identity and proof fields

CompressedHeader kept only the Bitcoin PoW fields and GetFullHeader()
reconstructed only those. In the low-work headers presync/redownload path
Elements headers were therefore rebuilt without block_height, proof,
dynafed params, or the signblock witness, so the reconstructed header's hash
no longer matched what was received and the fields signed/dynafed validation
needs were dropped.

Retain block_height, proof, m_dynafed_params, and m_signblock_witness in
CompressedHeader and reconstruct them in GetFullHeader(). This enlarges the
per-header redownload buffer footprint (previously assumed to be 48 bytes);
the comment and static_assert are updated accordingly. No consensus rule
changes: the reconstructed header now matches the header that was received.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit fixes a bug in how Elements nodes temporarily store block headers during initial sync. The node was stripping out Elements-specific fields (block height, proof, dynamic federation parameters, and signblock witness) when compressing headers for memory efficiency. When it later rebuilt the full header, those fields were missing, so the rebuilt header's hash no longer matched the original header that was received. This could cause sync failures or validation problems for Elements nodes, but it does not change any consensus rules.

Recommended action

Treat as a bug-fix commit with availability/reliability impact. Review whether the larger CompressedHeader size materially affects memory limits under REDOWNLOAD_BUFFER_SIZE, and consider backporting to maintained release branches because the sync path is affected. No emergency consensus deployment is indicated.

Security signals we found

01

Header integrity loss in sync path: reconstructed header hash would not match received header

02

Loss of proof and signblock witness data needed for signed/dynafed validation

03

Potential denial-of-service via sync failure or validation rejection of otherwise valid headers

04

No consensus rule changes; fix is data-fidelity only

Risk score

Why this scored 63/100

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