Repository navigation
Add APIs to classify channel-related transaction types #3566
Description
It would be great if we could add APIs that would allow the user to determine which 'type' of transaction any given transaction would be related to channel operation.
Especially when it comes to splicing it would be helpful if a user could check whether a particular Txid is 'known' to LDK and retrieve whether its a channel funding/channel close/splice in/splice out transaction.
Activity
TheBlueMatt commentedon May 1, 2025
Hmm, I don't really think we can do this generically as a query - LDK doesn't keep around all the information that would be required to do this (and I don't think we want to change that). I'm curious what is missing from the current API to be able to handle this on the client end, though? Presumably the only transactions you care about will come back via
SpendableOutputevents, which can be tracked on the client end, though we'll have to figure out what this looks like with splicing indeed.wpaulino commentedon May 1, 2025
I'm not sure we'll be producing
SpendableOutputevents for splices, they might not even have an output that pays back to the user. We will have two splicing-related events though: one for once it's negotiated and another once it's locked. Those could help the user label transactions in their wallet on their own.TheBlueMatt commentedon May 1, 2025
Right, I was thinking we'd have a new event for splicing confirmations which could be used by clients, as you note.
tnull commentedon Oct 1, 2025
Discussed this offline: we'll add additional arguments for channel ID and 'transaction label' to broadcaster interface that allows the implementer to intercept what the 'type' (funding, closing, splice in/out, bump) a particular transaction is and what channel context it is for. This would allow LDK Node to track an intermediary, persisted list of such labels that it can lookup while syncing the BDK onchain wallet.
ldk-reviews-bot commentedon Aug 13, 2026
@tnullcommented on Forgejo:Reopening this issue. When implementing the chosen approach (classifying transactions at broadcast time rather than keeping some more state on the LDK side and offering an API to query the transaction type) we keep seeing edge cases pop up left and right. While we'll ship this for LDK Node v0.8 (given we don't have an alternative), this won't be maintainable for longer.
I strongly feel we need to revisit this, e.g., by adding a persistent store to LDK that keeps track of all known (also closed/historic) channels and allows users (LDK Node) to query what a specific transaction is/which channel it relates to.
Related issues/PRs that deal with the complexity stemming from the chosen approach:
ChannelMonitor::best_block_updatedbeforeChannelMonitor::transactions_confirmedmay needlessly delay broadcasting by a block #962 — Keep funding payment records consistent across sync and classification (Keep funding payment records consistent across sync and classification ldk-node#962)ChannelMonitor::best_block_updatedbeforeChannelMonitor::transactions_confirmedmay needlessly delay broadcasting by a block #962 (Track remaining funding-payment consistency issues after #962 ldk-node#1044)(cc @jkczyz @matt)
ldk-reviews-bot commentedon Aug 13, 2026
@mattcommented on Forgejo:Hmmmm, so it seems like there's two issues here:
(a) ldk-node learns about transactions primarily via the broadcast interface which doesn't have any guarantees about replays on restart. The right fix for this would be to simply not broadcast until we've persisted whatever it is we need to track the transaction in a crash, except that
lightningdoesn't currently rebroadcast funding transactions. Ultimately this is #2574, at which point it should be relatively straightforward to fix.(b) much more importantly, however, we may learn of a transaction first not from a broadcast but rather from the chain, in case our peer broadcasts the transaction first. This obviously interacts with (a) in cases where we started to write then failed to finish updating whatever stores we have and then don't get a rebroadcast at all because the transaction is confirmed.
I think the only places where we can have a transaction that is broadcastable by either us or our counterparty is the funding tx - both splicing and dual-funding. One trivial thing we could do to ensure ldk-node sees transactions before they hit the chain is move
Event::SpliceNegotiatedup to happen before we send the funding signatures to our peer. If we then wait for the event to be processed before doing so (and include some transaction info in the event) I think we'd guarantee thatldk-nodesees transaction metadata before any transaction can appear on chain. It would be a semantic change toSpliceNegotiatedas we could still fail to get the splice tx after the event, but it doesn't seem wildly crazy.This one is just a bug in the
lightningcrate - #4878, which you mention, not an issue with the approach per se.Its not clear to me how this is realted?
ldk-reviews-bot commentedon Aug 13, 2026
@f3r10commented on Forgejo:@tnull @matt I think this PR is also related to this topic lightningdevkit/ldk-node#882 (Add persistent closed channel history and list_closed_channels())