pull down to refresh
0 sats \ 6 replies \ @ZezzebbulTheMysterious 15 Dec 2023 \ on: PSA to Node Operators: Check coop-close-target-confs lightning
This happened to me today on my LND node, with the CPFP tx at 620 sat/vB. (reported as 2x overpayed). The force close cost almost 6x the value of the channel recovered.
This channel was not even created by me. Someone established a 1M sat channel to me, and caused my node to burn 280k in fees on force close and HTLC timeout.
The CPFP transaction cost ~200k sat, with total fees being close ~280k. Total amount recovered in local balance was 50k.
This all seems broken in this environment, and is highly discouraging as a node operator. I have never had such issues with CLN.
Wait… doesn’t the channel opener pay for a force close. Did you manually initiate a CPFP? I’m puzzled as to how this could have come from your pocket.
reply
Yes -- my understanding was the channel opener paid for the close, I did not initiate the CPFP manually. There were 3 tx's, and the final one was claiming an HTLC timeout. It swept the hot wallet for the CPFP, then it swept it again to claim the HTLC timeout. I can share the tx's if you wish.
All this happened about 4 hours ago, without any action from me specifically.
I did not think this could happen either, but in my experience LND just burns sats...
reply
Running a lightning node is certainly a way to spend Bitcoin.
What you are describing almost sounds like a watchtower penalty. I wonder if something got FUBAR on your node and it sent an older state in the force close, leading to a punishment txn… but I don’t see anything from today on this list: https://forkmonitor.info/lightning
Or maybe this is a successful attack vector being implemented in the wild… I am curious to see the txns if you don’t mind sharing. Just to be clear, you initiated the force close? Or they did?
It sounds like the force close was initiated while a pending ln txn was running, which is a little sus.
reply
Force close :
https://mempool.space/tx/75d9034d016c697f59f7faa6fcf51b365a0fb29c0d96bbb253e05465d9b02362
Expensive CPFP (213k sat!):
https://mempool.space/tx/318420de2ba3d7383074a9ecd45f0e9286d29f7295ca51680498611d8084d383
Expired HTLC claim (64k sat):
https://mempool.space/tx/8a6ac4f11f9930c63d7c26cf524620098a4e92f9142b1b3564e96e8c91b68ebb
I am not sure who initiated the close. Its not reporting in Thunderhub, just 'closing'. I think when it is closed it reports remote or local close. I did not initiate any action from my side myself.
reply
Ah, I see what happened now. So it looks like someone sent an HTLC through that timed out while one of you was offline. This is IHMO one of the most horrible node operator situations.
If one of the nodes is offline when a pending HTLC expires, instead of being canceled by both nodes cooperatively, it triggers a force close of the channel to resolve the HTLC on chain. If you were the recipient of the incoming transaction, theoretically you would have that HTLC balance as input from the source (prior to expire)—so what got taken from you on chain should be in your LN balance (just as a balance shift incoming from another channel). This is my understanding of it anyway. This hasn’t happened to me yet…
I’ve also heard of people saying that htlcs can just get stuck when nodes are both online and trigger this. Maybe if you are both tor only and your ping time is really long and tor just shat the bed…
reply
Thank you for taking a look!
I think this would account for the HTLC expire tx, in that the sats are going to be in another channel.
I am at a loss on why it spent the whole onchain wallet on such high fees?
I think the bulk of the sats were spent from just broadcasting the claim tx's.
It blew away several small UTXOs, overspending to consolidate them.
Seems wise to have a minimal amount and few UTXO so high fees don't eat up large claims.
reply