trampoline payments with default 1% fee budget routinely fail with "fee budget exceeded"

[SomberNight]

• I tried buying beer, with trampoline enabled, 1% fee budget, and the payment failed with "fee budget exceeded"
• I tried sending sats to @f321x, going through two trampolines, "fee budget exceeded"
• payment amt was around 2500 sats in both cases
• after raising the fee budget to 2%, the payments succeeded. with fees around 47 sats

---

• did eclair raise default trampoline fees? did the ACINQ node in particular raise trampoline fees?
• should we change the default fee budget?
• should we at least make the slider for LIGHTNING_PAYMENT_FEE_MAX_MILLIONTHS more granular?

[accumulator]

* I tried buying beer, with trampoline enabled, 1% fee budget, and the payment failed with "fee budget exceeded"

* I tried sending sats to [@f321x](https://github.com/f321x), going through two trampolines, "fee budget exceeded"

* payment amt was around 2500 sats in both cases

* after raising the fee budget to 2%, the payments succeeded. with fees around 47 sats

With payment amounts around that level the base-fee (as opposed to ppm) gets relatively significant w.r.t fee-budget percentage. Especially when using trampoline, as the trampoline node must budget for the base fees along the route as well and add a margin for itself.

* should we change the default fee budget?

For e.g. 1 sat payments a fee of 20 sats is a bit ridiculous, but I think we should allow for a certain amount of base fee sats to avoid triggering the budget percentage.

* should we at least make the slider for `LIGHTNING_PAYMENT_FEE_MAX_MILLIONTHS` more granular?

IMO we should replace all of the following granular settings with a continuous curve (at least in the backend):

• LIGHTNING_PAYMENT_FEE_MAX_MILLIONTHS
• FEE_ETA_TARGETS
• FEE_DEPTH_TARGETS
• FEERATE_STATIC_VALUES

[f321x]

One possible approach could be showing a simple popup dialog in case the fee budget gets exceeded allowing the user to try the payment again with a temporarily increased budget.
This would be simple to understand for the user and wouldn't require either raising the default fee (going above 1% for all payments seems a bit expensive imo) or manually going to the settings twice to increase the fee and then decrease it again for a single payment (my typical workaround for this issue).

[SomberNight]

did the ACINQ node in particular raise trampoline fees?

Last time we saw lots of trampoline fee budget issues, it was due to the ACINQ node changing its min fees.
#9033

Hence I was curious if that might be related now. According to https://phoenix.acinq.co/faq, they are still using the same values:

What are the fees?
Sending via Lightning: 0.4 % + 4 sat

For e.g. 1 sat payments a fee of 20 sats is a bit ridiculous, but I think we should allow for a certain amount of base fee sats to avoid triggering the budget percentage.

Yes, that's already the case. That's what LIGHTNING_PAYMENT_FEE_CUTOFF_MSAT is for.

electrum/electrum/simple_config.py

Lines 756 to 760 in bd6dfc5

	LIGHTNING_PAYMENT_FEE_CUTOFF_MSAT = ConfigVar(
	'lightning_payment_fee_cutoff_msat', default=10_000, # 10 sat
	type_=int,
	short_desc=lambda: _("Max lightning fees to pay for small payments"),
	)

Is 10 sats not enough? Should that be raised?
but first we should re-test if 1% fees are enough with higher amounts, to see if constant cutoffs are related at all

IMO we should replace all of the following granular settings with a continuous curve (at least in the backend):

If a slider is so granular that it has hundreds of potential values, and I can't move it to some nice round number that I would prefer, that triggers my OCD. :D e.g. I am trying to move it to 6 and I am seeing values like 5.9912 and 6.037 when moving the slider and even after half a minute of trying, I can't lift my finger off on exactly 6, that triggers me :D

putting that aside -

• LIGHTNING_PAYMENT_FEE_MAX_MILLIONTHS

Ok.

• FEERATE_STATIC_VALUES

Ok.

• FEE_ETA_TARGETS

Could increase a bit but bitcoind does not provide distinct estimates for all values. see spesmilo/electrumx@bb3a2c9

Also, importantly, we have to request every target separately from the server, and we are polling them.

• FEE_DEPTH_TARGETS

We could increase the client's resolution but the resolution of the data provided by the server varies a lot between server implementations. The protocol does not specify what resolution the server should provide. https://electrum-protocol.readthedocs.io/en/latest/protocol-methods.html#mempool-get-fee-histogram
Also, the whole concept is flawed because the calculation treats each transaction individually and does not consider the mempool topology. For example, a very-high-fee-paying child tx is put at the top of the histogram even if mining it requires mining all its unconfirmed very-low-fee parents. Despite this inherent flaw, the histogram works very well in practice but nevertheless I am sceptical if greatly increasing the resolution in the current construction makes a lot of sense.

One possible approach could be showing a simple popup dialog in case the fee budget gets exceeded allowing the user to try the payment again with a temporarily increased budget.

Yes, maybe.
OTOH, another thing to manually test and which might regress.
We need automated tests :D

---

In any case, I would like to know what changed that resulted in these "fee budget exceeded" errors.

[SomberNight]

With payment amounts around that level the base-fee (as opposed to ppm) gets relatively significant w.r.t fee-budget percentage.

Ok, @accumulator is correct. It is about base fees.
I tried

• paying phone->T_acinq->T_electrumtrampoline->laptop, for invoice_amt=2500 sat, 1 % fee budget ==> budget exceeded
• paying phone->T_acinq->T_electrumtrampoline->laptop, for invoice_amt=2500 sat, 2 % fee budget ==> success
• paying phone->T_acinq->T_electrumtrampoline->laptop, for invoice_amt=5000 sat, 1 % fee budget ==> success
• paying phone->T_acinq->T_electrumtrampoline->laptop, for invoice_amt=10000 sat, 1 % fee budget ==> success

self-note: free testing on mainnet with patch on receiver-side:

diff --git a/electrum/lnpeer.py b/electrum/lnpeer.py
index cdea45f65f..7000596dfb 100644
--- a/electrum/lnpeer.py
+++ b/electrum/lnpeer.py
@@ -2556,6 +2556,7 @@ class Peer(Logger, EventListener):
             else:
                 return None, None
 
+        raise exc_incorrect_or_unknown_pd
         chan.opening_fee = None
         self.logger.info(f"maybe_fulfill_htlc. will FULFILL HTLC: chan {chan.short_channel_id}. htlc={str(htlc)}")
         return preimage, None

I think we should expose both LIGHTNING_PAYMENT_FEE_MAX_MILLIONTHS and LIGHTNING_PAYMENT_FEE_CUTOFF_MSAT in the GUI settings. I would personally likely set it to e.g. 50 sat and 1% atm. That would have made the beer purchase succeed. :D

Relatedly, perhaps long-term we should redesign the qml Settings page. Instead of a flat list of settings, we could have an extra layer of nesting, so that related settings are close together, but the length of the page is not overwhelming. That way we could expose more configvars/toggles easily. The desktop GUI essentially already has nesting in the form of the tabs.

In addition to exposing config.LIGHTNING_PAYMENT_FEE_CUTOFF_MSAT, we could also do @f321x's idea: if a payment fails with "fee budget exceeded", we could show a popup asking to retry with double the previous fee budget, potentially in an infinite loop. This would only ephemerally increase the fee budget for that one payment. It would not have to care about the base fee vs percentage fee distinction, instead it could just double the calculated absolute fee budget.