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

Split out remaining uses of `is_pre_funded_state` and rename it

Public commit record

What the developer wrote

Authored by Matt Corallo

90/100 · Strong
Split out remaining uses of `is_pre_funded_state` and rename it

`Channel::is_pre_funded_state` is used to mean several different
things. In the past few commits we stopped using it for a few
conflicting uses, but here we break out the remaining uses and
rename the remnants for clarity.

`is_funding_broadcast` was using `is_pre_funded_state` and was then
later used to decide if the `Channel` could be written to disk
(because it can be resumed on restart), if we should broadcast a
force-close transaction, and when to emit a `ChannelPending` event.

These were also somewhat divergent - we shouldn't generate a
`ChannelReady` event or broadcast a force-closing transaction until
we've actually broadcasted but want to write the `Channel` to disk
once we enter funding signature exchange for dual-funded open.

Thus, the ability to write a `Channel` to disk is provided by a new
`can_resume_on_restart` method. Then, `is_funding_broadcast` is
updated to only consider funding broadcasted after we provide our
funding signatures (i.e. the funding *could* have been
broadcasted). This is still a bit early to generate a
`ChannelPending` event (as the funding may not actually have been
broadcasted yet), but its better than it was.

Finally, the remaining `is_pre_funded_state` is renamed
`can_resume_on_reconnect`, which has slightly different semantics
than on-restart channels in batch opens.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Names security-relevant behavior explicitly
The short version

What changed, and why it matters

This commit is a code-cleanup refactor in a Bitcoin Lightning Network library. It splits one overloaded channel-state check into three more precise checks so that saving channels to disk, deciding when to broadcast force-close transactions, and emitting 'channel is opening' events no longer rely on a single ambiguous flag. The change appears aimed at preventing subtle bugs in dual-funded channel opening, but the commit itself does not claim to fix a known security vulnerability and no exploit is described.

Recommended action

Treat as a maintainability and robustness improvement rather than an urgent security patch. Reviewers should verify that `can_resume_on_restart` correctly handles batch-open channels (where some sub-channels must not be persisted independently) and that `is_funding_broadcastable` does not delay `ChannelPending` or force-close in ways that violate protocol expectations. Consider adding/adjusting tests for dual-funded open persistence and event timing. No immediate user action is required unless this commit is part of a larger disclosed security fix.

Security signals we found

01

State-machine predicate split reduces conflation of persistence, event emission, and force-close broadcast decisions

02

Dual-funded/interactive signing channels now persisted earlier than before (once signature exchange begins)

03

Force-close broadcast and ChannelPending event now gated by `is_funding_broadcastable`, which waits until our tx signatures are ready

04

No explicit security bug, CVE, or exploit described in commit message or diff

05

Change is defensive/refactoring; correctness depends on whether new predicates cover all edge cases

Risk score

Why this scored 30/100

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