Skip to content

Persist counterparty_claimable_outpoints out of channel_monitor#4461

Open
TheBlueMatt wants to merge 8 commits intolightningdevkit:mainfrom
TheBlueMatt:2026-01-new-monitor-offload
Open

Persist counterparty_claimable_outpoints out of channel_monitor#4461
TheBlueMatt wants to merge 8 commits intolightningdevkit:mainfrom
TheBlueMatt:2026-01-new-monitor-offload

Conversation

@TheBlueMatt
Copy link
Collaborator

Rebase + rework of #3106

Matt Corallo and others added 6 commits March 4, 2026 22:22
When a splice locks in, consumers need to know which previous funding
outpoint was spent. Add a new field to Event::ChannelReady to surface
this information:

- spent_funding_txo: the previous funding outpoint consumed by the
  splice (None for initial channel funding)

The field uses an odd TLV tag (3) for backward compatibility.

Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Introduce two new events i.e. PersistClaimInfo and ClaimInfoRequest.

PersistClaimInfo: Indicates that [ClaimInfo] may be durably persisted
to reduce `ChannelMonitor` in-memory size.

ClaimInfoRequest: Used to request [ClaimInfo] for a specific counterparty
commitment transaction.
Introduces two new functions in the chainmonitor:
 * `provide_claim_info` - is called in response to a `ClaimInfoRequest`
    to provide the necessary claim data that was previously persisted using
    the `PersistClaimInfo` event.

 * `claim_info_persisted` - should be called after `ClaimInfo` is persisted
    via the `PersistClaimInfo` event to confirm that the data is durably
    stored.

Also introduces tracking of transactions which spend a commitment
transaction we're waiting on claim info for so that we can replay
them once we receive the claim info.

Original commit by G8XSU <3442979+G8XSU@users.noreply.github.com>

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
When we're waiting for claim info for a counterparty-broadcasted
revoked commitment transaction, we confused our claimable `Balance`
logic. Here we fix that, also including a new `Balance` to ensure
that a `ChannelMonitor` which is waiting on claim info can not be
pruned.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Indicates that a [`ClaimInfo`] for a specific counterparty
commitment transaction must be supplied to LDK if available.
Indicates that [`ClaimInfo`] may be durably persisted
to reduce `ChannelMonitor` in-memory size.
@ldk-reviews-bot
Copy link

ldk-reviews-bot commented Mar 4, 2026

I've assigned @jkczyz as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

TheBlueMatt and others added 2 commits March 4, 2026 22:28
While downstream code can always ignore `Event::PersistClaimInfo`,
the generation of them can be somewhat expensive, so we thus allow
downstream logic to disable them entirely here.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@TheBlueMatt TheBlueMatt force-pushed the 2026-01-new-monitor-offload branch from dd0662a to a09467c Compare March 4, 2026 22:29
handler(ev).await
{
if !self.offload_claim_info {
if let Event::PersistClaimInfo { .. } = &ev {
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should actually not be generated instead of simply filtered.

@ldk-reviews-bot
Copy link

🔔 1st Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

@ldk-reviews-bot
Copy link

🔔 2nd Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

@ldk-reviews-bot
Copy link

🔔 3rd Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants