[bug]: can't bump fee of a coop closed channel

[rkfg]

Background

The channel point: https://mempool.space/tx/e49ddf72ead7445430f8e3dae014fa415282fd4c28ebced17d41a7606293abb0#vout=1

It was coop closed by Boltz long ago, right before the ordinals spam began. The tx never confirmed and was purged from my mempool I suppose. Now I try to bump the fee using lncli wallet bumpclosefee --conf_target 6 e49ddf72ead7445430f8e3dae014fa415282fd4c28ebced17d41a7606293abb0:1, however the command exits without any errors or success messages (I expect {} if it succeeds), there are no messages in the log either. I expect this command to use CPFP to bump my tx by spending my output but it doesn't seem to happen.

Your environment

• version of lnd lnd-v0.17.3
• which operating system (uname -a on *Nix) Raspbian arm64
• version of btcd, bitcoind, or other backend bitcoind v25.0.0
• any other relevant environment details

[Roasbeef]

If the fee rate of the transaction you want to bump is below the current mempool exclusion rate, then CPFP may not work. For CPFP to work, the node you're sending the tx to needs to have the parent transaction. It won't have the parent transaction if it was "dropped from the mempool".

There's an upcoming improvement to the protocol that enables the co-op close txn to be RBF'd. This would help your case as the parent transaction is 2 sat/vbyte rn.

[rkfg]

Can't both txs be broadcasted together so that their combined fee rate is above the purge limit? Also, shouldn't there be at least some error reported back from that command? Currently it's impossible to tell whether it worked or not and why.

And what should I do now to recover the funds?

[Roasbeef]

Can't both txs be broadcasted together so that their combined fee rate is above the purge limit?

In theory yes, but in practice no. The Bitcoin protocol doesn't yet support "package relay", which is the feature that would allow both of them to be broadcasted in tandem.

Also, shouldn't there be at least some error reported back from that command

After we merge #8345 we'll detect situations like this up front.

But with the way the "mempool" works, we won't know for sure. You only know when something is mined. Even if the first peer accept the txn, all their peers may have a feefiltervalue that causes them not accept the transaction.

And what should I do now to recover the funds?

Unfortunately, all you can do is wait (lower fees to the point where the parent tx is accepted by itself), or try to use some "transaction acceleration" service.

[rkfg]

Thanks for the comprehensive answer! This is truly sad. Does lnd rebroadcast this tx automatically until the tx gets into mempool or should I restart it to do that? I remember some fixes in this area but not sure if they cover this situation.

[Roasbeef]

This is truly sad

Yeah, I wish we had better tools at this point in the venture :/

Does lnd rebroadcast this tx automatically until the tx gets into mempool or should I restart it to do that? I remember some fixes in this area but not sure if they cover this situation.

Yeah lnd will automatically rebroadcast.

One thing I'm working on in the background is a tx accelerator that can operate purely over LN, so keysend to bump a fee for something. Needs some additional entities involved though.

[rkfg]

Good, then I suppose nothing can be done about it now. Thanks for the help!

[rkfg]

So, the channel has finally been closed as the fees dropped. However, the issue was still standing. I tried lncli wallet bumpclosefee --conf_target 1 e49ddf72ead7445430f8e3dae014fa415282fd4c28ebced17d41a7606293abb0:1 but it returned nothing and didn't bump the fee while it should have: the purge cut off at the time was below 2 sat/vB (which is the original fee). I only managed to bump the fee using my own output (CPFP) directly with lncli wallet bumpfee --conf_target 1 --force 49a4185267c68b9c9ebe90b178ba6567f37334a17a7b523a996595217a3ccabb:1. Then a new tx was created and broadcast, however, even then the combined fee was too low, about 10.7 sat/vB while the median fee in the last blocks was around 18 sat/vB so I waited for another day or two until it confirms. This command returned {}. Looks like something isn't right.

[guggero]

The bumpclosefee command is only for force closes. That was made more clear in a recent PR (#8350, not yet in a released version).
So using lncli wallet bumpfee is correct.

Did you specify a fee rate when using lncli wallet bumpfee? If not, a rate is estimated which might be too low. The response of {} just means "no error happened". See #7762

[rkfg]

The bumpclosefee command is only for force closes. That was made more clear in a recent PR (#8350, not yet in a released version).

I suppose it wouldn't be hard to extend it to co-op closes as well? We know our output and we can perform CPFP. Otherwise I need to manually look up the close tx and my output.

Did you specify a fee rate when using lncli wallet bumpfee?

I specified --conf_target 1, I think it's mutually exclusive with --sat_per_vbyte? Also I use feeurl=https://nodes.lightning.computer/fees/v1/btc-fee-estimates.json because of #7756, can't risk it. But I hope those estimates are good enough to calculate the right fee for CPFP.

[Roasbeef]

This PR will allow for natively doing a fee bump (via RBF) on a co-op close channel: #8453

[Roasbeef]

I suppose it wouldn't be hard to extend it to co-op closes as well? We know our output and we can perform CPFP. Otherwise I need to manually look up the close tx and my output.

Depends if it fell out of the mempool or not. Architecture wise, it is possible, the first step is that the sweeping module is made aware of the co-op close outputs.

We can morph this issue to track the implementation of that feature.