pull down to refresh

LND's ability to manage onchain fees is driving me mad. Especially when closing a channel, I find it next to impossible to reliably estimate the fee at which the channel will be closed. This often leads to wasted precious sats by doubling the chosen fee but I also had the opposed situation where a transaction was broadcasted with a very low fee that took weeks to confirm (this is the worst case as I find it rude to lock up my channel partner liquidity for a long time).
What am I missing? How do you set a specific fee when dealing with onchain transactions using LND?
LN isn't trustless because when you open a channel, you are trusting your channel peer not to close it during an unreasonably high fee environment.
You think you own X% of the sats in your channel, but really, a miner owns some of those sats.
reply
What are your practical recommendations to manage the fees? From the UX point of view it's a nightmare. If I specify 23 sats/vByte to close a channel the final result often varies from 12 to 80 and it seams totally unrelated from the current mempool activity.
reply
0 sats \ 1 reply \ @anon 7 Jun
The problem here is that Lightning wasn't designed with replace-by-fee in mind.
The way coop closes should work, is you ask your counterparty to provide signatures for a whole bunch of different possible fee-rates, with you paying those fees. Equally, you should give your counterparty signatures to a whole bunch of possible fee-rates, with them paying those fees. Now either one of you can choose what fee-rate to use and how much money to spend.
Lightning didn't do that because the devs were lazy and there's been this weird distaste of RBF in some of the dev community.
reply
Thanks for the insight. Did you take part in the development of lightning software?
Anyway, from a practical point. What are your recommendations? I'd really like to set a fee to close a channel and to be able to trust it at least a bit.
reply