Good day LND Builders and Neighborhood,
I am dealing with a extremely uncommon and demanding concern the place on-chain funds related to a previous LND channel closure are inaccessible, regardless of my Bitcoin Core node (v29.0.0, RPi5, totally synced after recent IBD, txindex=1) confirming the UTXO’s existence through scantxoutset. Nonetheless, each listunspent and exterior pockets software program (Sparrow) miss out on this UTXO, and crucially, the tackle holding the funds can’t be derived from my LND root key utilizing customary strategies.
System & Historical past:
LND: v0.18.5-beta (upgraded from v0.5.2-beta). Confirmed just one pockets.db used all through.
Bitcoin Core: v29.0.0 (RPi5), totally synced post-IBD, txindex=1 studies synced: true. Datadir /mnt/hdd/bitcoin.
Channel Historical past: 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 tackle bc1qt728qplpuh6d98evkl4a990zdhwpwvur6qg8qz.
On-Chain Verification: Explorers affirm this UTXO (4c04…:0) exists and is unspent at bc1qt7…g8qz.
The Core Downside & Contradictions:
After a full IBD and making certain txindex is synced on my Bitcoin Core node:
getrawtransaction 4c04... true SUCCEEDS: The node is aware of the historical past of the funding transaction.
scantxoutset begin '["addr(bc1qt7...)"]' SUCCEEDS and RETURNS THE UTXO: This instantly confirms that the node’s chainstate (UTXO set) database IS CORRECT and accommodates the unspent output for bc1qt7…g8qz.
{
"success": true, ...
"unspents": [ { "txid": "4c04...", "vout": 0, ... "address": "bc1qt7...", "amount": 0.01495437 ... } ],
"total_amount": 0.01495437
}
listunspent ... '["bc1qt7..."]' (utilizing -rpcwallet="" or different loaded wallets) returns []: Regardless of the UTXO present within the chainstate, the wallet-specific RPC name fails to listing it.
Sparrow Pockets (recent set up, related to this node) exhibits 0 steadiness: When importing the confirmed LND root xprv and configuring for BIP84 (m/84’/0’/0′, Native Segwit P2WPKH), Sparrow completes scanning however exhibits 0 steadiness and lists no UTXOs, failing to see the UTXO that the node is aware of exists (per scantxoutset).
Parallel Pockets Derivation Failure:
Utilizing the confirmed root xprv (extracted from the proper pockets.db through chantools showrootkey), intensive checks with offline instruments (bip39-standalone.html) on customary BIP84 paths (m/84’/0’/0’/0/* and m/84’/0’/0’/1/*) did not derive the tackle bc1qt728qplpuh6d98evkl4a990zdhwpwvur6qg8qz after checking thousands and thousands of addresses.
Present Standing & Pressing Questions:
I’ve on-chain funds at bc1qt7…g8qz that my node essentially is aware of about (per scantxoutset), however that are inaccessible through customary pockets RPCs (listunspent) and exterior wallets (Sparrow). Compounding that is the failure to derive this particular tackle from the LND root key utilizing customary BIP84 paths.
Searching for knowledgeable assistance on:
Why would listunspent (even with the proper pockets specified) and exterior wallets like Sparrow miss out on a UTXO when scantxoutset on the identical node confirms its existence within the UTXO set? Is that this a recognized Core bug, a difficulty with how wallets question non-owned addresses, or one thing else?
Given the derivation failure, is it doable for LND (esp. after main model jumps) to comb funds to an tackle not derivable through customary BIP84 paths from the aezeed root key? Might a bug or particular state result in utilizing a distinct derivation scheme or perhaps a key unrelated to the primary pockets for sweep outputs?
Are there any superior strategies or instruments (LND debug instructions, particular chantools utilization, various pockets software program recognized to deal with edge circumstances) that might both:
a) Power Sparrow/LND to acknowledge the UTXO primarily based on the node’s chainstate affirmation?
b) Assist definitively hint the derivation path (even when non-standard) used to generate bc1qt7…g8qz from my pockets.db/xprv?
This example appears extremely anomalous. Any insights or steering could be extraordinarily appreciated.
Thanks.
Good day LND Builders and Neighborhood,
I am dealing with a extremely uncommon and demanding concern the place on-chain funds related to a previous LND channel closure are inaccessible, regardless of my Bitcoin Core node (v29.0.0, RPi5, totally synced after recent IBD, txindex=1) confirming the UTXO’s existence through scantxoutset. Nonetheless, each listunspent and exterior pockets software program (Sparrow) miss out on this UTXO, and crucially, the tackle holding the funds can’t be derived from my LND root key utilizing customary strategies.
System & Historical past:
LND: v0.18.5-beta (upgraded from v0.5.2-beta). Confirmed just one pockets.db used all through.
Bitcoin Core: v29.0.0 (RPi5), totally synced post-IBD, txindex=1 studies synced: true. Datadir /mnt/hdd/bitcoin.
Channel Historical past: 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 tackle bc1qt728qplpuh6d98evkl4a990zdhwpwvur6qg8qz.
On-Chain Verification: Explorers affirm this UTXO (4c04…:0) exists and is unspent at bc1qt7…g8qz.
The Core Downside & Contradictions:
After a full IBD and making certain txindex is synced on my Bitcoin Core node:
getrawtransaction 4c04... true SUCCEEDS: The node is aware of the historical past of the funding transaction.
scantxoutset begin '["addr(bc1qt7...)"]' SUCCEEDS and RETURNS THE UTXO: This instantly confirms that the node’s chainstate (UTXO set) database IS CORRECT and accommodates the unspent output for bc1qt7…g8qz.
{
"success": true, ...
"unspents": [ { "txid": "4c04...", "vout": 0, ... "address": "bc1qt7...", "amount": 0.01495437 ... } ],
"total_amount": 0.01495437
}
listunspent ... '["bc1qt7..."]' (utilizing -rpcwallet="" or different loaded wallets) returns []: Regardless of the UTXO present within the chainstate, the wallet-specific RPC name fails to listing it.
Sparrow Pockets (recent set up, related to this node) exhibits 0 steadiness: When importing the confirmed LND root xprv and configuring for BIP84 (m/84’/0’/0′, Native Segwit P2WPKH), Sparrow completes scanning however exhibits 0 steadiness and lists no UTXOs, failing to see the UTXO that the node is aware of exists (per scantxoutset).
Parallel Pockets Derivation Failure:
Utilizing the confirmed root xprv (extracted from the proper pockets.db through chantools showrootkey), intensive checks with offline instruments (bip39-standalone.html) on customary BIP84 paths (m/84’/0’/0’/0/* and m/84’/0’/0’/1/*) did not derive the tackle bc1qt728qplpuh6d98evkl4a990zdhwpwvur6qg8qz after checking thousands and thousands of addresses.
Present Standing & Pressing Questions:
I’ve on-chain funds at bc1qt7…g8qz that my node essentially is aware of about (per scantxoutset), however that are inaccessible through customary pockets RPCs (listunspent) and exterior wallets (Sparrow). Compounding that is the failure to derive this particular tackle from the LND root key utilizing customary BIP84 paths.
Searching for knowledgeable assistance on:
Why would listunspent (even with the proper pockets specified) and exterior wallets like Sparrow miss out on a UTXO when scantxoutset on the identical node confirms its existence within the UTXO set? Is that this a recognized Core bug, a difficulty with how wallets question non-owned addresses, or one thing else?
Given the derivation failure, is it doable for LND (esp. after main model jumps) to comb funds to an tackle not derivable through customary BIP84 paths from the aezeed root key? Might a bug or particular state result in utilizing a distinct derivation scheme or perhaps a key unrelated to the primary pockets for sweep outputs?
Are there any superior strategies or instruments (LND debug instructions, particular chantools utilization, various pockets software program recognized to deal with edge circumstances) that might both:
a) Power Sparrow/LND to acknowledge the UTXO primarily based on the node’s chainstate affirmation?
b) Assist definitively hint the derivation path (even when non-standard) used to generate bc1qt7…g8qz from my pockets.db/xprv?
This example appears extremely anomalous. Any insights or steering could be extraordinarily appreciated.
Thanks.
