Feature request: better (manual) fee control

[viaj3ro]

In the last 4 months I paid a total of around ~0.22 BTC for roughly 600 channel opening/closing transactions even though my opening tx are always only paying a maximum of 1-5 sat/b and only maybe 75% of those channels were opened by myself. Pretty much all of those tx happened during times of insignificant network congestion. As soon as congestion goes up, things will get much worse and 0.22 BTC is already pretty bad!

If possible, this would be the best imho:

• manual fee setting whenever humanly possible (the algos just suck big time)
• stop overpaying (sometimes by more than 400% according to blockstream.info)
• use a standard target of 144 blocks instead of 2
• an option to manually adjust this target via config
• make it simple to get stuck TXs unstuck via CFP
• use less TXs, but that's already in the works: https://github.com/ACINQ/eclair/pull/1026
• get rid of unnecessary force closures (mostly an LND issue, afaik)
• option to combine closing and opening TXs
• option to open (and close) multiple channels with a single TX

Hopefully at least some of it can be implemented before the bull market starts picking up steam. Otherwise I fear that operating a routing node will become VERY expensive. I'm already paying hundreds of dollars each month...

[viaj3ro]

Would be nice to have a say or at least try to have some influence on the fee when a peer mutually closes a locally opened channel. Since peers have an interest in getting funds back fast but pay absolutely none of the fees they will always have an incentive to pay the highest fee possible for such channel closures. In the end it hurt's everyone and it would be nice to have a solution. One solution would be if every node advertises the highest and lowest fees in sats per byte they would accept as well as the highest and lowest block target. Peers can then decide if they are willing to accept or refuse channels with a respective node.

Example: lowest accepted block target: 72 highest accepted block target: 2016 lowest accepted fee: 1 s/vb highest accepted fee: 50 s/vb

If a peer has a range setting that overlaps, channel opening will be accepted. Otherwise the node sends an error message back with the accepted range and the funding party can decide if they wanna adjust their settings accordingly or rather not open a channel with the respective node.

Having both, a fee setting and a block target could be problematic but could probably be solved by requiring only one to be within range or prioritize one over the other.

Since fees are very dynamic and those settings are much less dynamic, transactions could get stuck. It should always be quite simple to get them unstuck via CPFP though.

It would probably be even better to have an advanced option to manually adjust the max accepted fee and block target upon channel opening not only via the config. This would provide much more flexibility.

[araspitzu]

1066 already handles mutual close, it will be possible to configure the feerate (see block target) to use when computing the commitment transaction (which is what is used in mutual close). The commitment fees are part of the negotiation of the channel opening, in fact they are inside the open_channel message sent to open a new channel, the receiving peer can refuse to accept the channel if the feerate is not satisfying. Unfortunately due to CPFP's rules we can't use it here but note that there has been proposals to integrate it in the commitment transaction.