[bug]: Repeated use of the same addresses during force close tx settlement

[kulisekf]

Background

While analyzing the forse close transaction with my node I found that the same address was reused. This address was used both in the case of the forse close transaction itself, and was also used in the case of Expired Lightning HTLC transactions as one of the output addresses. Within this behavior, I observed 2 inefficiencies of this solution:

1. reusing the same address when settling a force close transaction leads to a decrease in anonymity within lightning for this method of settlement, as I was able to determine which UTXOs belong to the same owner.

2. If I do not use the UTXO from this address in a new transaction within a few days, lnd will automatically forward this UTXO to the new address. It is always a transaction with 1 input and 1 output. As a result, compared to the case where a unique output address is always used instead of the same output address when settling a force close transaction, it creates completely unnecessary transactions that take up space in the block and at the same time a fee is paid for them completely unnecessarily. In this case, there are 3 such transactions, each with a size of 249B and fees of 62, 75 and 91 sat/vB. These are not dizzying volumes, but a certain inefficiency arises.

Force close TX ID: 77f29620fa92d67e5a46901359a158666a423ee140879a17ec25e3062bdd62a7
Reused address: bc1q265k2qlqm0aprhsnf9349hv6lhctf9mx88dnlsw048e59c55tnesaytsp2

Your environment

uname -mrsv

Linux 5.4.0-164-generic

bitcoind --version || btcd --version

Bitcoin Core version v26.0.0

lsb_release -a

Distributor ID: Ubuntu
Description:    Ubuntu 20.04.6 LTS
Release:        20.04
Codename:       focal

lncli --version

lncli version 0.17.3-beta commit=v0.17.3-beta

Steps to reproduce

Force close when there are unfinished HTLCs in the channel.

Expected behaviour

Node will use unique addresses to settle individual HTLCs.

Actual behaviour

It does not use unique addresses.

[Roasbeef]

How did you open these channels? bc1q265k2qlqm0aprhsnf9349hv6lhctf9mx88dnlsw048e59c55tnesaytsp2 a CSV delay output (so sweep after force close):

• https://mempool.space/tx/8d4a948e337076c82de4ea03bcaec2039c9da3d3120c2c85826ce0788f43bd27
• https://mempool.space/tx/8f0598771dacf048994687489ebb8819e961ff850c7e4a3046b1fdd9814a4cd8
• https://mempool.space/tx/9a62f385f628bcdb8073d2cc69829f96e70ea1e6a52178c7d091e433bf2485ab

Re-using would mean that both you and your channel peer in these cases used the same public keys for these 3 channels.

[Roasbeef]

Actually these are all from the same force close here: https://mempool.space/address/bc1q265k2qlqm0aprhsnf9349hv6lhctf9mx88dnlsw048e59c55tnesaytsp2

The script for delay after force close, is identical to the script for a second level HTLC claim:

• second level claim: https://github.com/lightningnetwork/lnd/blob/master/input/script_utils.go#L1504-L1512
• to self delay: https://github.com/lightningnetwork/lnd/blob/master/input/script_utils.go#L2008-L2014

Notice how they use the same delay + revocation key. The were derived using randomness unique to this particular commitment state, so they show up the same on chain.

Closing as things seem to be working as intended here.

If I do not use the UTXO from this address in a new transaction within a few days, lnd will automatically forward this UTXO to the new address.

Correct that we don't have to always sweep these uncontested outputs into a new address. However, by doing so, we always consolidate UTXOs up front into larger UTXOs. In times of high fees, if you didn't consolidate UTXOs in the past, many of your outputs end up being uneconomical.

We're doing a overhaul of our sweeping patterns tracked in this issue: #2285