Bitcoin Core Node Sees UTXO via scantxoutset, BUT listunspent & Sparrow Wallet Fail; Address Undrivable from LND Key?

[vicortar]

Hello LND Developers and Community,
I'm facing a highly unusual and critical issue where on-chain funds associated with a past LND channel closure are inaccessible, despite my Bitcoin Core node (v29.0.0, RPi5, fully synced after fresh IBD, txindex=1) confirming the UTXO's existence via scantxoutset. However, both listunspent and external wallet software (Sparrow) fail to see this UTXO, and crucially, the address holding the funds cannot be derived from my LND root key using standard methods.
System & History:
LND: v0.18.5-beta (upgraded from v0.5.2-beta). Confirmed only one wallet.db used throughout.
Bitcoin Core: v29.0.0 (RPi5), fully synced post-IBD, txindex=1 reports synced: true. Datadir /mnt/hdd/bitcoin.
Channel History: Opened Mar 2019 (LND v0.5.2, Funding Tx: 7060...9d71), later force-closed by peer.
Sweep Transaction: On Apr 1, 2024 (Block 837257), Tx 4c0407b1188e0ba39313b1d9c87c49f6c81d99aa2839026c8af8c989ce102244 spent the channel output, sending ~0.01495 BTC to P2WPKH address bc1qt728qplpuh6d98evkl4a990zdhwpwvur6qg8qz.
On-Chain Verification: Explorers confirm this UTXO (4c04...:0) exists and is unspent at bc1qt7...g8qz.
The Core Problem & Contradictions:
After a full IBD and ensuring txindex is synced on my Bitcoin Core node:
getrawtransaction 4c04... true SUCCEEDS: The node knows the history of the funding transaction.
scantxoutset start '["addr(bc1qt7...)"]' SUCCEEDS and RETURNS THE UTXO: This directly confirms that the node's chainstate (UTXO set) database IS CORRECT and contains the unspent output for bc1qt7...g8qz.
{
"success": true, ...
"unspents": [ { "txid": "4c04...", "vout": 0, ... "address": "bc1qt7...", "amount": 0.01495437 ... } ],
"total_amount": 0.01495437
}
Use code with caution.
Json
listunspent ... '["bc1qt7..."]' (using -rpcwallet="" or other loaded wallets) returns []: Despite the UTXO existing in the chainstate, the wallet-specific RPC call fails to list it.
Sparrow Wallet (fresh install, connected to this node) shows 0 balance: When importing the confirmed LND root xprv and configuring for BIP84 (m/84'/0'/0', Native Segwit P2WPKH), Sparrow completes scanning but shows 0 balance and lists no UTXOs, failing to see the UTXO that the node knows exists (per scantxoutset).
Parallel Wallet Derivation Failure:
Using the confirmed root xprv (extracted from the correct wallet.db via chantools showrootkey), extensive checks with offline tools (bip39-standalone.html) on standard BIP84 paths (m/84'/0'/0'/0/* and m/84'/0'/0'/1/*) failed to derive the address bc1qt728qplpuh6d98evkl4a990zdhwpwvur6qg8qz after checking millions of addresses.
Current Status & Urgent Questions:
I have on-chain funds at bc1qt7...g8qz that my node fundamentally knows about (per scantxoutset), but which are inaccessible via standard wallet RPCs (listunspent) and external wallets (Sparrow). Compounding this is the failure to derive this specific address from the LND root key using standard BIP84 paths.
Seeking expert help on:
Why would listunspent (even with the correct wallet specified) and external wallets like Sparrow fail to see a UTXO when scantxoutset on the same node confirms its existence in the UTXO set? Is this a known Core bug, an issue with how wallets query non-owned addresses, or something else?
Given the derivation failure, is it possible for LND (esp. after major version jumps) to sweep funds to an address not derivable via standard BIP84 paths from the aezeed root key? Could a bug or specific state lead to using a different derivation scheme or even a key unrelated to the main wallet for sweep outputs?
Are there any advanced methods or tools (LND debug commands, specific chantools usage, alternative wallet software known to handle edge cases) that could either:
a) Force Sparrow/LND to recognize the UTXO based on the node's chainstate confirmation?
b) Help definitively trace the derivation path (even if non-standard) used to generate bc1qt7...g8qz from my wallet.db/xprv?
This situation seems highly anomalous. Any insights or guidance would be extremely appreciated.
Thank you.

[vicortar]

Subject: FOLLOW-UP: Address bc1qt7...g8qz with On-Chain Funds NOT Derivable via Standard BIP84 Paths from Confirmed LND Root xprv (Core Node Correctly Sees UTXO via scantxoutset)
Hi again / LND Developers,
This is a follow-up to my previous issue regarding inaccessible funds at address bc1qt728qplpuh6d98evkl4a990zdhwpwvur6qg8qz. Thank you for any initial feedback.
Crucial Update & Clarification:
Following extensive troubleshooting and confirmation from a Bitcoin Core contributor on a related ticket, we have definitively established:
Bitcoin Core Node Data Integrity is CONFIRMED:
My Bitcoin Core node (v29.0.0, fully synced after fresh IBD, txindex=1 synced) correctly identifies the unspent UTXO (4c04...:0, ~0.01495 BTC) at address bc1qt7...g8qz when queried directly using scantxoutset start '["addr(bc1qt7...)"]'. This confirms the node's chainstate (UTXO set) accurately reflects the on-chain reality for this specific UTXO.
The previous failures of listunspent and Sparrow Wallet are understood to be expected behavior because the Core wallet itself does not manage LND's keys/addresses. This rules out a Bitcoin Core data consistency bug as the primary cause.
The Core Problem Persists and is LND-Specific:
Despite the backend node having the correct UTXO information, the fundamental problem remains:
FAILURE TO DERIVE THE ADDRESS: Using the confirmed BIP32 root xprv (extracted from the correct and only wallet.db for this LND instance via chantools showrootkey), I have performed exhaustive checks using offline tools (bip39-standalone.html) and chantools derivekey (for v0.13.7).
Checks covered millions of addresses along the standard BIP84 derivation paths:
m/84'/0'/0'/0/* (External Chain, Account 0)
m/84'/0'/0'/1/* (Internal/Change Chain, Account 0)
RESULT: The target address bc1qt728qplpuh6d98evkl4a990zdhwpwvur6qg8qz COULD NOT BE FOUND/DERIVED.
Checks on other standard-but-non-default BIP84 accounts (e.g., m/84'/0'/1'/...) also yielded no results for the first few indices (limited by derivekey capability in v0.13.7).
Environment Recap:
LND: v0.18.5-beta (upgraded historically from v0.5.2-beta).
AEZeeD Seed/wallet.db: Confirmed unique and correct for this instance.
Target Address: bc1qt728qplpuh6d98evkl4a990zdhwpwvur6qg8qz (P2WPKH Native Segwit).
Funding Source: Likely an LND channel sweep (Tx 4c04...).
Refined Request for LND Expertise:
Given that the Bitcoin Core node data is correct, but the address holding the funds cannot be derived from the LND root key using standard BIP84 paths, I urgently need help understanding:
Is there any known LND bug, specific condition (especially related to upgrades from very old versions like v0.5.2), or edge case where LND's Sweeper might generate a receiving address using a NON-STANDARD derivation path (different purpose, account, hardened/non-hardened deviation), or worse, an address completely unrelated or underivable from the wallet's aezeed seed/root key?
Are there LND-specific debug commands, advanced chantools flags/modes (beyond standard derivation checks), or other diagnostic tools that can help trace the origin or intended derivation path of this specific address (bc1qt7...) from LND's perspective or using LND's internal logic/database, leveraging the confirmed wallet.db?
Could any database inconsistency within wallet.db (perhaps related to the upgrade path) lead to such a derivation mismatch for swept funds, even if the root key itself is correct?
The standard recovery methods have failed solely due to this derivation issue. Any insights into potential non-standard LND behavior or advanced recovery techniques would be immensely helpful.
Thank you.

[starius]

Can you check the output of lncli closedchannels please?

Find the channel in the output by searching for channel opening transaction ID.
Then check settled_balance field in the record of that channel. What is the value there?

Also check "close_type" field. Is it "COOPERATIVE_CLOSE"?
Also check "resolutions" field. It should be an empty list ([]).

What looks strange to me is that LND v0.18.5-beta used a P2WPKH address to accept the funds from a cooperative channel closure. IIRC it should had used a P2TR address by default. But maybe this is not the case for channels opened far in the past. Needs research.

[vicortar]

This indicates that my LND node currently has no record of any closed channels, including the specific one funded by 7060...9d71:1

with peer 0274...6772.

This is unexpected, as we know this channel existed and was closed (confirmed by explorers and the sweep tx 4c04...).

Does this empty closedchannels output suggest a potential issue with LND's channel.db database (e.g., corruption, reset, or loss

during past troubleshooting/upgrades)?

While this explains why we can't check the settled_balance or resolutions for that specific channel within LND, the core mysteries

remain:

Why did the sweep transaction (4c04...) send funds to address bc1qt7...g8qz, which I cannot derive from my confirmed root xprv

using standard BIP84 paths?

Why can LND's wallet (walletbalance/listunspent) and Sparrow (using the correct xprv and connected to a correct Core node) not

see the UTXO at bc1qt7...g8qz, even though the Core node itself confirms its existence via scantxoutset?

Could a corrupted/reset channel.db somehow influence the wallet's ability to track swept funds or, in extreme cases, affect the

derivation logic used during the sweep?

Thanks again for your help.

[guggero]

Did you try chantools sweepremoteclosed? Perhaps it wasn't a cooperative close after all?

[vicortar]

Hi @guggero and LND team,
Thank you for the suggestion to try chantools sweepremoteclosed. I have now run this command using the latest version of chantools and my confirmed root xprv.
Result of chantools sweepremoteclosed:

2025-04-22 20:55:37.572 [INF] CHAN: chantools version v0.13.7 commit
Error: found 0 sweep targets with total value of 0 satoshis which is below the dust limit of 600
Usage: [...]

(Note: I used --rootkey <my_confirmed_root_xprv> --sweepaddr <my_receive_address> --feerate <current_rate>)

This command found zero sweep targets, indicating that the UTXO at bc1qt728qplpuh6d98evkl4a990zdhwpwvur6qg8qz is not recognized by chantools as a standard output resulting from a remote force close that requires special sweeping logic.
Summary of Final Dead End:
To recap the critical findings after exhaustive troubleshooting, including a full Bitcoin Core IBD + synced txindex:
On-Chain Fact: Address bc1qt7...g8qz definitely holds an unspent UTXO (~0.01495 BTC) from Tx 4c04... (likely LND sweep after channel close).
Core Node UTXO Set Correct: My fully synced Core node confirms this UTXO exists via scantxoutset start '["addr(bc1qt7...)"]'.
Wallet RPCs Fail: listunspent (via Core wallet) and Sparrow Wallet (connected to Core, using correct xprv) fail to see/list this UTXO.
Derivation Failure: Using the confirmed LND root xprv (from the correct wallet.db), extensive checks (millions of addresses via offline tools/chantools) on standard BIP84 paths (m/84'/0'/0'/0/* and m/84'/0'/0'/1/*) have failed to derive the address bc1qt7...g8qz. Checks on the first few indices of other BIP84 accounts (m/84'/0'/1', etc.) using chantools derivekey also failed.
sweepremoteclosed Fails: The tool specifically designed for non-standard remote force close outputs finds nothing to sweep.
Conclusion & Final Plea:
All evidence now strongly suggests that the address bc1qt7...g8qz, despite holding funds seemingly swept by my LND instance (historically upgraded from v0.5.2), cannot be derived from my LND wallet's root key using any standard BIP84 derivation path.
This leaves me with inaccessible on-chain funds and no clear standard recovery path.
My final questions to the LND experts are:
Is there any known scenario, bug (perhaps related to the v0.5.2 -> v0.18.5 upgrade path), or non-standard behavior in LND's Sweeper logic that could result in funds being sent to a valid P2WPKH address (bc1q...) which is not derivable via standard BIP84 paths from the originating wallet's root key?
Are there any LND-specific advanced diagnostic tools, debug logs (beyond standard levels), database inspection methods, or non-standard chantools commands/flags that could potentially help identify the actual derivation path used for this address, or offer a way to construct a transaction to recover these funds, given that the root xprv is known but standard derivation fails?
I seem to have hit a wall where the on-chain reality contradicts the expected behavior of standard HD wallet derivation based on my LND keys. Any insights into potential LND internal behavior or specialized recovery techniques would be the only remaining hope.
Thank you immensely for your time and any further assistance you can provide.

[guggero]

Sorry if this was suggested before, but these walls of text without any formatting are hard to parse at a glance:

• Generate addresses with chantools genimportscript --format bitcoin-cli --lndpaths --recoverywindow 5000 and see if the address is in the generated list
• Restore lnd (latest version) from seed and let it fully re-scan the chain (as mentioned in https://github.com./lightningnetwork/lnd/blob/master/docs/recovery.md#on-chain-recovery)

[vicortar]

Hi @guggero, @starius, and LND team,
Thank you for your previous guidance. This post summarizes the final results of extensive troubleshooting regarding inaccessible on-chain funds at address bc1qt728qplpuh6d98evkl4a990zdhwpwvur6qg8qz.
Summary of Final, Confirmed State:
Bitcoin Core Node (v29.0.0) Data Integrity VERIFIED:
After a full fresh IBD with txindex=1 enabled and synced (getindexinfo reports synced: true).
Crucially, scantxoutset start '["addr(bc1qt7...)"]' run against this node SUCCEEDS and correctly identifies the unspent UTXO (4c04...:0, ~0.01495 BTC) at address bc1qt7...g8qz. This confirms the node's chainstate database accurately reflects the on-chain existence of this UTXO.
getrawtransaction 4c04... true also succeeds, confirming txindex functionality for this historical transaction.
LND & Wallet Access Failure PERSISTS:
Despite the Core node's correct chainstate, sudo -u lnduser lncli walletbalance and sudo -u lnduser lncli listunspent continue to show zero balance and no UTXOs.
Sparrow Wallet (fresh install, connected only to this verified Core node) also shows zero balance and no UTXOs after importing the LND root xprv and scanning with the correct BIP84 configuration (Native Segwit P2WPKH, path m/84'/0'/0').
Address Derivation Failure CONFIRMED:
Using the confirmed BIP32 root xprv (extracted from the correct and only wallet.db via chantools v0.13.7 showrootkey).
An exhaustive check using chantools v0.13.7 genimportscript --rootkey "..." --lndpaths --recoverywindow 5000 --stdout | grep bc1qt7... (covering BIP44/49/84/86 account 0, internal/external chains, depth 5000) yielded NO results for the target address bc1qt7...g8qz.
This definitively confirms the address cannot be derived from the root key using any standard LND derivation path checked by chantools --lndpaths.
sweepremoteclosed FAILED:
Following @guggero's suggestion, chantools v0.13.7 sweepremoteclosed --rootkey "..." was run. It reported found 0 sweep targets, ruling out the possibility that this UTXO requires special sweeping logic for a typical remote force close.
LND Startup Issues Resolved:
The initial "unknown option: tor.cookiepath" error (as clarified by @starius) was resolved by removing the invalid config option. LND v0.18.5-beta now runs stably using tor.password for Tor control authentication.
The Unresolved Core Mystery:
We have a situation where:
a) An unspent UTXO exists on-chain at bc1qt7...g8qz.
b) The underlying Bitcoin Core node's chainstate correctly reflects this (per scantxoutset).
c) LND (and Sparrow using LND's key) cannot see or access this UTXO.
d) The address bc1qt7...g8qz cannot be derived from the confirmed LND root key using any standard derivation path checked by chantools --lndpaths.
Final Request for LND Expertise:
Since standard derivation checks have failed and the backend node's data is confirmed correct via scantxoutset, the issue seems highly specific to how LND generated this address or how its wallet is failing to reconcile its state.
Is there any known LND bug, edge case (especially concerning the upgrade from v0.5.2), or non-standard behavior where the LND Sweeper might generate a P2WPKH output address that deviates from all standard BIP44/49/84/86 Account 0 derivation paths derivable from the wallet's root key?
Are there any LND-specific internal debugging tools, advanced chantools functionalities beyond genimportscript --lndpaths, database inspection techniques, or recovery methods that could help identify the actual derivation path used for bc1qt7...g8qz, or force LND's wallet to recognize the UTXO based on the scantxoutset confirmation and the known funding transaction (4c04...)?
I have seemingly exhausted all user-level recovery and diagnostic paths based on standard HD wallet principles. Any insight into potential non-standard LND internal wallet behavior or specialized recovery procedures is now crucial.
Thank you very much for your continued support and expertise.