Repository navigation
Add APIs to classify channel-related transaction types #3566
Description
Activity
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.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.Right, I was thinking we'd have a new event for splicing confirmations which could be used by clients, as you note.
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.
Reacted by Ovi Trif
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:
- ldk-node
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) - ldk-node Cut 0.0.100 #1044 — Track remaining funding-payment consistency issues after
ChannelMonitor::best_block_updatedbeforeChannelMonitor::transactions_confirmedmay needlessly delay broadcasting by a block #962 (Track remaining funding-payment consistency issues after #962 ldk-node#1044) - ldk-node Fix trailing semicolon warnings on latest rustc nightly #1049 — Guard payment records against splice funding rebroadcasts (Guard payment records against splice funding rebroadcasts ldk-node#1049)
- rust-lightning #4878 — Preserve interactive-funding classification on rebroadcast (https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/issues/4878)
- ldk-node Increase visibility for external integration tests #448 — Include onchain transactions in events (Include onchain transactions in events ldk-node#448)
- ldk-node lightning-block-sync::HttpClient::send_request_with_retry panics if bitcoind crashes #930 — Retry user-initiated splices across restarts (Retry user-initiated splices across restarts and disconnects ldk-node#930)
- ldk-node
ldk-node #962 — Keep funding payment records consistent across sync and classification (lightningdevkit/ldk-node#962)
ldk-node #1044 — Track remaining funding-payment consistency issues after #962 (lightningdevkit/ldk-node#1044)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.ldk-node #1049 — Guard payment records against splice funding rebroadcasts (lightningdevkit/ldk-node#1049)
This one is just a bug in the
lightningcrate - #4878, which you mention, not an issue with the approach per se.ldk-node #930 — Retry user-initiated splices across restarts (lightningdevkit/ldk-node#930)
Its not clear to me how this is realted?
@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())
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
Txidis 'known' to LDK and retrieve whether its a channel funding/channel close/splice in/splice out transaction.