Is your feature request related to a problem? Please describe.
If there is a force close with an outgoing htlc lnd is bumping very aggresively the fees for the onchain transactions. Lnd is using a target of 1 block for bumping the commitment and 6 blocks for sweeping the outgoing htlc to stage 2, because these htlcs are very time sensitive. If they are not swept until a related incoming htlc expires one can lose money. But in a very volatile mempool environment this can lead to high sweeping costs. Especially if there are fee spikes because miners haven't found a block for a longer time.
In PR #7535 we discussed already about a possible alternative for sweeping these time sensitive transactions in a more conservative way.
Describe the solution you'd like
Now here are my thoughts about a possible solution. I think it is not a good way to set a cap for a feerate or setting a higher but fixed confimation target. Both can lead to the result that the htlcs cannot be swept to the wallet until the expiry of a related incoming htlc.
The goal in these cases should be to push the funds safely into the wallet without the user having to intervene manually, e.g. by bumps or parameter changes when the mempool is full again. But sweeping should not be as conservative as it is now. It only becomes critical if the transactions are not confirmed by the time the HTLC downstream is due. So my idea is a dynamic confirmation target that is updated by lnd with each block_height and successively shortens until it eventually arrives at 1.
The due date of the downstream HTLC is to be called expiry_downstream. The dynamic confirmation target shall be calculated by max(expiry_downstream - confirmation_buffer_secondlevel - current_block_height;1).
Confirmation_buffer_secondlevel specifies how many blocks before the downstream HTLC is due the transaction must be confirmed . As the block height increases, the target would then decrease and lnd would bump more and more aggressively. However, one has the chance to get a confirmation at more favorable fees than in the status quo.
The whole thing would also have a positive side effect. It could move users to set higher TimeLockDeltas, because they can reduce the FC costs.
Describe alternatives you've considered
Setting hard caps of the feerate. Or other fix confirmation targets.
Interested to know what the thoughts of the devs are. Or if there are other ways to go.
Regards feelancer21
Is your feature request related to a problem? Please describe.
If there is a force close with an outgoing htlc lnd is bumping very aggresively the fees for the onchain transactions. Lnd is using a target of 1 block for bumping the commitment and 6 blocks for sweeping the outgoing htlc to stage 2, because these htlcs are very time sensitive. If they are not swept until a related incoming htlc expires one can lose money. But in a very volatile mempool environment this can lead to high sweeping costs. Especially if there are fee spikes because miners haven't found a block for a longer time.
In PR #7535 we discussed already about a possible alternative for sweeping these time sensitive transactions in a more conservative way.
Describe the solution you'd like
Now here are my thoughts about a possible solution. I think it is not a good way to set a cap for a feerate or setting a higher but fixed confimation target. Both can lead to the result that the htlcs cannot be swept to the wallet until the expiry of a related incoming htlc.
The goal in these cases should be to push the funds safely into the wallet without the user having to intervene manually, e.g. by bumps or parameter changes when the mempool is full again. But sweeping should not be as conservative as it is now. It only becomes critical if the transactions are not confirmed by the time the HTLC downstream is due. So my idea is a dynamic confirmation target that is updated by lnd with each block_height and successively shortens until it eventually arrives at 1.
The due date of the downstream HTLC is to be called expiry_downstream. The dynamic confirmation target shall be calculated by max(expiry_downstream - confirmation_buffer_secondlevel - current_block_height;1).
Confirmation_buffer_secondlevel specifies how many blocks before the downstream HTLC is due the transaction must be confirmed . As the block height increases, the target would then decrease and lnd would bump more and more aggressively. However, one has the chance to get a confirmation at more favorable fees than in the status quo.
The whole thing would also have a positive side effect. It could move users to set higher TimeLockDeltas, because they can reduce the FC costs.
Describe alternatives you've considered
Setting hard caps of the feerate. Or other fix confirmation targets.
Interested to know what the thoughts of the devs are. Or if there are other ways to go.
Regards feelancer21