[Test Case?] Bumpfee of Commitment Tx way too late and not necessary

[ziggie1984]

Background

This issue can be related to any Lightning Implementation out there which implements Anchor Channels. I am reporting this issue to just bring awareness for a potential testcase (if its not already there).

I saw the following Commitment Tx onchain:https://mempool.space/tx/df0c4853f6ac69c79faac28235068ae8de766293a372b3147adcca0e79732c9d

nothing special so far, but take a look at the anchor which got obviously used to somehow bump the fee of the commitment tx, but way too late, so the Commitment Tx is already 50 Blocks confirmed until the anchor got confirmed. Regarding the timestamp of both transactions it looks like the anchor feebump happend ~9 hours later.

My guess is, that the node was offline when the commitment tx was broadcasted.

Could lnd behave in such a way? If not just close the issue

[Roasbeef]

Unless we have exact logging timestamps, it would be difficult to get the exact time frame. We'll target a specific block height and fetch a new estimate each time for it, but due to mempool murkyness, we don't actually know for sure if the new replacement will get accepted. Also given there's no way to reliably cancel a transaction, it's performed on a best effort basis (we use the anchor once a certain amount of blocks has passed).

[ziggie1984]

Thanks for your answer, can you point me in the direction where lnd does handle the logic of a anchor feebump of the commitment tx ? Could only find the anchorResolver which takes care of sweeping it after the commitment is safe

[yyforyongyu]

I think you are looking for sweepAnchors here.

[Crypt-iQ]

Without having logs, this is pretty hard to diagnose.

The node was probably offline for some time and possibly was at risk of funds loss:

• There was an outgoing HTLC with an expiry of 736897
• The commitment tx was confirmed at height 737001

This is about a 100 block delay. If the counter-party was running lnd, they didn't close the channel earlier because they didn't know the preimage.

This delay means that the call in sweepAnchors likely chose a deadline of 1 which means "choose a high fee".
However, it was confirmed 50 blocks after the commit transaction. When the contractcourt is notified of the commit tx confirmation, it makes the anchor sweep use the minimum fee-rate. However, this probably conflicts with RBF in this case.

What I don't know is why a 24sat/vbyte anchor sweep transaction took ~50 blocks to confirm. There is some logic in the sweeper to prevent a transaction with an unconfirmed parent from using a lower fee-rate, but the commit tx had a feerate of 10sat/vbyte.