Allow LN users to see current CTX on-chain fees (s/vb) and allow them to guide CTX on-chain fee rate.

[brianddk]

The LND wallet allows users to guide the fee choice on commitment transactions exchanged during lighting operations. The LND guidance is simple { low, medium, high }, but useful none the less. It would be useful to offer the same controls in Electrum to request fee choices accordingly. In parity with this feature, it would be useful to show what the on-chain fee (s/vb) was used in the last exchange of commitment transactions, and a possible button to manually refresh commitment transactions in the event that the channel has been idle over a period of rapid fee escalation. Although decoding the data returned by get_channel_ctx() can provide this on desktop, it's not a realistic option in mobile.

Correction

{ ECONOMICAL, CONSERVATIVE } are the modes, not { low, medium, high }

[SomberNight]

it would be useful to show what the on-chain fee (s/vb) was used in the last exchange of commitment transactions

The desktop qt GUI shows this (added recently in d4f3192).

The LND wallet allows users to guide the fee choice on commitment transactions exchanged during lighting operations. The LND guidance is simple { low, medium, high }, but useful none the less.

How does that work exactly? Is this a persistent preference, global for all channels?

a possible button to manually refresh commitment transactions in the event that the channel has been idle over a period of rapid fee escalation

Hmm... Is this something you've seen in some other wallet?

[SomberNight]

it would be useful to show what the on-chain fee (s/vb) was used in the last exchange of commitment transactions

The desktop qt GUI shows this (added recently in d4f3192).

Added to qml GUI in 16eec8d

[brianddk]

How does that work exactly? Is this a persistent preference, global for all channels?

I think it uses the estimatefee variable in lnd.conf. It's referenced as feeMode in the fetchEstimate method, which looks to call into the estimatesmartfee bitcoind RPC.

Hmm... Is this something you've seen in some other wallet?

No, I haven't seen a commitment refresh message in other wallets, and perhaps it is a protocol question that should be added via BOLT. But was curious if the Electrum LN team thought it possible using the current LN protocol spec revision?

Added to qml

Thx!

[SomberNight]

a possible button to manually refresh commitment transactions in the event that the channel has been idle over a period of rapid fee escalation

Hmm... Is this something you've seen in some other wallet?

No, I haven't seen a commitment refresh message in other wallets, and perhaps it is a protocol question that should be added via BOLT. But was curious if the Electrum LN team thought it possible using the current LN protocol spec revision?

The ctx fees are decided by the channel opener. So in the case of Electrum, in practice always the local client. The opener can send the update_fee message to change the fees and then they can send commitment_signed to create a new ctx. This is all part of the BOLTs, and it is ~independent of sending HTLCs.

The current client logic for years has been that we use the bitcoind estimatesmartfee (conservative) 2-block rate to set the fee to, and we refresh it if it changed by more than 2x.
I've just recently changed this to be a bit more aggressive re adjusting upwards (but not downwards) in e6a0455.

So what you suggest, to do this manually, would certainly be technically possible (for the channel-opener party), however I have some reservations if it's a good idea for the UI. It would probably be preferable to make the automatic logic smarter instead.

The LND wallet allows users to guide the fee choice on commitment transactions exchanged during lighting operations. The LND guidance is simple { low, medium, high }, but useful none the less.

How does that work exactly? Is this a persistent preference, global for all channels?

I think it uses the estimatefee variable in lnd.conf. It's referenced as feeMode in the fetchEstimate method, which looks to call into the estimatesmartfee bitcoind RPC.

Right. I meant to ask not where the estimate comes from, but how the user-facing setting-it part works and what it affects. Where is this { low, medium, high } set? And is that set per-channel, or is it a global singleton setting?
Also, what does it affect anyway, is it only for the update_fee message, or also perhaps re sweeping behaviour?
If you have a link to some docs, even just the name of this setting that has these { low, medium, high } values, I can look it up.

[brianddk]

If you have a link to some docs, even just the name of this setting that has these { low, medium, high } values, I can look it up.

I misspoke, { low, medium, high } is incorrect. The actual user setting is the estimatefee variable in lnd.conf and the two settings are { ECONOMICAL, CONSERVATIVE }. This setting looks to be a pass-thru for the bitcoind backend RPC which uses the exact same { ECONOMICAL, CONSERVATIVE } in it's estimatesmartfee RPC

Correction

estimatemode setting, not estimatefee setting

[SomberNight]

If you have a link to some docs, even just the name of this setting that has these { low, medium, high } values, I can look it up.

I misspoke, { low, medium, high } is incorrect. The actual user setting is the estimatefee variable in lnd.conf and the two settings are { ECONOMICAL, CONSERVATIVE }. This setting looks to be a pass-thru for the bitcoind backend RPC which uses the exact same { ECONOMICAL, CONSERVATIVE } in it's estimatesmartfee RPC

I see. So it is a global singleton setting in lnd, that affects all feerate estimates.

[brianddk]

Here's to doc page on the estimatemode setting.

https://docs.lightning.engineering/lightning-network-tools/lnd/optimal-configuration-of-a-routing-node#high-fee-environment

[SomberNight]

Given that the current fees are now shown in the UI, what exactly remains to be done? The suggestion is a bit unclear. Or can the issue be closed? If not, please also change the title.