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

Free holding cells immediately rather than in message sending

Public commit record

What the developer wrote

Authored by Matt Corallo

83/100 · Strong
Free holding cells immediately rather than in message sending

I noted in review for an unrelated PR that adding more per-channel
logic in `ChannelManager::get_and_clear_pending_msg_events` really
sucks for our performance, especially if it ends up hitting a sync
monitor persistence. This made me wonder how far we actually are
from not needing the holding `check_free_holding_cells` call that's
currently there.

Turns out, at least according to our functional test coverage, the
answer is "not very far".

Thus, here we drop it in favor of consistently calling a new util
method on channels that might have the ability to release holding
cell updates in the same lock where they change state, rather than
waiting until `get_and_clear_pending_msg_events`.

We still process async monitor events in
`get_and_clear_pending_msg_events`, which can lead to channel (and
monitor) updates, but that should only be the case for async
persist applications, which then are likely to have fast
`ChannelMonitorUpdate` in-line handling logic (cause its async).
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
The short version

What changed, and why it matters

This commit is a performance-focused internal refactor in the Lightning Dev Kit. It moves the freeing of 'holding cells' (temporary queues of pending payment updates inside a channel) from the message-sending path to the moment the channel state changes. The goal is to avoid doing extra work, including possible disk I/O, while the node is trying to send messages. The commit does not fix a known exploit, but it changes how and when channel state is updated and persisted, which has security-adjacent implications for consistency and denial-of-service.

Recommended action

Treat as a normal code-quality/performance patch. Reviewers should verify that the new immediate-free paths always hold the total consistency lock and that dropping holding-cell work from `get_and_clear_pending_msg_events` does not create a window where pending HTLCs or monitor updates are left unprocessed. Run the updated functional tests and monitor for the new debug assertion/log error in CI.

Security signals we found

01

Changes lock ordering and timing of state updates

02

Adds debug assertions that the total consistency lock is held during holding-cell processing

03

Moves monitor-update handling out of the message-retrieval hot path

04

Adds a debug assertion/log error when holding cells are not freed immediately

05

Refactor touches HTLC failure and channel monitor update paths

Risk score

Why this scored 33/100

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