Issues with importdescriptors command on testnet

I’m testing with a testnet wallet and having issues when I try to use the importdescriptors command with the output from listdescriptors false. Getting some errors. Anyone know how to fix this? I had a watch-only wallet created from the same testnet wallet and it worked fine. Now trying to import from that wallet to a new watch-only one and the errors pop up.

Yes, that’s a thing. There’s a start_height argument in the rescanblockchain command that can help scan from your oldest block. But it won’t fix missing transactions from pruned blocks. You could also try importprunedfunds, but that needs a txoutproof from another testnet node.

I dunno how regtest works, never used it. I like testing things live, feels more reliable. Gonna check out testnet4 since it’s only 13GB. Where can I find the sizes for testnet3 and testnet4 blockchains? Can’t find the mainnet size on mempool.space either. And do you know any legit site to get testnet4 coins?

Regtest is like live but you control block creation. Good luck with the forking nonsense on Testnet4 with miners ignoring mempool transactions. Actually, it's improved a bit since last time I checked. You should learn regtest, it’s not that tough. There are good guides here. Also, there’s a faucet for Testnet3 and Testnet4, like altquick.com, but I can send you some Testnet4 coins too.

Regtest really has everything you need for that workflow. It follows most rules for what you’re trying to test. Just keep in mind that its network is limited, but that’s not a big deal unless you’re testing transaction speeds. Testnet nodes don’t mirror mainnet behavior accurately. My testnet4 blocks folder is about 12.8GB if you want a reference.

The issue isn’t just with importdescriptors itself, it’s the rescan colliding with pruned history. Core rescans from the descriptor timestamp, and if those blocks are gone, there’s nothing to read. People think reindexing will bring back old blocks, but it won’t. It only works with data you still have.

I refuse to mess with pruned stuff, it’s just a waste of time. Testnet4 is small enough to handle easily. Not sure what signet is, but I’ll check it out. The real pain is that watch-only wallets can’t order transactions properly; they all seem to arrive at the same time if they share the same timestamp.

Yeah, watch-only ordering isn’t magic. It’s Core reconstructing the state from what it sees. Missing historical blocks mean it can’t find old transactions no matter how accurate the descriptor is. Descriptors guide Core but don’t retrieve old block data.

Try importing the descriptor again, but add "now" in the timestamp so it ignores the rescan. Then, use importprunedfunds (should work even if your node isn’t pruned). I found a post with details on using importprunedfunds, if your target transaction is reachable, you can use getrawtransaction "your_txid".

Just remember this command only works if the transaction is still in your mempool. For transactions already on the blockchain, you need txindex or the block hash where that transaction is. For pruned nodes without txindex, you gotta have the block available.

Yeah, I totally forgot about needing -txindex. Been using that command for years with txindex enabled. Didn’t realize we could still query transactions on a pruned blockchain without it if we follow the right steps.

You can store block files on an HDD without losing much speed. Just set blocksdir=<path-to-folder-on-mounted-HDD> in bitcoin.conf. Keep indexes and chainstate on a fast SSD. HDDs are cheaper than SSDs.

Sure, providing the block hash makes it easier since it won’t need to search the blockchain. But if the goal is to use importprunedfunds on a pruned node that failed to rescan due to pruned transactions, getrawtransaction isn’t relevant since that transaction is already gone.

Thanks for the advice! Tried that with my first 2TB SATA SSD. Worked great. Using an HDD instead of SSD for blocks is smart, but I’m worried about accidentally disconnecting it and corrupting data. I’ll decide when I need to.

True, can’t fully rely on rescanblockchain command either.