Force Closes with large timeout recovery tx fee
2578 sats \ 5 comments \ @ZezzebbulTheMysterious 18 Oct lightning
I had a FC this week, the initial FC tx went out at a reasonable 5s/vb -- but the timeout recovery tx went out at 173! (overpaid 22x). Minimum on the block was 8. ~20k fee sat. :-(
How does it determine what fee to do the timeout recovery tx? By this I mean the tx that is broadcast after the initial FC and timeout period has expired, allowing recovery of the channel balance.
This is actually less time sensitive than the initial FC, so I don't know why it was done with such a high fee. It would be good to have it send the recovery with a low value at first. Both the FC and Recovery TX are both RBF, why would it even try a high value here first?
Does anyone have any insight into why the recovery TX costs so much?
Burning sats on fees during network congestion that far outstripping routing fees here.
write
preview
related posts
140 sats \ 1 reply \ @krawall 19 Oct
Normally when node peers communicate with each other, they will agree on blockchain fees periodically. What can happen is that if the last time the blockchain fees where agreed is when the blockchain fees were high. Then let's assume (because it was a force close anyway!) that one of the parties became unresponsive and then the force close will happen with the agreed high blockchain fee.
As per the "RBF", this is tricky because replace-by-fee creates a new transaction id and this new transaction fee may be unknown to the lightning node(s) in question.
LND handles bump fee with "child pays for parent" so that the original funding transaction goes through no matter what. If you were to bump a funding transaction with RBF then your channel will not get opened at least by your counterparty because they are looking for the original funding transaction to go through. For close it's surely the same, now for Force Close, I agree, it could just RBF but that's all really above my pay grade here :-)
reply
0 sats \ 0 replies \ @krawall 19 Oct
sorry for the above :"this new transaction fee" should of course say "this new transaction"...
reply
41 sats \ 1 reply \ @DarthCoin 19 Oct
The new Core 28 comes with nice improvements for these cases https://bitcoinops.org/en/bitcoin-core-28-wallet-integration-guide/
After a sufficient number of nodes upgrade on the network, the LN protocol may be updated to drop the “update_fee” message, which has been a source of unnecessary force closes during fee spikes for years now. With removal of this protocol message, commitment transactions could be set to a static 1 sat/vbyte feerate. With TRUC transactions, we can ensure that competing commitment transactions with anchor spends are allowed to RBF each other over the network, and if there are competing output spends from the same commitment transaction, that RBF can occur no matter which output is being spent. TRUC transactions are also allowed to be 0-fee, allowing reduction in spec complexity. With TRUC’s sibling eviction, we can also drop the 1 block CSV locktimes, since we are no longer overly concerned with what unconfirmed outputs are being spent, as long as each party can spend a single output themselves
reply
0 sats \ 0 replies \ @ZezzebbulTheMysterious OP 19 Oct
Oh fantastic. I know what I’m doing now. Thank you DC
reply
20 sats \ 0 replies \ @028559d218 19 Oct
I remember I closed a channel I had had open with a 'large' node... it wasn't a 'force close' just a regular close. And it went out at something like 80 sats/vbyte.
I don't know why it went out at such a high fee-rate... I certainly didn't select a high rate just the going rate at the time maybe a little higher. It wasn't a 'big deal' the channel had been great and had always worked. However I wish there were more transparency (?) why it closed at such a fee rate.
I believe that the value of the channel for as long as I used it far exceeded the opening and closing cost... however minimizing opening and closing costs is a good thing too.
reply