[bug]: Ghost UTXO (unconfirmed balance) after unsuccessful attempts to publish a sweep tx or due to collected anchors #7420

M1ch43lV · 2023-02-17T20:10:23Z

M1ch43lV
Feb 17, 2023

There are two types of ghost UTXO:

An UTXO has already confirmed by miners but lnd does not recognize it as confirmed or
a channel force-close binds an UTXO from the node's wallet to the 330 sat anchor with the purpose to sweep it back to the node's wallet with the fee of 1 sat/vb (can take a very long time to confirm dependent on the amount of unconfirmed tx in the mempool). However in the meantime the anchor was collected by someone else or did not enter mempool because of low fee's cut-off/purge. Lnd still assumes the UTXO is bound to the anchor which normally results in a new change UTXO after confirmation. This can never happen and the new UTXO still remains unconfirmed. Restarting lnd does not help to resolve this discrepancy.

The following section deals with case no. 2 and provides an easy solution to resolve the ghost UTXO problem.

TL;DR:
Rebroadcast the raw tx of the channel force close which led to the ghost UTXO. Enter lncli wallet publishtx <hex_tx of FC> to manually update lnd's utxo list.
Either use https://mempool.space entering the FC transaction hash to find the hex_tx (click on the red circle to reveal your hex_tx like in the picture) or you use the command lncli listchaintxns | grep -a37 "<tx_hash of FC>" to search for the raw_tx_hex if you know the tx_hash of your FC.
If you don't know your transaction id, then use https://amboss.space to find the correct FC transaction hash (enter your node's pubkey, click on the Closed Channels section, search for the interesting FC, click on Channel ID, there you click on the hash termed Closing Transaction). Clicking on this hash links you to mempool.space where you find your hex_tx (red circle).

03/10/2023
Once again, I have encountered a third failed sweep transaction in a row - now without collected anchor - leading to the creation of a ghost UTXO. You can find the FC transaction here: https://mempool.space/tx/fdbe4fe8bc7a7d710e85b8ce89255f84082e044a97fad1865acc727d820d3280
Node using: lnd v.0.16.0.rc1 and bitcoind 24.0.1
After examining lnd.log, I discovered what is causing the ghost UTXO. When an attempt to sweep an anchor of a force-closed channel is unsuccessful, a ghost UTXO may develop that cannot be published in the mempool due to high fees or being purged because of a full mempool. In general, LND transfers the FC anchor to the node's wallet by binding it to an unspent UTXO, which waits to be confirmed to a new UTXO. However, if confirmation fails after 10 attempts to publish to the mempool, LND drops the anchor, but the sweep transaction created by LND remains as a ghost UTXO for unknown reasons. Although the LND log may suggest otherwise, the lncli unspent command still shows the UTXO as unconfirmed. Is this related to a taproot problem?

The solution to remove the ghost UTXO is to manually publish the original hex transaction of the force close with lncli wallet publishtx <hex tx of FC> which returns a transaction ID and resolves the issue. The anchor is correctly accounted as a confirmed unspent UTXO without anchor sats (147 sats) to the node's wallet.

Here are three suggestions:

Introduce a general setting to LND that anchors should not be swept after the timelock of the FC has passed, creating a so-called drop possibility.
Avoid binding the anchor to an unspent UTXO if the mempool is full or confirmation fees are too high.
At the very least, bugfix this error of ghost UTXOs.

Lnd.log using grep "SWPR"

2023-03-10 03:53:54.766 [INF] SWPR: Candidate sweep set of size=1 (+1 wallet inputs), has yield=0.00000159 BTC, weight=677
2023-03-10 03:53:54.766 [INF] SWPR: Sweep candidates at height=780094 with fee_rate=253 sat/kw, yield 1 distinct txns
2023-03-10 03:54:24.767 [INF] SWPR: Candidate sweep set of size=1 (+1 wallet inputs), has yield=0.00000159 BTC, weight=677
2023-03-10 03:54:24.767 [INF] SWPR: Creating sweep transaction 8df7ff5d8c6bc5b4572e54e7d09e128bf3c66ec5eeab6119909fb75be2a04e90 for 2 inputs (fdbe4fe8bc7a7d710e85b8ce89255f84082e044a97fad1865acc727d820d3280:0 (CommitmentAnchor), 1300ccaf1c2f4fb95a06493edd3e93d3e1bb4d5a24403e0c7a76b7a1d857ee6d:0 (TaprootPubKeySpend)) using 253 sat/kw, tx_weight=725, tx_fee=0.00000183 BTC, parents_count=0, parents_fee=0 BTC, parents_weight=0
2023-03-10 03:54:24.774 [ERR] SWPR: input cluster sweep: unable to sweep inputs: publish tx: unmatched backend error: -26: mempool min fee not met, 183 < 195
2023-03-10 04:59:47.662 [INF] SWPR: Candidate sweep set of size=1 (+1 wallet inputs), has yield=0.00000159 BTC, weight=677
2023-03-10 04:59:47.662 [INF] SWPR: Sweep candidates at height=780095 with fee_rate=253 sat/kw, yield 1 distinct txns
2023-03-10 05:00:17.663 [INF] SWPR: Candidate sweep set of size=1 (+1 wallet inputs), has yield=0.00000159 BTC, weight=677
2023-03-10 05:00:17.664 [INF] SWPR: Creating sweep transaction 27de71ffe0517694bb1192c9e44f7cb7e2be03bf76c93dde7bed8aec066bfe91 for 2 inputs (fdbe4fe8bc7a7d710e85b8ce89255f84082e044a97fad1865acc727d820d3280:0 (CommitmentAnchor), 1300ccaf1c2f4fb95a06493edd3e93d3e1bb4d5a24403e0c7a76b7a1d857ee6d:0 (TaprootPubKeySpend)) using 253 sat/kw, tx_weight=725, tx_fee=0.00000183 BTC, parents_count=0, parents_fee=0 BTC, parents_weight=0
2023-03-10 05:06:12.486 [INF] SWPR: Sweep candidates at height=780096 with fee_rate=253 sat/kw, yield 0 distinct txns
2023-03-10 05:26:49.072 [INF] SWPR: Sweep candidates at height=780097 with fee_rate=253 sat/kw, yield 0 distinct txns
2023-03-10 05:32:13.067 [INF] SWPR: Sweep candidates at height=780098 with fee_rate=253 sat/kw, yield 0 distinct txns
...
...
2023-03-10 19:57:28.497 [INF] SWPR: Sweep candidates at height=780175 with fee_rate=253 sat/kw, yield 0 distinct txns
2023-03-10 20:04:27.654 [INF] SWPR: Sweep candidates at height=780176 with fee_rate=253 sat/kw, yield 0 distinct txns
2023-03-10 20:14:46.137 [INF] SWPR: Candidate sweep set of size=1 (+1 wallet inputs), has yield=0.00000159 BTC, weight=677
2023-03-10 20:14:46.138 [INF] SWPR: Sweep candidates at height=780177 with fee_rate=253 sat/kw, yield 1 distinct txns
2023-03-10 20:15:16.139 [INF] SWPR: Candidate sweep set of size=1 (+1 wallet inputs), has yield=0.00000159 BTC, weight=677
2023-03-10 20:15:16.184 [INF] SWPR: Creating sweep transaction 8e2d6a78f52ed220c50eb442c161a730b17ded92b626b7cb7544b099c6577cb5 for 2 inputs (fdbe4fe8bc7a7d710e85b8ce89255f84082e044a97fad1865acc727d820d3280:0 (CommitmentAnchor), 23b3a7f2b46570974372023802fcd7e7f8e1d791a2cda59a40a08f9f42c1252f:0 (TaprootPubKeySpend)) using 253 sat/kw, tx_weight=725, tx_fee=0.00000183 BTC, parents_count=0, parents_fee=0 BTC, parents_weight=0
2023-03-10 20:15:16.202 [ERR] SWPR: Publish sweep tx 8e2d6a78f52ed220c50eb442c161a730b17ded92b626b7cb7544b099c6577cb5 got error: transaction rejected: output already spent
2023-03-10 20:15:16.202 [WRN] SWPR: input fdbe4fe8bc7a7d710e85b8ce89255f84082e044a97fad1865acc727d820d3280:0: publishAttempts(10) exceeds MaxSweepAttempts(10), removed
2023-03-10 20:15:16.202 [INF] NTFN: Canceling spend notification: spend_id=59, outpoint=fdbe4fe8bc7a7d710e85b8ce89255f84082e044a97fad1865acc727d820d3280:0, script=0 07a1cff547e76fd7ee6cf18900fae5015bf9ea6a99c0eb2f69dcbf6cf5ac9674

Ghost utxo has been resolved by using the original transaction hex code of the force closed channel:

03/11/2023 10:43am
$ lncli wallet publishtx 02000000000101005f9d0b8f100e5829fea2075555933ebe6f05c7bc38040578dd2d6db79030f7000000000039423680044a0100000000000022002007a1cff547e76fd7ee6cf18900fae5015bf9ea6a99c0eb2f69dcbf6cf5ac96744a010000000000002200201d24b00a406cbff0389c9df63ccc60735a0bffcb8177a4d49844406591f6c46050390000000000002200204d9863fa1cbd0c1b2e9b57e45ae3358062d9de9443ad694bdb199bb622ee96ace4f50e0000000000220020463091a4cb13b86e2ef84c6c45f4d0a297dc5bddd526312f3f8bb20de1ebf25f040048304502210087afb27132706ccf686803dc2e1b58e2699389bba5ac3fb1cfc0639fe2c7b37602203587e80f1c7090b2666f418ec14d74eedfbdec92b795a91065a2cc2de52a86200147304402206318cc8d9b91955d5eff699c08c0960dc76e35e623d726aec4442739da965ee902207a2524a59f85ba9319e9e0836f8e0c36fb25a5b6e97aee5821486506f2788bec014752210284ccc0431d915958b308578b65e19b962eac84b8e0d85c7fc04a9b8b1bfffa6721037ef37de99f7d025069777b07b26b160d9d8a067ee23527e65a7f9fe84bf6da2a52ae21006e20
{
        "txid": "fdbe4fe8bc7a7d710e85b8ce89255f84082e044a97fad1865acc727d820d3280"
}

lnd.log
2023-03-11 10:43:10.461 [INF] LNWL: Inserting unconfirmed transaction fdbe4fe8bc7a7d710e85b8ce89255f84082e044a97fad1865acc727d820d3280

03/04/2023: Now using lnd 0.16.0.rc1
Another FC, another sweep. Again the anchor is collected by someone else. Lnd does not realize that the utxo is already accounted to the own wallet.

https://mempool.space/tx/ae9f2e338ee337df795d8ca1956bfd84589a2cf8c4201c7b9dfe27ab1d8bd75b

What I did to solve the problem:

I went a transaction before:
https://mempool.space/tx/d858c7a8dfca0659e626dce3cfd73afafdb7911b065086951450f36c68d2f63a
Took the transaction hex
https://mempool.space/api/tx/d858c7a8dfca0659e626dce3cfd73afafdb7911b065086951450f36c68d2f63a/hex
and broadcasted it with
lncli wallet publishtx <transaction hex>

Problem solved. LND realized now that the utxo is part of the node's wallet and now the missing / ghost UTXO is confirmed.

I would ask the developers of lnd to fix this behaviour that if the anchor of a FC is collected by someone else, that lnd nevertheless performs an update of the apparently unconfirmed utxo.

02/24/2023:
I think with the update of lnd 0.16.0.rc1 the bug of not detecting an already spent UTXO created with an external tool has been fixed:#7243

Using lnd version 0.15.5-beta and bitcoind 24.0.1
TL;DR
After a forced close channel lnd showed me an unconfirmed balance which allegedly did not enter the mempool. The channel was created with bos open-group.
The unconfirmed balance came from a remaiming sweep of expired htlcs of the FC.
The anchor of this sweep was lost respectively collected by someone else due to a RBF maneuver with changing the owner of the lightning anchor. With the missing anchor lnd did not realize that the remaining utxo was already spent and reported erroneously this over 4 days as unconfirmed balance until I broadcasted manually the transaction hash of the remaining transaction. Lnd then realized that the utxo was already spent and updated the onchain balance correctly.

Resolution of this problem:
lnd should check if the lightning anchor still belongs to the node, check if the utxo was already spent and correct the wrongly reported unconfirmed balance without manual intervention.

============= Here the report and according logs ==============

113966 sats not confirmed.

Likely related to #6241 and #7104
I think the last issue #7104 helped me to understand what is the problem of lost anchors ...

The persistent display of an unconfirmed balance began when a force closed of a channel was initiated due to expired htlcs:
https://mempool.space/tx/1ed22f68f4ec7badbc790f52cf2883cf092c1f9d4dddf90327636f68a1b61aba

As you can see the force close resulted in 4 outputs: The amount 0,03218734 BTC minus fee went to me. The amount of ‎0,0007662 BTC went to the other peer, and then two lightning anchors remained, one going to the other peer, and the other one which should normally go to my node, was snatched away by a anchor fee collector script.
https://mempool.space/address/bc1qps4jrqrxf6n34yeqmulp2w9dvp5xa0w0gaqpn7ew5vkw9r8ene2slpakxr

$ lncli listchaintxns
{
    "transactions": [
        {
            "tx_hash": "2c8e74cb1e4d76d260b1abb25464b6a56416683718bc74fc790578c555c4fd1c",
            "amount": "147",
            "num_confirmations": 0,
            "block_hash": "",
            "block_height": 0,
            "time_stamp": "1676374225",
            "total_fees": "0",
            "dest_addresses": [
                "bc1p8j4dttfwxwc8ep5s7ctepmn5zsnchxllul0468y0lzz6uqwvnn2s20zxfz"
            ],
            "output_details": [
                {
                    "output_type": "SCRIPT_TYPE_WITNESS_V1_TAPROOT",
                    "address": "bc1p8j4dttfwxwc8ep5s7ctepmn5zsnchxllul0468y0lzz6uqwvnn2s20zxfz",
                    "pk_script": "51203caad5ad2e33b07c8690f61790ee7414278b9bffe7df5d1c8ff885ae01cc9cd5",
                    "output_index": "0",
                    "amount": "113966",
                    "is_our_address": true
                }
            ],
            "raw_tx_hex": "02000000000102ba1ab6a1686f632703f9dd4d9d1f2c09cf8328cf520f79bcad7becf4682fd21e0000000000000000002eea47a79c90a93cb70b8805a5bad97b20
98d4ec30695e347e1797162b0f2ab8000000000000000000012ebd0100000000002251203caad5ad2e33b07c8690f61790ee7414278b9bffe7df5d1c8ff885ae01cc9cd502483045022100e1f5fd2
92dbbdb08118971ec794b9a79a0307b7f27b752fe9bca66e58ab7b84702201bea493456f1dcc50345d40f4b3c999fde0bacbddb936cd44862d4c07b6c3aab01282103b9efb326d5411db3e52202ae
bff0f5c87d4f857041b3a929b9f124ce59b6704dac736460b2680140d7f8852680fe753d052e4590900ad36075ce86c55d67bdab9c8aecf1fa7c00b5141b119f351ba9075778a9a36ae98970ff151
a7a87237fd208c39c50281876212dd90b00",
            "label": "0:sweep",
            "previous_outpoints": [
                {
                    "outpoint": "1ed22f68f4ec7badbc790f52cf2883cf092c1f9d4dddf90327636f68a1b61aba:0",
                    "is_our_output": false
                },
                {
                    "outpoint": "b82a0f2b1697177e345e6930ecd498207bd9baa505880bb73ca9909ca747ea2e:0",
                    "is_our_output": true
                }
            ]
        }

As you can see in the above command there are two previous outpoints:
1ed22f68f4ec7badbc790f52cf2883cf092c1f9d4dddf90327636f68a1b61aba:0 (is_our_output: false)
b82a0f2b1697177e345e6930ecd498207bd9baa505880bb73ca9909ca747ea2e:0 (is_our_output: true)

This is the lnd.log output of how the sweep 2c8e74cb1e4d76d260b1abb25464b6a56416683718bc74fc790578c555c4fd1c is generated out of the two outpoints and should enter the mempool:

2023-02-14 12:30:23.346 [INF] SWPR: Candidate sweep set of size=1 (+0 wallet inputs), has yield=0.03217848 BTC, weight=443
2023-02-14 12:30:23.712 [INF] SWPR: Creating sweep transaction f9fd2234d292be6afab20d617c32ee074f2ffd2dc926b39614144bc681b4d0b2 for 1 inputs (1ed22f68f4ec7badbc790f52cf2883cf092c1f9d4dddf90327636f68a1b61aba:3 (CommitmentToRemoteConfirmed)) using 2000 sat/kw, tx_weight=491, tx_fee=0.00000982 BTC, parents_count=0, parents_fee=0 BTC, parents_weight=0
2023-02-14 12:30:23.782 [INF] LNWL: Inserting unconfirmed transaction f9fd2234d292be6afab20d617c32ee074f2ffd2dc926b39614144bc681b4d0b2
2023-02-14 12:30:25.542 [INF] SWPR: Candidate sweep set of size=1 (+1 wallet inputs), has yield=0.00000159 BTC, weight=677
2023-02-14 12:30:25.934 [INF] SWPR: Creating sweep transaction 2c8e74cb1e4d76d260b1abb25464b6a56416683718bc74fc790578c555c4fd1c for 2 inputs (1ed22f68f4ec7badbc790f52cf2883cf092c1f9d4dddf90327636f68a1b61aba:0 (CommitmentAnchor), b82a0f2b1697177e345e6930ecd498207bd9baa505880bb73ca9909ca747ea2e:0 (TaprootPubKeySpend)) using 253 sat/kw, tx_weight=725, tx_fee=0.00000183 BTC, parents_count=0, parents_fee=0 BTC, parents_weight=0
2023-02-14 12:30:26.006 [INF] LNWL: Inserting unconfirmed transaction 2c8e74cb1e4d76d260b1abb25464b6a56416683718bc74fc790578c555c4fd1c
2023-02-14 12:30:43.385 [INF] WTCL: (legacy) Client stats: tasks(received=0 accepted=0 ineligible=0) sessions(acquired=0 exhausted=0)

However the commitment anchor of 1ed22f68f4ec7badbc790f52cf2883cf092c1f9d4dddf90327636f68a1b61aba:0 seems not belong to my node any more - as it was snatched away - and the transaction 2c8e74cb1e4d76d260b1abb25464b6a56416683718bc74fc790578c555c4fd1c did not enter the mempool.
https://mempool.space/tx/2c8e74cb1e4d76d260b1abb25464b6a56416683718bc74fc790578c555c4fd1c

The expired htlcs remained as unconfirmed balance and unspent utxo on my node until I decided to rebroadcast the hex encoded raw transaction because it has never entered the mempool.

As next step I entered following command:

$ lncli wallet publishtx "02000000000102ba1ab6a1686f632703f9dd4d9d1f2c09cf8328cf520f79bcad7becf4682fd21e0000000000000000002eea47a79c90a93cb70b8805a5bad97b2098d4ec30695e347e1797162b0f2ab8000000000000000000012ebd0100000000002251203caad5ad2e33b07c8690f61790ee7414278b9bffe7df5d1c8ff885ae01cc9cd502483045022100e1f5fd292dbbdb08118971ec794b9a79a0307b7f27b752fe9bca66e58ab7b84702201bea493456f1dcc50345d40f4b3c999fde0bacbddb936cd44862d4c07b6c3aab01282103b9efb326d5411db3e52202aebff0f5c87d4f857041b3a929b9f124ce59b6704dac736460b2680140d7f8852680fe753d052e4590900ad36075ce86c55d67bdab9c8aecf1fa7c00b5141b119f351ba9075778a9a36ae98970ff151a7a87237fd208c39c50281876212dd90b00"
 [lncli] rpc error: code = Unknown desc = transaction rejected: output already spent

However lncli says that it was already spent. So I used bitcoin-cli alternatively:

$ bitcoin-cli sendrawtransaction "02000000000102ba1ab6a1686f632703f9dd4d9d1f2c09cf8328cf520f79bcad7becf4682fd21e0000000000000000002eea47a79c90a93cb70b8805a5bad97b2098d4ec30695e347e1797162b0f2ab8000000000000000000012ebd0100000000002251203caad5ad2e33b07c8690f61790ee7414278b9bffe7df5d1c8ff885ae01cc9cd502483045022100e1f5fd292dbbdb08118971ec794b9a79a0307b7f27b752fe9bca66e58ab7b84702201bea493456f1dcc50345d40f4b3c999fde0bacbddb936cd44862d4c07b6c3aab01282103b9efb326d5411db3e52202aebff0f5c87d4f857041b3a929b9f124ce59b6704dac736460b2680140d7f8852680fe753d052e4590900ad36075ce86c55d67bdab9c8aecf1fa7c00b5141b119f351ba9075778a9a36ae98970ff151a7a87237fd208c39c50281876212dd90b00"
error code: -25
error message:
bad-txns-inputs-missingorspent

Same error, already spent.

Checking for pendingsweeps revealed this:

$ lncli wallet pendingsweeps
{
        "pending_sweeps": []
}
$ lncli listchaintxns

Wow, the unconfirmed balance is not found any more! But instead lnd found this new=old previously mentioned transaction b82a0f2b1697177e345e6930ecd498207bd9baa505880bb73ca9909ca747ea2e which is now listed and correctly assigned to my wallet as confirmed balance. Originally 113966 sats unconfirmed - fee of 147 sats = 113819 confirmed sats

        {
            "tx_hash": "b82a0f2b1697177e345e6930ecd498207bd9baa505880bb73ca9909ca747ea2e",
            "amount": "-143",
            "num_confirmations": 2123,
            "block_hash": "000000000000000000068aac09e93b84477b85464b8a57c02e59b9e725e13a1f",
            "block_height": 775057,
            "time_stamp": "1675551312",
            "total_fees": "143",
            "dest_addresses": [
                "bc1pzqevxm9ncyrs30wnp6vaszkqzl6c2vvn2zp5m2y44u2mcvuuvz6q5t72xm",
                "bc1q7uywg8djq7302dx0amfzfdajwwcns25nze789a"
            ],
            "output_details": [
                {
                    "output_type": "SCRIPT_TYPE_WITNESS_V1_TAPROOT",
                    "address": "bc1pzqevxm9ncyrs30wnp6vaszkqzl6c2vvn2zp5m2y44u2mcvuuvz6q5t72xm",
                    "pk_script": "51201032c36cb3c10708bdd30e99d80ac017f585319350834da895af15bc339c60b4",
                    "output_index": "0",
                    "amount": "113819",
                    "is_our_address": true
                },
                {
                    "output_type": "SCRIPT_TYPE_WITNESS_V0_PUBKEY_HASH",
                    "address": "bc1q7uywg8djq7302dx0amfzfdajwwcns25nze789a",
                    "pk_script": "0014f708e41db207a2f534cfeed224b7b273b1382a93",
                    "output_index": "1",
                    "amount": "4000095",
                    "is_our_address": true
                }
            ],
            "raw_tx_hex": "02000000000101fae2589f8d41ffbc5f5300d2753ec9d7b2187ce4afe7fc5d33297a761e025e4c0000000000ffffffff029bbc0100000000002251201032c36cb3
c10708bdd30e99d80ac017f585319350834da895af15bc339c60b45f093d0000000000160014f708e41db207a2f534cfeed224b7b273b1382a930140bb2a03117e8aca9ef0e4447f24b113e036a8c
e8690d72b7721ad53b2616187bac3802d84211f312bb0515c2f102864af97361a7dc700e458d61eb1d65c7e2c0800000000",
            "label": "bos open-balanced-channel",
            "previous_outpoints": [
                {
                    "outpoint": "4c5e021e767a29335dfce7afe47c18b2d7c93e75d200535fbcff418d9f58e2fa:0",
                    "is_our_output": true
                }
            ]
        },
--

nixonrichard1971 · 2023-07-05T19:48:55Z

nixonrichard1971
Jul 5, 2023

Hi, I have a similar issue. In this case, I've got many unconfirmed UTXO's possibly all linked to the same problem you describe here.

The problem seems to start with the force-closed of a channel i opened usinb balance of satoshis. Apparently the force-closed tx (locally closed, possibly due to expired HTLC’s) does not appear in my list of transactions, but I can track it down as I have the opening tx. if I track it down in the mempool, this force-closed tx does not appear as force-close in the description, but as multisig 2 of 2. That is weird. And is also weird that it does not appear in my list of tx’s.

Did you have the same issue, that the force-close tx did not appear in your tx list?

Now, the first tx with 0 confirmations in my list is apparently a doubled tx from the I guess is one of the anchors from that force-closed. And from here onwards, I seem to be having a lot of unconfirmed tx's with 136 and 147 sats and subsequently a lot of ghost UTXO's.

If i want to resolve the issue, do you think i should just publish the hex of the force-closed tx that does not appear in my list of tx's?

lncli wallet publishtx

4 replies

M1ch43lV Jul 5, 2023
Author

The problem of a ghost UTXO generally appears if the anchor of a force close tx has been collected by someone else in the meantime but the transaction has not being confirmed.
lnd does not update the change of the ownership of the anchor. Initially lnd tries to recollect the 330 sat anchor (diminished by the minimum miners fees of 1sat/vb fee you receive 147 sats) by binding an utxo of your lnd wallet. Erroneously if it is collected it assumes that the utxo of your lnd wallet is still attached to the anchor, but in reality it is not. So I called it ghost utxo, because the utxo is still spendable and left in your lnd wallet but the utxo database of lnd is not up to date.
To update lnd manually you have to republish the raw hex of the force close tx. As it is already broadcasted and confirmed you can not damage anything.
lncli wallet publishtx <hex tx of FC>
Hope this helps.
Generally it would be preferable if you had an option to drop the anchor instead of binding it, especially if you have high mempool fees.

nixonrichard1971 Jul 6, 2023

Hi, thanks for your reply. Do you have to do anything after you publish the tx? I just published it, but nothing happened, the command return the tx id, and then I can see this tx appears in my list as a new tx and is unconfirmed. Apart from that, I still have my UTXO's unconfirmed

M1ch43lV Jul 7, 2023
Author

Apparently, the UTXOs seem to be still bind to the anchor and the anchor still belongs to you. Maybe you can post the mempool tx to get an idea of the problem or you join the plebnet group on Telegram asking for help of the community https://t.me/plebnet

nixonrichard1971 Jul 12, 2023

i did fix my problem by rescanning my lnd wallet tx's

Prodigygr · 2023-07-09T00:17:05Z

Prodigygr
Jul 9, 2023

same problem here. i have posted here.

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[bug]: Ghost UTXO (unconfirmed balance) after unsuccessful attempts to publish a sweep tx or due to collected anchors #7420

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Replies: 2 comments 4 replies

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

Select a reply

[bug]: Ghost UTXO (unconfirmed balance) after unsuccessful attempts to publish a sweep tx or due to collected anchors #7420

M1ch43lV Feb 17, 2023

Replies: 2 comments · 4 replies

nixonrichard1971 Jul 5, 2023

M1ch43lV Jul 5, 2023 Author

nixonrichard1971 Jul 6, 2023

M1ch43lV Jul 7, 2023 Author

nixonrichard1971 Jul 12, 2023

Prodigygr Jul 9, 2023

M1ch43lV
Feb 17, 2023

Replies: 2 comments 4 replies

nixonrichard1971
Jul 5, 2023

M1ch43lV Jul 5, 2023
Author

M1ch43lV Jul 7, 2023
Author

Prodigygr
Jul 9, 2023