LND's Deadline-Aware Budget Sweeper

[ismaelsadeeq]

@morehouse

By default, a linear fee function is used which starts at a low fee (determined by the minimum relay fee rate or an external estimator) and ends with the total budget being allocated to fees when the deadline is one block away. The initial batched transaction is published and a “fee bumper” is assigned to monitor confirmation status in the background. For each block the transaction remains unconfirmed, the fee bumper broadcasts a new transaction with a higher fee rate determined by the fee function.

This fee estimator is called using the deadline as the conf target

It seems that nodes are calling the long-term fee estimator (conf_target > 2) while expecting the transaction to confirm as soon as possible.

When you call estimateSmartFee with a confirmation target of n, you should not expect the transaction to confirm in the next block but rather within n blocks.

However, in this case, the transaction is time-sensitive, and you strictly want it to confirm before n blocks have elapsed.

Calling estimateSmartFee with n, and expecting it to confirm ASAP is not not ideal, and would likely not confirm ASAP. Instead, they should call estimateSmartFee with a conf_target of 1. If the transaction does not confirm within the next 1–2 blocks, they can then call the fee function to determine the fee rate they are willing to pay at that target based on the available budget (curve).

@morehouse

Problems

While external fee rate estimators can be helpful, they’re not perfect. And relying on them too much can lead to missed deadlines when unusual things are happening in the mempool or with miners (e.g., increasing mempool congestion, pinning, replacement cycling, miner censorship).

See the API proposal for Bitcoin Core’s improved fee estimator response, which provides the state of the mempool in the past with respect to miner’s mempool. This information could help clients make more informed decisions: Fee Estimation via Fee rate Forecasters tracking issue · Issue #30392 · bitcoin/bitcoin · GitHub

cc @ClaraShk