Critical discrepancy: Bitcoin Core nodes look at Utxo via ScantXOutset, but not motivated from ListunSpent and Sparrow Wallet Fail; lnd keys?

Hello LND Developers and Community,

Despite being fully synchronized after Bitcoin core node (v29.0.0, RPI5 fresh IBD, txindex = 1), we are facing a very unusual and important issue that on-chain funds related to past LND channel closures are inaccessible. However, both the ListUnSpent software and the external wallet software (Sparrow) are unable to view this UTXO, and importantly, the address holding the fund cannot be derived from my LND root key using standard methods.

System and history:

LND: v0.18.5-beta (upgraded from v0.5.2-beta). Only one wallet.db has been identified that is used throughout.

Bitcoin Core: V29.0.0 (RPI5), fully synced, IBD, TXINDEX = 1 report synced: true. Datadir/MNT/HDD/BITCOIN.

Channel History: Opened in March 2019 (LND V0.5.2, Funding TX: 7060 … 9D71), later closed the power by peers.

Sweep Transaction: April 1, 2024 (block 837257), TX 4C0407B1188E0BA39313B1D9C87C49F6C81D99AA2839026C8AF8C989CE102244 used the channel output and sent 0.01495 BTC to P2WPHH. BC1QT728QPLPUH6D98EVKL4A990ZDHWPWVUR6QG8QZ.

On-Chain Verification: Explorers confirm that this UTXO (4C04 …:0) is present and does not exist in BC1QT7 … G8QZ.

Core Issues and Conflicts:

After full IBD, make sure the txindex is synced on the Bitcoin Core node.

getrawtransaction 4c04... true Success: Node knows the history of funding transactions.

scantxoutset start '("addr(bc1qt7...)")' Returns UTXO successfully. This directly confirms that the node’s chainstate (UTXO set) database is correct and contains the previous output of BC1QT7 … G8QZ.

{
  "success": true, ...
  "unspents": ( { "txid": "4c04...", "vout": 0, ... "address": "bc1qt7...", "amount": 0.01495437 ... } ),
  "total_amount": 0.01495437
}

listunspent ... '("bc1qt7...")' (use -rpcwallet="" or any other loaded wallet) Returns (): Despite the UTXO present in the chain state, wallet-specific RPC calls cannot list it.

Sparrow Wallet (a fresh install connected to this node) shows a balance of 0. Import the confirmed LND root XPRV and configure BIP84 (M/84’/0’/0”, native Segwit P2WPKH), Sparrow completes the scan, but shows 0 balance and uses utxos.

Parallel Wallet Derived Failure:

Verified root XPRV (extracted from the correct Wallet.db via Chantools Showrootkey), using extensive checks using the offline tool (bip39-Standalone.html) (m/84’/0’/0’/0’/* and m/84’/0’/0’/0’/1/*). BC1QT728QPLPUH6D98EVKL4A990ZDHWPWVUR6QG8QZAfter checking millions of addresses.

Current Status and Emergency Questions:

I have an on-chain fund in bc1qt7…g8qz (per scantxoutset) the nodes fundamentally know, but they are not accessible via standard wallet RPC (listunspent) and external wallet (sparrow). To consolidate this is that you cannot derive this particular address from the LND root key using the standard BIP84 path.

Seek expert help:

Why can’t external wallets like Sparrow and external wallets like Sparrow not display UTXO when ScantxOutset on the same node confirm its presence in the UTXO set? Is this a known core bug, an issue with how Wallets queries addresses other than owners, or is it something else?

Given the derivation failure, is it possible for LND (especially after major version jump) to wipe out funds from the Aezeed root key to addresses that cannot be derived via the standard BIP84 path? Is a bug or a particular state likely to lead to using different derivation schemes, or can you use important keys that are unrelated to the main wallet in the sweep output?

Advanced methods or tools (LND debug commands, using specific Chantools, alternative wallet software known to handle edge cases) are:

a) Force Sparrow/LND to recognize UTXO based on node chain state confirmation?

b) Does it help clearly track the derived paths (even non-standard) used to generate bc1qt7…g8qz from wallet.db/xprv?

This situation seems very unusual. The insights and guidance are highly appreciated.

thank you.