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

funding: persist ConfirmationHeight upon first funding confirmation

Public commit record

What the developer wrote

Authored by Nishant Bansal

73/100 · Adequate
funding: persist ConfirmationHeight upon first funding confirmation

This change ensures that a channel's ConfirmationHeight is recorded in the
database once its funding transaction receives its initial confirmation.
By doing so, we establish a reliable reference point to monitor the
channel's progress toward the required confirmation depth.

Signed-off-by: Nishant Bansal <nishant.bansal.282003@gmail.com>
✓ 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 how LND records when a new Lightning channel's funding transaction is first confirmed on the Bitcoin blockchain. Previously, the exact block height of first confirmation was not reliably saved. Now it is written to the database as soon as the first confirmation is seen, and reset to zero if a blockchain reorganization removes that confirmation. This is a correctness and reliability improvement rather than a fix for an active exploit, but it helps prevent state inconsistencies that could affect channel safety after restarts or reorgs.

Recommended action

Review as a normal reliability/correctness improvement. Include in release notes as a robustness enhancement for channel funding confirmation tracking. No emergency patch or security advisory is warranted based solely on this commit. If this change relates to a known issue, request the associated CVE or vendor security notice to reassess.

Security signals we found

01

State persistence improvement: records first confirmation block height in channel database

02

Reorg handling: resets ConfirmationHeight to 0 on NegativeConf

03

Adds defensive checks so channel progress toward required confirmation depth is recoverable after restart

04

No direct evidence in commit of an exploitable bug such as funds theft, DoS, or state corruption being fixed

05

No CVE, advisory, or vendor security disclosure referenced in commit message or diff

Risk score

Why this scored 31/100

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