Track funding transaction confirmation in ChannelMonitor

[wpaulino]

Without this, if a channel has already closed, we're unable to determine if the funding transaction has actually confirmed and we have balances to claim. An added bonus would be to also track all inputs of the funding transaction, so that we can tell solely within LDK if it's been double spent, and after some confirmations, can fully archive/discard the ChannelMonitor.

[elnosh]

hey, I was interested in picking this up and had some questions:

we're unable to determine if the funding transaction has actually confirmed and we have balances to claim

so the goal would be to check when the funding tx has reached minimum_depth for the channel to be ready and until then, do not return that as a ClaimableOnChannelClose from get_claimable_balances?

• And IIUC from how it works, if the funding was never confirmed and get_claimable_balances returns empty it should be made to eventually get the monitor discarded from ChainMonitor?

An added bonus would be to also track all inputs of the funding transaction, so that we can tell solely within LDK if it's been double spent

wondering if/how this should be done. If an input from the funding tx is double-spent to some other non-channel related tx then the monitor could be discarded from path of checking if the funding tx ever got confirmed?

[wpaulino]

so the goal would be to check when the funding tx has reached minimum_depth for the channel to be ready and until then, do not return that as a ClaimableOnChannelClose from get_claimable_balances?
And IIUC from how it works, if the funding was never confirmed and get_claimable_balances returns empty it should be made to eventually get the monitor discarded from ChainMonitor?

Not quite, we still want the balance to be returned while the channel is unconfirmed, otherwise the monitor could get archived.

I think this issue was mostly referring to a channel that never confirms. For inbound channels, we forget it after FUNDING_CONF_DEADLINE_BLOCKS without confirming. For outbound channels, we'll always keep it around.

wondering if/how this should be done. If an input from the funding tx is double-spent to some other non-channel related tx then the monitor could be discarded from path of checking if the funding tx ever got confirmed?

We could maybe use the Filter::register_output API on inputs to obtain their spending transactions. If they're spent by anything other than the expected funding transaction, we can immediately archive the monitor. This is needed to handle outbound channels that never confirm, otherwise we'll keep their monitors around forever.

[elnosh]

thanks for the response and apologies for the delay here.

If they're spent by anything other than the expected funding transaction, we can immediately archive the monitor. This is needed to handle outbound channels that never confirm, otherwise we'll keep their monitors around forever.

Got it, I see that the FundingScope in the ChannelMonitor only has the funding outpoint so we'd need to pass the transaction to the monitor to be able to track the inputs. So if an input is double-spent, then the monitor should get archived after that double-spent tx reaches ANTI_REORG_DELAY confs?

Regarding inbound channels, I was wondering how do those get pruned? I was playing around with a test where it:

• opened a channel between nodes up until funding_signed stage.
• connected FUNDING_CONF_DEADLINE_BLOCKS number of blocks without the funding tx in any of them.
• It reached the timeout threshold so a channel closure is triggered rom the channel manager but the monitor is still listed from the node with the incoming channel that has no balance.

I think this may have some overlap with #3384

[wpaulino]

Sorry for the delay here, somehow I missed this.

So if an input is double-spent, then the monitor should get archived after that double-spent tx reaches ANTI_REORG_DELAY confs?

Correct. We may still want to wait for ARCHIVAL_DELAY_BLOCKS to actually prune it to remain consistent, but we can consider it prunable as soon as ANTI_REORG_DELAY confs on a conflicting transaction.

Regarding inbound channels, I was wondering how do those get pruned?

Inbound channels with zero push_msat should be prunable already, my guess is that there's a claimable balance with 0 sats in it preventing it from happening.

[Anyitechs]

Hi! Is anyone currently working on this?

[wpaulino]

If @elnosh isn't then it should be available.

[elnosh]

hey, sorry I lost track of this. You can take it @Anyitechs

[Anyitechs]

hey, sorry I lost track of this. You can take it @Anyitechs

Great. Thanks!

[TheBlueMatt]

This is being done as a part of #3838