LND consolidated two outputs from different channels while high fee rates

[nixonrichard1971]

Hi, I have this transaction:

438403e5ac15c03c43b95318ea398d7360fa4c88373211f7c147a32274c916a1

where LND decided to consolidated the two outputs that belonged to me from different remote closed channels that two different peers opened to me.

The issue is that the peers that did the remote close did actually set a decent fee rate (approx 10 sats/vByte), whereas the consolidation that LND made for my two outputs into one single UTXO set a very high fee rate (232 sats/vByte paying a total fee of 44,307 sats).

How can I avoid this from happening in the future? I don't want to end up in a situation that LND performs operations that I am not in control of, especially things seem to not work not so well when fees are high and I have seen more than once that channels get force-closed in this environment.

Thanks

[bitromortac]

Looking at the transactions, it seems like you had two force closes at about the same time and there were HTLCs on each of the transaction (would be great if you could confirm). The contract resolver in lnd then needed to sweep those HTLCs before the timeout in order to be able to cancel back HTLCs on incoming channels (to save them from force closing). This is important to break chains of force closes across nodes.

The closing transaction's fee rates are only ~10sats/vB for the bare transaction, but effectively they are higher due to anchor output sweeps, look for the effective fee rate (221 sats/vB) at https://mempool.space/tx/12f61eb96ec82562db4e310143555adc7a4621ac9d1ef58abc1d6df9b980812d.

[nixonrichard1971]

Thank you.

First, how can I check and confirm you that I had HTLC's pending in each of the transactions?

Second, what does it mean an "effective fee rate" for those transactions? What is the total mining fee paid in these transactions? Who paid that fee, the peer closing the channels?

Third, what is the purpose of the tx below? Sweeping the HTLC's are not done in the closing transactions? This transaction below as far as I understand only takes the two outputs as input and merges them into one output in an address that I control.

https://mempool.space/tx/438403e5ac15c03c43b95318ea398d7360fa4c88373211f7c147a32274c916a1#flow=&vin=0

[bitromortac]

First, how can I check and confirm you that I had HTLC's pending in each of the transactions?

You could look at lncli closedchannels and post the output here for the two channels in question.

Second, what does it mean an "effective fee rate" for those transactions? What is the total mining fee paid in these transactions? Who paid that fee, the peer closing the channels?

The effective fee rate means that there were two chained transactions in the mempool where a second transaction increased the fee rate of the first in order to have a higher fee rate (this is called child pays for parent - CPFP). The 10 sat/vbyte was paid by the channel opener, for the anchor output sweep (child transaction) I'm not sure, but I guess your peer because they seem to have force closed in order to time out the HTLC (need to check with closedchannels). The total mining fees would also need to take into account the anchor sweeps, e.g., https://mempool.space/tx/f286d9c48d224798e5f2f6687c80388e959382b1aa2a3b1800f7f13aeda718af.

Third, what is the purpose of the tx below? Sweeping the HTLC's are not done in the closing transactions? This transaction below as far as I understand only takes the two outputs as input and merges them into one output in an address that I control.

Sorry, I was wrong in my first post, those were to_remote outputs that were aggregated. The reason for this is to get those outputs back into the wallet scope, in order to make the funds recoverable from seed. But there are also HTLC sweeps like https://mempool.space/tx/9dcd9397f9c7da29172148da2ca4c0137f953b9599100999a0517f45c5374bbd.

[nixonrichard1971]

Hi thanks for the thorough explanations.

What does it mean to timeout the HTCL? Why does an HTLC get "stuck" sometimes and the peer would want to time it out and how can I avoid that happening so often? I had many channels closed because of this!

So, who paid the total mining fees for these two transactions?

And did I pay for the mining fee for getting the outputs aggregated into an UTXO that I control? If yes, how can I avoid in the future paying that gigantic mining fee if something happens when fees are high?

The output for the two channels are like this:
On one channel:
"channel_point": "ba49acbcba48ccb1f9543fe0ec07a8dcf8ce29a62764bd46e1413d7932511d85:13", "chan_id": "888600008882126861", "chain_hash": "000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f", "closing_tx_hash": "12f61eb96ec82562db4e310143555adc7a4621ac9d1ef58abc1d6df9b980812d", "remote_pubkey": "0364913d18a19c671bb36dd04d6ad5be0fe8f2894314c36a9db3f03c2d414907e1", "capacity": "2000000", "close_height": 816604, "settled_balance": "474408", "time_locked_balance": "0", "close_type": "REMOTE_FORCE_CLOSE", "open_initiator": "INITIATOR_REMOTE", "close_initiator": "INITIATOR_BOTH", "resolutions": [ { "resolution_type": "COMMIT", "outcome": "CLAIMED", "outpoint": { "txid_bytes": "2d8180b9f96d1dbc8af51e9dac21467adc5a554301314edb6225c86eb91ef612", "txid_str": "12f61eb96ec82562db4e310143555adc7a4621ac9d1ef58abc1d6df9b980812d", "output_index": 2 }, "amount_sat": "474408", "sweep_txid": "438403e5ac15c03c43b95318ea398d7360fa4c88373211f7c147a32274c916a1" }, { "resolution_type": "INCOMING_HTLC", "outcome": "TIMEOUT", "outpoint": { "txid_bytes": "2d8180b9f96d1dbc8af51e9dac21467adc5a554301314edb6225c86eb91ef612", "txid_str": "12f61eb96ec82562db4e310143555adc7a4621ac9d1ef58abc1d6df9b980812d", "output_index": 4 }, "amount_sat": "815222", "sweep_txid": "" } ], "alias_scids": [], "zero_conf_confirmed_scid": "0"

And on the other channel:

"channel_point": "2bd1b1b4a196ed8a5b755dc26d0e90afad2d1f17c4715d4f03f8098d4ee465e9:1", "chan_id": "864310697514106881", "chain_hash": "000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f", "closing_tx_hash": "8aeddca6e047a152c25ad35e04662322e93bc7f9e214ccdd9500ea03602b4324", "remote_pubkey": "035360b3bf6a997ed1bb943ccca2b7ef969b1e25a1ee1322d3c8acca7e34468edd", "capacity": "10000000", "close_height": 816604, "settled_balance": "103199", "time_locked_balance": "0", "close_type": "REMOTE_FORCE_CLOSE", "open_initiator": "INITIATOR_REMOTE", "close_initiator": "INITIATOR_BOTH", "resolutions": [ { "resolution_type": "COMMIT", "outcome": "CLAIMED", "outpoint": { "txid_bytes": "24432b6003ea0095ddcc14e2f9c73be9222366045ed35ac252a147e0a6dced8a", "txid_str": "8aeddca6e047a152c25ad35e04662322e93bc7f9e214ccdd9500ea03602b4324", "output_index": 2 }, "amount_sat": "103199", "sweep_txid": "438403e5ac15c03c43b95318ea398d7360fa4c88373211f7c147a32274c916a1" }, { "resolution_type": "INCOMING_HTLC", "outcome": "TIMEOUT", "outpoint": { "txid_bytes": "24432b6003ea0095ddcc14e2f9c73be9222366045ed35ac252a147e0a6dced8a", "txid_str": "8aeddca6e047a152c25ad35e04662322e93bc7f9e214ccdd9500ea03602b4324", "output_index": 3 }, "amount_sat": "815222", "sweep_txid": "" } ], "alias_scids": [], "zero_conf_confirmed_scid": "0"