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
}
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.