Custom On-chain Fee Rate for Loop Out?

[bushev]

Hi team,

I’m using Lightning Terminal on Umbrel to perform loop outs from the Lightning Network to on-chain BTC. A major issue I’m facing is the inability to manually set the on-chain fee rate.

The GUI only allows setting a confirmation target (starting from 100 blocks), which is too slow for my use case. I want the loop out to confirm as quickly as possible.

If I leave the field blank, the fee defaults to something like 1 sat/vbyte, which is way too low given the current network congestion. As a result, transactions get stuck in the mempool for a long time.

Is there a way—through Umbrel’s terminal, CLI, or config—to specify the exact fee rate (e.g., 15 sat/vbyte) manually?

Thanks!

[alexbosworth]

what fee are you seeing when you specify a fast confirmation target?

if it's really stuck at the maximum fee rate and you want to bump it even more than that you can do bumpfee

[bushev]

Thanks for the quick response!

The issue is that the only option I’m given in the GUI is to specify a confirmation target block number, which—due to validation rules—can only start at 100 blocks. That’s way too slow for my needs.

If I leave that field blank, the fee ends up being just a bit over 1 sat/vbyte, which results in the transaction getting stuck for a long time, especially with the current mempool congestion.

What I’d really like is the ability to set an exact fee rate, e.g., 15 sat/vbyte, directly when initiating the loop out.

Also, could you please clarify how exactly bumpfee works in this context? Is there a way to use it with a loop out that’s already been initiated through Umbrel? Some guidance or examples would be much appreciated.

[alexbosworth]

that sounds like a wrong validation then, it should allow for a fast conf target

@levmi this would correspond with the conf target argument

   --conf_target value           the number of blocks from the swap initiation height that the on-chain HTLC should be swept within (default: 9)

[levmi]

Are you using the litd binary UI or terminal.lightning.engineering?

[TwistedHardware]

Hello @levmi and @alexbosworth. I think the part that you are referring to as getting stuck is the "sweep" that the LND node does after the HTLC by Loop service is confirmed.

There is a problem that was introduced some time ago. Loop out currently completely ignores any sweep_conf_target you pass to it. To better understand this part, this is how Loop does it:

1. Loop initializes batcherOpts with loopOutSweepFeerateProvider.GetMinFeeRate
2. The batcher is used in the executor which is used in the client
3. When loop out requests come, the client uses the batcher to handle them.
4. After Loop service publishes the HTLC, the batch sweeper, publishes a sweep transaction for its output to the destination address
5. The way the fee is calculated for the sweep, is using the batcher's fee provider (which is set to GetMinFeeRate)

Now here where the problem comes from. The way GetMinFeeRate works is by using GetConfTargetAndFeeRate. I went through this function and it basically uses the delta between the HTLC expiry and the current blockchain height to calculate its own conf_target and that target is the only thing that is used to calculate the fee. This target starts really high (I'm not 100% sure what is the default expiry of the HTLC, but I think it's 100). This makes the target 100 block which makes your fees calculation for the sweep 1sat/vbyte. The fee is also updated on each new block slowly increasing your fee but it could take hours to see any actual increase.

In short, the process is optimized to "sweep" your UTXO before the HTLC expires. It even goes into urgent mode when only 3 blocks are remaining until expiry. But since the default HTLC expiry is a high number, we end up with very low fees for hours until we start getting normal fees.

There are two ways to influence the behavior of this function but they both require a source code change and a recompile.

If my understanding of the source code is incorrect, please correct me and point me to how any custom target we are passing is getting to the sweeper's fee calculation.