lnutil: make minimum channel funding amount configurable

[nothing-stops-this-train]

Rationale:

Electrum comes with a hardcoded constant (MIN_FUNDING_SAT) which specifies the smallest allowable lightning channel, set to 200,000 sats, roughly equivalent to $200 USD. This is a burdensome amount for new Bitcoin users and puts lightning out of reach for them. This is especially relevant to lightning since it is really designed for small payments in the first place.

Some minimum, however, is needed for funds safety since if a channel partner published an old channel state (in an attempt to steal), it must be economical to challenge that state on-chain.

Other popular lightning wallets like Zeus set this at 20,000 sats (the LND default). Given that LND is the most popular lightning node client, this is a good reference amount.

This change enables users to set their own risk tolerance and advises them about how to do so, while sticking with a conservative 50,000 sat default.

Solution:
The minimum channel funding amount was a hardcoded constant (MIN_FUNDING_SAT = 200_000). Lower it to a 50_000 sat default and expose it as a new config setting, LIGHTNING_MIN_FUNDING_SAT, mirroring the existing LIGHTNING_MAX_FUNDING_SAT.

All call sites that previously read the hardcoded constant now read the value from config, so it is loaded at startup and honored at runtime like any other config value. The Qt Preferences dialog (Tools -> Preferences -> Lightning) gains an editor for the setting, together with a warning describing the risks of small channels in a high onchain-fee environment.

MIN_FUNDING_SAT is kept in lnutil as the default value for the new config var.

[SomberNight]

The whole model breaks down if the capacity is comparable to (or less than) the onchain fees. Are you sure you understand? I would probably have to spend 10+ minutes to think all the implications through so I highly doubt the typical user has any idea.

For example, did you realise that adding an HTLC to the channel usually increases the size of the commitment transaction and the onchain fees needed? Meaning if the prevalent mempool feerates are high, you might not be able to add an HTLC at all. Notice that I have not mentioned trust or cheating here.

Having a large minimum is annoying a single well-defined time: when the user wants to open a channel. Having a small minimum is a lingering risk. It is also a constant looming danger for us that suddenly when the mempool fees spike we have to explain to all those users why their channels are unusable. It is bad UX at unexpected times.

Also note that ACINQ (and eclair in general by default) sets max_htlc_value_in_flight_msat to 45% of the capacity, meaning pending htlcs in either direction (separately-per-direction) cannot exceed 45%. So if you open a channel with ACINQ for 200k sats, actually the max invoice you are able to pay is 90k sats. Unless you are a Phoenix client because then you get special treatment. This is even more annoying if you open a small channel.

[SomberNight]

ref #9519

[nothing-stops-this-train]

You are right to point out the max_htlc_value_in_flight issue, this is a concern in high-fee environments. There is obviously no "correct" answer, it comes down to the user and their risk tolerance. LND is the dominant lightning node software, not just for routing nodes but also for user wallets, and because of that, lightning users are used to regularly being able to move a much greater % of their channel balance than Eclair's defaults allow. Is that a good argument for allowing unsafe channel behaviour? Not really. As a dev you have to choose the right balance. Just because another wallet packages a convenient option, you shouldn't do the same thing if it's unsafe.

Your point about "one pain point now, avoid multiple pain points later" is sound. Do we apply this same logic to small UTXOs? A user can receive small on-chain payments only to find out they are functionally unspendable in a high fee environment, and of course, they would blame Electrum devs somehow for this even though it's a basic fact about how the Bitcoin network works. Just like "small lightning channels become useless in high-fee environments" is. A high-fee environment, in the typical lifecyle of a wallet, might also be considered either a one time or very rare occurrence.

Keep in mind that Electrum is the only mature desktop user wallet on Linux that supports lightning (and one of the few for other platforms). LND and other clients, of course, could also be run, but depend on complex plumbing like docker compose files. If users cant afford the $200 entry price and aren't a whiz in the terminal, they are essentially locked out of being able to use lightning at all. Again, not a great technical argument, but worth considering. I think a 200,000 sat limit is letting the perfect be the enemy of the good.

A $200 entry fee to use a system to cover what is essentially an edge case is steep. Even if the default minimum isn't lowered, I think letting the user have control of their own risk tolerance and adding a setting for this is valuable and it puts Electrum on par with other wallets. It also fits with the Bitcoin ethos about returning autonomy to the user.