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

channeldb: add type-prefix to waiting proof store records

Public commit record

What the developer wrote

Authored by Elle Mouton

95/100 · Strong
channeldb: add type-prefix to waiting proof store records

Existing waiting proof records encode a bare isRemote flag followed by a
raw AnnounceSignatures1 payload. A future gossip v2 implementation will
store AnnounceSignatures2 (taproot) proofs in the same bucket, so each
record needs a discriminator byte to select the correct decoder.

This commit:

1. Defines WaitingProofTypeV1 (= 0x00) for the current
AnnounceSignatures1-based proofs.
2. Updates WaitingProofKey to 10 bytes [proofType(1) || scid(8) ||
isRemote(1)] to avoid cross-version key collisions.
3. Adds migration 35, which rewrites every existing record to prepend
the type byte and rewrites keys to the new format.
4. Updates WaitingProof.Encode/Decode to always write/expect the prefix.

The migration, codec changes, and tests are kept in one atomic commit so
there is no intermediate revision where the new Decode can encounter
unmigrated records.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification
The short version

What changed, and why it matters

This commit is a forward-looking database format change for LND's 'waiting proof store,' which holds channel announcement proofs. It adds a one-byte type marker to each stored record and its lookup key so that a future gossip v2/Taproot version can safely store a different proof type in the same place. It also ships a database migration that rewrites all existing records to the new format. The change is defensive and structural, not a fix for an active vulnerability.

Recommended action

Treat as a normal schema-migration commit. Verify migration35 tests pass and that the migration is registered correctly. No immediate security response is required, but operators upgrading should ensure the migration completes cleanly because it rewrites waiting proof records in place.

Security signals we found

01

Database schema migration with key/value rewrite and key-format change

02

New explicit type discriminator to prevent cross-version record misinterpretation

03

Decode now rejects unknown waiting proof types

04

Migration includes sanity check that legacy key matches decoded record content

05

Atomic commit of migration and codec changes to avoid decode mismatch windows

Risk score

Why this scored 26/100

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