LND nodes overpay quite significantly on mutual closing TX's

I closed a couple channels with LND nodes recently and even though on-chain fees are quite cheep right now, my LND peers weren't willing to settle for anything less than >3k per Kw. Even July 21st, after a long period of mostly half empty blocks:

2020-06-21 23:32:01,321 INFO  f.a.eclair.Diagnostics n:031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda c:4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152 - IN msg=Shutdown(4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152,ByteVector(22 bytes, 0x0014bcb1a1bf6ed412195aecd655115854b1bde1ddae))
2020-06-21 23:32:01,321 INFO  f.a.e.i.Peer$MessageLogs n:031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda c:4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152 - IN msg=Shutdown(4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152,ByteVector(22 bytes, 0x0014bcb1a1bf6ed412195aecd655115854b1bde1ddae))
2020-06-21 23:32:01,328 INFO  f.a.e.i.Peer$MessageLogs n:031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda c:4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152 - OUT msg=Shutdown(4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152,ByteVector(22 bytes, 0x0014a39b3e0f892c18faef2fd320fbf51c4664efe494))
2020-06-21 23:32:01,328 INFO  f.a.eclair.Diagnostics n:031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda c:4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152 - OUT msg=Shutdown(4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152,ByteVector(22 bytes, 0x0014a39b3e0f892c18faef2fd320fbf51c4664efe494))
2020-06-21 23:32:01,757 INFO  f.a.eclair.Diagnostics n:031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda c:4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152 - IN msg=ClosingSigned(4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152,Satoshi(4422),d101921ccc660efccd0bdce133bbf14dbcbc01273755677d9297addab8f31f5b1dd244c9f26ca5dae23cd4c76204aecf30726e04fee6dcd05d5ba5594ea45795)
2020-06-21 23:32:01,758 INFO  f.a.e.i.Peer$MessageLogs n:031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda c:4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152 - IN msg=ClosingSigned(4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152,Satoshi(4422),d101921ccc660efccd0bdce133bbf14dbcbc01273755677d9297addab8f31f5b1dd244c9f26ca5dae23cd4c76204aecf30726e04fee6dcd05d5ba5594ea45795)
2020-06-21 23:32:01,758 INFO  f.a.e.channel.Channel n:031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda c:4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152 - received closingFeeSatoshis=Satoshi(4422)
2020-06-21 23:32:01,759 INFO  f.a.e.channel.Channel n:031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda c:4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152 - signed closing txid=79a23fb5372fe3807dc63d4b859e3e2abd1142ab0512ef2705028ae2ffcef525 with closingFeeSatoshis=Satoshi(4422)
2020-06-21 23:32:01,763 INFO  f.a.e.channel.Channel n:031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda c:4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152 - using feeratePerKw=253 for initial closing tx
2020-06-21 23:32:01,763 INFO  f.a.e.channel.Channel n:031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda c:4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152 - signed closing txid=3fa29ead7ebfd689a917e496078bca4d896b1ab8f4a625db5531019166fd391a with closingFeeSatoshis=Satoshi(2296)
2020-06-21 23:32:01,763 INFO  f.a.e.channel.Channel n:031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda c:4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152 - proposing closingFeeSatoshis=Satoshi(2296)
2020-06-21 23:32:01,766 INFO  f.a.e.i.Peer$MessageLogs n:031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda c:4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152 - OUT msg=ClosingSigned(4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152,Satoshi(2296),83285558bfe3633f282bc457f9d28cea2af9fe689dc618f7b53363268bcf051e14ab4b9876522d2de1e98bcd5ffc5798dd53259a95457cb3c7237f41797191d1)
2020-06-21 23:32:01,766 INFO  f.a.eclair.Diagnostics n:031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda c:4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152 - OUT msg=ClosingSigned(4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152,Satoshi(2296),83285558bfe3633f282bc457f9d28cea2af9fe689dc618f7b53363268bcf051e14ab4b9876522d2de1e98bcd5ffc5798dd53259a95457cb3c7237f41797191d1)
2020-06-21 23:32:02,126 INFO  f.a.eclair.Diagnostics n:031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda c:4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152 - IN msg=ClosingSigned(4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152,Satoshi(3980),8dcb6cda126c5e8867f89fdd1828c636b2b00605eb985aa9f34f05fe16fd73026c529f16a5cdb2545c3ce56161bcd225eeefd66497bf40f4a757516e8e9a5d55)
2020-06-21 23:32:02,126 INFO  f.a.e.i.Peer$MessageLogs n:031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda c:4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152 - IN msg=ClosingSigned(4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152,Satoshi(3980),8dcb6cda126c5e8867f89fdd1828c636b2b00605eb985aa9f34f05fe16fd73026c529f16a5cdb2545c3ce56161bcd225eeefd66497bf40f4a757516e8e9a5d55)
2020-06-21 23:32:02,127 INFO  f.a.e.channel.Channel n:031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda c:4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152 - received closingFeeSatoshis=Satoshi(3980)
2020-06-21 23:32:02,127 INFO  f.a.e.channel.Channel n:031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda c:4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152 - signed closing txid=c60609274d665122a2b3122a2fb97de0fbed30dc76e1188bf55fc295ab30da1e with closingFeeSatoshis=Satoshi(3980)
2020-06-21 23:32:02,131 INFO  f.a.e.channel.Channel n:031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda c:4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152 - signed closing txid=108a5cd42c97fbc846f774c6fc8b7f5dcdd0206820abef9afce9c2437c522340 with closingFeeSatoshis=Satoshi(3138)
2020-06-21 23:32:02,131 INFO  f.a.e.channel.Channel n:031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda c:4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152 - proposing closingFeeSatoshis=Satoshi(3138)
2020-06-21 23:32:02,135 INFO  f.a.e.i.Peer$MessageLogs n:031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda c:4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152 - OUT msg=ClosingSigned(4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152,Satoshi(3138),60cd2d6cba3ab57fe818515147879dbd3af3ec5d734f76f0f56ea83eebf82d832625d8b289d9c3eeec47f30374b96281e6c94735972c467eaf1f8ef111d4decd)
2020-06-21 23:32:02,136 INFO  f.a.eclair.Diagnostics n:031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda c:4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152 - OUT msg=ClosingSigned(4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152,Satoshi(3138),60cd2d6cba3ab57fe818515147879dbd3af3ec5d734f76f0f56ea83eebf82d832625d8b289d9c3eeec47f30374b96281e6c94735972c467eaf1f8ef111d4decd)
2020-06-21 23:32:02,844 INFO  f.a.eclair.Diagnostics n:031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda c:4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152 - IN msg=ClosingSigned(4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152,Satoshi(3138),7aba6619bcb262378d065767d01b2fe45ef855f99484f9f985d274d8f78953a71af8e25c40ef67011dd0b9b1528f8b103627c3c68e5d775f60c20574df784b7f)
2020-06-21 23:32:02,844 INFO  f.a.e.i.Peer$MessageLogs n:031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda c:4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152 - IN msg=ClosingSigned(4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152,Satoshi(3138),7aba6619bcb262378d065767d01b2fe45ef855f99484f9f985d274d8f78953a71af8e25c40ef67011dd0b9b1528f8b103627c3c68e5d775f60c20574df784b7f)
2020-06-21 23:32:02,844 INFO  f.a.e.channel.Channel n:031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda c:4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152 - received closingFeeSatoshis=Satoshi(3138)
2020-06-21 23:32:02,845 INFO  f.a.e.channel.Channel n:031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda c:4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152 - signed closing txid=108a5cd42c97fbc846f774c6fc8b7f5dcdd0206820abef9afce9c2437c522340 with closingFeeSatoshis=Satoshi(3138)
2020-06-21 23:32:02,846 INFO  f.a.e.channel.Channel n:031e643c3343d0561fcd7e303b468124e86b9ed3403ce82204bf93cc9d2546beda c:4acdd2fe1063110af6b40a0741d3663e9c772d605b436d0d65b09fd739804152 - closing tx published: closingTxId=108a5cd42c97fbc846f774c6fc8b7f5dcdd0206820abef9afce9c2437c522340

I know, fee estimation is a very complicated matter and there isn't a good solution at the moment, but would you consider using less expensive standard settings? Especially since it's always quite simple to get a TX unstuck via CPFP in the off chance it actually gets stuck for a significant amount of time.

Isn't that 3k the absolute fee? That's what's sent over the wire, not the fee rate.

I wish.... but no. Just look up the closingTxId=108a5cd42c97fbc846f774c6fc8b7f5dcdd0206820abef9afce9c2437c522340

https://blockstream.info/tx/108a5cd42c97fbc846f774c6fc8b7f5dcdd0206820abef9afce9c2437c522340

all my recent mutual closures with LND nodes have been even more expensive: https://1ml.com/node/02e9046555a9665145b0dbd7f135744598418df7d61d3660659641886ef1274844/channels?order=closedchannels

in fact, most have been even more expensive than this recent force closure: https://blockstream.info/tx/3ecebdf1a9312d43ae544032ced864f628f7ceca52ca7fe1d8bbeac29a8eb17a

So it seems to me, LND appoints force closures the exact same priority as mutual closures. Or is there any other explanation? For all mutual closures my node starts negotiating in the low triple digit area and my LND peers refuse to settle for anything less than 3k per Kw while initially proposing significantly more.

lnd proposes an initial fee rate to confirm within 6 blocks when receiving a cooperative channel closure request. There's no way to make this configurable at the moment, and we weren't able to CPFP back then. Now that we do, we can definitely lower that confirmation target and users can CPFP if desired.

Would you consider low balling the fee when you lower the target and maybe even give your users the option to set a custom target? In eclair the setting is already configurable and I had very good experience with a 144 block target. Tx's usually confirm within hours and as you said, even during high fee periods there is always the option to CPFP if the funds are needed quicker.

There is the downside of possibly externalizing fees, but the upside is that everyone saves a lot of money 95% of the time or more. I'd say this is the better approach. Especially when you make it configurable and people who are unhappy can adjust accordingly.

edit: can CPFP'd closure tx's be used for channel openings in LND? If yes, even the 'externalizing fees' thing wouldn't be much of an issue.

edit2: LNBIG seems to have big issues with how costly it is to run routing nodes as well: https://twitter.com/lnbig_com/status/1276595150266007553 They are certainly not providing liquidity in the most efficient way but the high cost of routing nodes is an issue even if you operate in the most cost effective way possible. I've been running a big routing node for 1.5 years now and by far the biggest cost are on-chain fees (which are bound to rise significantly sooner or later). Therefore I think reducing this cost should be a top priority. Low balling channel openings and mutual closures are the low hanging fruit. Being less aggressive with force closures works also well (I'm targeting 6 instead 2 blocks and this is much cheaper but still super safe since the fee estimation algos are so bad that even a 6 block target still overpays for next block confirmation in most cases). Last but not least, try avoiding channel failures as much as possible. They are happening constantly with LND nodes for all kind of weird reasons like this one:

2020-06-23 15:21:47,209 ERROR f.a.e.channel.Channel n:030c3f19d742ca294a55c00376b3b355c3c90d61c6b6b39554dbc7ac19b141c14f c:afd550ad05db99acf13e5d83729dfe764625e3da13f20a0ace5be7699768b9c8 - peer sent error: ascii='internal error' bin=696e7465726e616c206572726f72

This is with the Bitrefill node which had quite a few of those recently. Maybe @juscamarena has more infos on that.

I'm currently in the process of migrating a relatively large node from Eclair to LND and can concur that it would be desirable to really push down fees during these periods when mempool empties regularly. In Eclair I was also targeting 144 blocks, and a rebuttal against a cheating old state is the only time I would imagine timeliness is a concern.

According to this: [(https://lightning.engineering/posts/2020-04-30-lnd-v0.10/)] would this: [(https://github.com/lightningnetwork/lnd/pull/3821)] help enable very long block targets more safely since it would allow contingencies if intervention is needed?

Would you consider low balling the fee when you lower the target and maybe even give your users the option to set a custom target?

You can already configure it through the --sat_per_byte/--conf_target flags for most (if not all) commands involving on-chain transactions with the exception of force closes since that's already negotiated ahead of time.

can CPFP'd closure tx's be used for channel openings in LND?

Yes, see lncli wallet bumpfee. If you compiled from source, you'll need the walletrpc tag.

Last but not least, try avoiding channel failures as much as possible. They are happening constantly with LND nodes for all kind of weird reasons like this one:

We're already aware of this and have fixes coming soon.

According to this: [(https://lightning.engineering/posts/2020-04-30-lnd-v0.10/)] would this: [(https://github.com//pull/3821)] help enable very long block targets more safely since it would allow contingencies if intervention is needed?

@STAWKEYE yes, but that's concerning force closes. This issue is regarding cooperative closes, which allow you to set your desired fee as long as the remote party agrees.

Now that we do, we can definitely lower that confirmation target and users can CPFP if desired.

Is there anything happening in this regard? today I closed a couple channels with LND nodes after many hours of 1 s/b tx confirming and my peers still refused to close for anything less than 100 s/b. This is REALLY painful and stopping to waste so much money should be of utmost priority imho.


2020-08-08 18:52:49,338 INFO  f.a.eclair.Diagnostics n:0217890e3aad8d35bc054f43acc00084b25229ecff0ab68debd82883ad65ee8266 c:3fc886139755ab2dc749a17315b9e3b81454bdddd093ad212ba3738a019148a8 - IN msg=Shutdown(3fc886139755ab2dc749a17315b9e3b81454bdddd093ad212ba3738a019148a8,ByteVector(22 bytes, 0x0014b8998d302d294ba0e2543324bd80cd6ea5629790))
2020-08-08 18:52:49,338 INFO  f.a.e.i.Peer$MessageLogs n:0217890e3aad8d35bc054f43acc00084b25229ecff0ab68debd82883ad65ee8266 c:3fc886139755ab2dc749a17315b9e3b81454bdddd093ad212ba3738a019148a8 - IN msg=Shutdown(3fc886139755ab2dc749a17315b9e3b81454bdddd093ad212ba3738a019148a8,ByteVector(22 bytes, 0x0014b8998d302d294ba0e2543324bd80cd6ea5629790))
2020-08-08 18:52:49,339 INFO  f.a.e.channel.Channel n:0217890e3aad8d35bc054f43acc00084b25229ecff0ab68debd82883ad65ee8266 c:3fc886139755ab2dc749a17315b9e3b81454bdddd093ad212ba3738a019148a8 - using feeratePerKw=754 for initial closing tx
2020-08-08 18:52:49,339 INFO  f.a.e.channel.Channel n:0217890e3aad8d35bc054f43acc00084b25229ecff0ab68debd82883ad65ee8266 c:3fc886139755ab2dc749a17315b9e3b81454bdddd093ad212ba3738a019148a8 - signed closing txid=cc06926fc68110185df9da81428929c9c95af660be72809c4aeaddb5f4b08933 with closingFeeSatoshis=Satoshi(508)
2020-08-08 18:52:49,358 INFO  f.a.e.i.Peer$MessageLogs n:0217890e3aad8d35bc054f43acc00084b25229ecff0ab68debd82883ad65ee8266 c:3fc886139755ab2dc749a17315b9e3b81454bdddd093ad212ba3738a019148a8 - OUT msg=ClosingSigned(3fc886139755ab2dc749a17315b9e3b81454bdddd093ad212ba3738a019148a8,Satoshi(508),5edeee64d3e82b223eda8a13bc157e8ae73b27580100aedffac70dc3db7d1ea4554233fabba660701453634af1300d60608849c38041f113f4335185bbc6eeef)
2020-08-08 18:52:49,358 INFO  f.a.eclair.Diagnostics n:0217890e3aad8d35bc054f43acc00084b25229ecff0ab68debd82883ad65ee8266 c:3fc886139755ab2dc749a17315b9e3b81454bdddd093ad212ba3738a019148a8 - OUT msg=ClosingSigned(3fc886139755ab2dc749a17315b9e3b81454bdddd093ad212ba3738a019148a8,Satoshi(508),5edeee64d3e82b223eda8a13bc157e8ae73b27580100aedffac70dc3db7d1ea4554233fabba660701453634af1300d60608849c38041f113f4335185bbc6eeef)
2020-08-08 18:52:49,480 INFO  f.a.eclair.Diagnostics n:0217890e3aad8d35bc054f43acc00084b25229ecff0ab68debd82883ad65ee8266 c:3fc886139755ab2dc749a17315b9e3b81454bdddd093ad212ba3738a019148a8 - IN msg=ClosingSigned(3fc886139755ab2dc749a17315b9e3b81454bdddd093ad212ba3738a019148a8,Satoshi(20188),18e671ab23d1c232abcdb4a64ade47786bb2eb03093d8cc67c73838a4ac0079d7e585e42c0cb29dc1aac29de064c6bc0e5a6a551397db7019f938f8db729aafd)
2020-08-08 18:52:49,480 INFO  f.a.e.i.Peer$MessageLogs n:0217890e3aad8d35bc054f43acc00084b25229ecff0ab68debd82883ad65ee8266 c:3fc886139755ab2dc749a17315b9e3b81454bdddd093ad212ba3738a019148a8 - IN msg=ClosingSigned(3fc886139755ab2dc749a17315b9e3b81454bdddd093ad212ba3738a019148a8,Satoshi(20188),18e671ab23d1c232abcdb4a64ade47786bb2eb03093d8cc67c73838a4ac0079d7e585e42c0cb29dc1aac29de064c6bc0e5a6a551397db7019f938f8db729aafd)
2020-08-08 18:52:49,481 INFO  f.a.e.channel.Channel n:0217890e3aad8d35bc054f43acc00084b25229ecff0ab68debd82883ad65ee8266 c:3fc886139755ab2dc749a17315b9e3b81454bdddd093ad212ba3738a019148a8 - received closingFeeSatoshis=Satoshi(20188)
2020-08-08 18:52:49,481 INFO  f.a.e.channel.Channel n:0217890e3aad8d35bc054f43acc00084b25229ecff0ab68debd82883ad65ee8266 c:3fc886139755ab2dc749a17315b9e3b81454bdddd093ad212ba3738a019148a8 - signed closing txid=c0797d3f262707841586d810e38fbb576f3bef77de00bdae00374aff5a5fb696 with closingFeeSatoshis=Satoshi(20188)
2020-08-08 18:52:49,484 INFO  f.a.e.channel.Channel n:0217890e3aad8d35bc054f43acc00084b25229ecff0ab68debd82883ad65ee8266 c:3fc886139755ab2dc749a17315b9e3b81454bdddd093ad212ba3738a019148a8 - signed closing txid=3b52e988d7f3217a5a241cea1205d0db6589fb20fe3728c30c6e4bac1d7cd90b with closingFeeSatoshis=Satoshi(10348)
2020-08-08 18:52:49,484 INFO  f.a.e.channel.Channel n:0217890e3aad8d35bc054f43acc00084b25229ecff0ab68debd82883ad65ee8266 c:3fc886139755ab2dc749a17315b9e3b81454bdddd093ad212ba3738a019148a8 - proposing closingFeeSatoshis=Satoshi(10348)
2020-08-08 18:52:49,577 INFO  f.a.e.i.Peer$MessageLogs n:0217890e3aad8d35bc054f43acc00084b25229ecff0ab68debd82883ad65ee8266 c:3fc886139755ab2dc749a17315b9e3b81454bdddd093ad212ba3738a019148a8 - OUT msg=ClosingSigned(3fc886139755ab2dc749a17315b9e3b81454bdddd093ad212ba3738a019148a8,Satoshi(10348),07aadad4261a730cb040ab2343b1ada9994cebf4d36fe197d764153cbbdff23622ab0fc11a8c545c0a37bd95a8aaa5fb1c7addea51d78f3cb77b279e704c5584)
2020-08-08 18:52:49,577 INFO  f.a.eclair.Diagnostics n:0217890e3aad8d35bc054f43acc00084b25229ecff0ab68debd82883ad65ee8266 c:3fc886139755ab2dc749a17315b9e3b81454bdddd093ad212ba3738a019148a8 - OUT msg=ClosingSigned(3fc886139755ab2dc749a17315b9e3b81454bdddd093ad212ba3738a019148a8,Satoshi(10348),07aadad4261a730cb040ab2343b1ada9994cebf4d36fe197d764153cbbdff23622ab0fc11a8c545c0a37bd95a8aaa5fb1c7addea51d78f3cb77b279e704c5584)
2020-08-08 18:52:49,690 INFO  f.a.eclair.Diagnostics n:0217890e3aad8d35bc054f43acc00084b25229ecff0ab68debd82883ad65ee8266 c:3fc886139755ab2dc749a17315b9e3b81454bdddd093ad212ba3738a019148a8 - IN msg=ClosingSigned(3fc886139755ab2dc749a17315b9e3b81454bdddd093ad212ba3738a019148a8,Satoshi(18170),eea28ae096e277be658c51c750e5acf8ad856a1454b429e402ca0fe2b93988504d38e70156054f5bdedb06cb3cb0fba53d8649b01f6d986455634479d28d5296)
2020-08-08 18:52:49,690 INFO  f.a.e.i.Peer$MessageLogs n:0217890e3aad8d35bc054f43acc00084b25229ecff0ab68debd82883ad65ee8266 c:3fc886139755ab2dc749a17315b9e3b81454bdddd093ad212ba3738a019148a8 - IN msg=ClosingSigned(3fc886139755ab2dc749a17315b9e3b81454bdddd093ad212ba3738a019148a8,Satoshi(18170),eea28ae096e277be658c51c750e5acf8ad856a1454b429e402ca0fe2b93988504d38e70156054f5bdedb06cb3cb0fba53d8649b01f6d986455634479d28d5296)
2020-08-08 18:52:49,690 INFO  f.a.e.channel.Channel n:0217890e3aad8d35bc054f43acc00084b25229ecff0ab68debd82883ad65ee8266 c:3fc886139755ab2dc749a17315b9e3b81454bdddd093ad212ba3738a019148a8 - received closingFeeSatoshis=Satoshi(18170)
2020-08-08 18:52:49,691 INFO  f.a.e.channel.Channel n:0217890e3aad8d35bc054f43acc00084b25229ecff0ab68debd82883ad65ee8266 c:3fc886139755ab2dc749a17315b9e3b81454bdddd093ad212ba3738a019148a8 - signed closing txid=f5753ed3aa12d6c0b7989c466be3558f9cc0d6edea85c953bce62f8c15f162f5 with closingFeeSatoshis=Satoshi(18170)
2020-08-08 18:52:49,695 INFO  f.a.e.channel.Channel n:0217890e3aad8d35bc054f43acc00084b25229ecff0ab68debd82883ad65ee8266 c:3fc886139755ab2dc749a17315b9e3b81454bdddd093ad212ba3738a019148a8 - signed closing txid=5673b3dabf783c073f623806559c9783ed3707db8aedbe862845a2104d3d9d23 with closingFeeSatoshis=Satoshi(14258)
2020-08-08 18:52:49,695 INFO  f.a.e.channel.Channel n:0217890e3aad8d35bc054f43acc00084b25229ecff0ab68debd82883ad65ee8266 c:3fc886139755ab2dc749a17315b9e3b81454bdddd093ad212ba3738a019148a8 - proposing closingFeeSatoshis=Satoshi(14258)
2020-08-08 18:52:49,812 INFO  f.a.e.i.Peer$MessageLogs n:0217890e3aad8d35bc054f43acc00084b25229ecff0ab68debd82883ad65ee8266 c:3fc886139755ab2dc749a17315b9e3b81454bdddd093ad212ba3738a019148a8 - OUT msg=ClosingSigned(3fc886139755ab2dc749a17315b9e3b81454bdddd093ad212ba3738a019148a8,Satoshi(14258),a8700af1bbeaf2bc18b16ec409b1364c83f15f24df9ff3d15b70e03ecf4200bb02c49d89b944143e1bf6d6eb74190550c95eaadfba4425d690340dc98ff6a795)
2020-08-08 18:52:49,812 INFO  f.a.eclair.Diagnostics n:0217890e3aad8d35bc054f43acc00084b25229ecff0ab68debd82883ad65ee8266 c:3fc886139755ab2dc749a17315b9e3b81454bdddd093ad212ba3738a019148a8 - OUT msg=ClosingSigned(3fc886139755ab2dc749a17315b9e3b81454bdddd093ad212ba3738a019148a8,Satoshi(14258),a8700af1bbeaf2bc18b16ec409b1364c83f15f24df9ff3d15b70e03ecf4200bb02c49d89b944143e1bf6d6eb74190550c95eaadfba4425d690340dc98ff6a795)
2020-08-08 18:52:50,353 INFO  f.a.e.i.Peer$MessageLogs n:0217890e3aad8d35bc054f43acc00084b25229ecff0ab68debd82883ad65ee8266 c:3fc886139755ab2dc749a17315b9e3b81454bdddd093ad212ba3738a019148a8 - IN msg=ClosingSigned(3fc886139755ab2dc749a17315b9e3b81454bdddd093ad212ba3738a019148a8,Satoshi(14258),80be36373222b9d54f705077c508a4441aba74182a38c1f6ce8fe4038dabf78b2fc15cb9f47e183364d055fe3d360ce4753d18207d85f9fdedd77c0bbbdd366b)
2020-08-08 18:52:50,353 INFO  f.a.e.channel.Channel n:0217890e3aad8d35bc054f43acc00084b25229ecff0ab68debd82883ad65ee8266 c:3fc886139755ab2dc749a17315b9e3b81454bdddd093ad212ba3738a019148a8 - received closingFeeSatoshis=Satoshi(14258)
2020-08-08 18:52:50,354 INFO  f.a.e.channel.Channel n:0217890e3aad8d35bc054f43acc00084b25229ecff0ab68debd82883ad65ee8266 c:3fc886139755ab2dc749a17315b9e3b81454bdddd093ad212ba3738a019148a8 - signed closing txid=5673b3dabf783c073f623806559c9783ed3707db8aedbe862845a2104d3d9d23 with closingFeeSatoshis=Satoshi(14258)
2020-08-08 18:52:50,356 INFO  f.a.e.channel.Channel n:0217890e3aad8d35bc054f43acc00084b25229ecff0ab68debd82883ad65ee8266 c:3fc886139755ab2dc749a17315b9e3b81454bdddd093ad212ba3738a019148a8 - closing tx published: closingTxId=5673b3dabf783c073f623806559c9783ed3707db8aedbe862845a2104d3d9d23

Is there anything happening in this regard? today I closed a couple channels with LND nodes after many hours of 1 s/b tx confirming and my peers still refused to close for anything less than 100 s/b

It's difficult as in that situation you either need to chose to not compromise on their preference, or just end negotiation and try again. On our end the only thing we can do that isn't burdensome on the user (non-interactive) is to add a new flag to let users override the default value on start up.

On our end the only thing we can do that isn't burdensome on the user (non-interactive) is to add a new flag to let users override the default value on start up.

That would be a very big help IMHO. I think most people are just not aware of the issue. If something like this would be implemented together with some sort of explanation (either via the prompt itself or via the change logs or both) this could help alleviate the issue a fair bit!

I decided to increase the fees (3x):

saturated channels 3000 ppm (0.3%)

balanced channels 6000 ppm (0.6%)

depleted channels 12000 ppm (1.2%)

private channels (payer pays aside private payee) 18000 ppm (1.8%)

and this: https://twitter.com/lnbig_com/status/1299320526507311104

Unfortunately, the real balance at all nodes is slowly decreasing every day, despite the fees. It is difficult to understand the reason, because the funds are scattered in different places that are constantly changing: pending/opening/closing channels, wallets and etc.

I'm pretty sure, 90% of those losses LNBIG can't quite pin down is due to the crazy high onchain fees LND is wasting with the current standard settings. I think not working on how funds are currently wasted unnecessarily on fees risks losing significant network liquidity due to node operators becoming fed up with constantly losing money.

Any progress on this? It keeps hurting me and probably everyone else a lot: https://github.com/ACINQ/eclair/issues/1583

Nothing yet, but https://github.com/lightningnetwork/lnd/issues/4732 was just opened. We might be able to address it for the next major release (v0.12.0).

Please do! The fees are seriously painful and overpaying is such an unnecessary waste!

lightningnetwork / lnd

LND nodes overpay quite significantly on mutual closing TX's #4413