Error while using importdescriptors

[takuma sato]

Im testing with a testnet3 wallet and I see that there is an error when I paste the contents of "listdescriptors false" with "importdescriptors" command. I get a number of these errors:

[
  {
    "success": false,
    "error": {
      "code": -1,
      "message": "Rescan failed for descriptor with timestamp (a number here). There was an error reading a block from time (a number here), which is after or within 7200 seconds of key creation, and could contain transactions pertaining to the desc. As a result, transactions and coins using this desc may not appear in the wallet. This error could be caused by pruning or data corruption (see bitcoind log for details) and could be dealt with by downloading and rescanning the relevant blocks (see -reindex option and rescanblockchain RPC)."

Does anyone know how to fix this? I have another watch-only wallet I did from the same testnet wallet back then and it worked. I tried importing from the same wallet I used to create the previous watch-only wallet into a new watch-only wallet now and the error showed up.

I believe this may be from using pruned mode? (back then I had the blocks and I don't now?) For some reason, some funds are there, but mostly aren't.

Maybe with some of these rescan commands you can make them show up? I want to use pruned mode for testnet because I don't want to use extra disk space but maybe I end up using full blockchain there too. Pruned mode only gives you problems anyway it seems (the migration wallet bug was a good reminder to not use pruned mode). If im going to need to run an entire resync of the blockchain everytime I use importdescriptors, then I might as well use nonpruned mode... but anway let me know what is the best thing to do now.

Also, if im going to need to download the entire tesnet3 blockchain, perhaps I should move to testnet4? I remember reading something testnet3 being deprecated soon or something. But I also remember some exploits being used on testnet4. I don't want to end up with a ton of space dedicated to testnet if they use it to spam it or something.

[nc50lc]

I believe this may be from using pruned mode? (back then I had the blocks and I don't now?) For some reason, some funds are there, but mostly aren't.

Yes, it does.

Maybe with some of these rescan commands you can make them show up? I want to use pruned mode for testnet because I don't want to use extra disk space but maybe I end up using full blockchain there too.

There's a "start_height" arg in rescanblockchain command that you can use to scan your oldest block,
But that wont solve the issue of missing transactions in the already pruned blocks.

The alternative that I know is importprunedfunds but it requires a "txoutproof" from another testnet3 node.

Also, if im going to need to download the entire tesnet3 blockchain, perhaps I should move to testnet4?

If the datadir's size is the issue, then certainly yes.
For example, my testnet4 node's entire datadir including wallets is currently only 13GB in size.

Or you can use Regtest, you'll only need about less than a GB for its datadir.
It's perfect for testing PSBT workflow.

[takuma sato]

I believe this may be from using pruned mode? (back then I had the blocks and I don't now?) For some reason, some funds are there, but mostly aren't.

Yes, it does.

Maybe with some of these rescan commands you can make them show up? I want to use pruned mode for testnet because I don't want to use extra disk space but maybe I end up using full blockchain there too.

There's a "start_height" arg in rescanblockchain command that you can use to scan your oldest block,
But that wont solve the issue of missing transactions in the already pruned blocks.

The alternative that I know is importprunedfunds but it requires a "txoutproof" from another testnet3 node.

Also, if im going to need to download the entire tesnet3 blockchain, perhaps I should move to testnet4?

If the datadir's size is the issue, then certainly yes.
For example, my testnet4 node's entire datadir including wallets is currently only 13GB in size.

Or you can use Regtest, you'll only need about less than a GB for its datadir.
It's perfect for testing PSBT workflow.

I don't know how regtest works, never heard of it. I prefer to test things live, it gives me more peace of mind that something works imo. So I will try testnet4, if it's only 13GB It's no big deal. Where can I see how big the testnet3 and testnet4 blockchains are? I cannot even see the maintest size on mempool.space site.

Btw, do you know a legit site to get testnet4 coins?

[Cricktor]

Regtest is as live as you want it, you control block creation yourself. Good luck with the blocks forking nonsense and some stupid miners on Testnet4 that don't care to include transactions from mempool(s).

Oops, it actually got a bit better from the last time I checked on https://fork.observer, nice!

You could learn how to use Regtest, it's not too hard. I'm sure there're good explanatory posts in this forum, just a little search away.

A working faucet for Testnet3 and Testnet4 e.g. is: https://altquick.com/faucet/, but I can send you Testnet4 coins, too. Just state how much you need (don't be too greedy) and your Testnet4 public address.

[nc50lc]

-snip-
Or you can use Regtest, you'll only need about less than a GB for its datadir.
It's perfect for testing PSBT workflow.

I don't know how regtest works, never heard of it. I prefer to test things live, it gives me more peace of mind that something works imo.

For that workflow, Regtest has it all covered.
It follows most consensus rules related to your intended test from PSBT generation to broadcast.
The only difference is its network is limited to what you can connect to it but that's not the main point of your test,
unless it's about transaction propagation speed which testnet/testnet4 also can't accurately reproduce the same result as mainnet since those consist of different set of nodes.

So I will try testnet4, if it's only 13GB It's no big deal. Where can I see how big the testnet3 and testnet4 blockchains are?

Here's my testnet4 directory's blocks folder if you want an example:

Code:

08/24/2025  12:36 PM                 0 .lock
01/03/2025  07:45 PM       134,121,996 blk00000.dat
01/03/2025  07:46 PM       134,164,948 blk00001.dat
-snip-
03/02/2026  03:04 PM       133,014,062 blk00086.dat
03/02/2026  03:05 PM        83,886,080 blk00087.dat
03/02/2026  03:08 PM    <DIR>          index
09/05/2025  02:03 PM        21,088,324 rev00000.dat
09/05/2025  02:05 PM        20,460,713 rev00001.dat
-snip-
03/02/2026  03:04 PM         8,670,181 rev00086.dat
03/02/2026  03:05 PM        11,534,336 rev00087.dat
01/03/2025  07:40 PM                 8 xor.dat
             178 File(s) 12,853,689,060 bytes

Approximately 12.8GB in size.

[BattleDog]

What is biting you here is not really importdescriptors itself, it is the rescan window colliding with pruned history. Core rescans from the descriptor timestamp minus a little safety margin, and if those blocks are already gone, there is nothing for it to read. A lot of people hear "try reindex" and think that magically summons old blocks back from the grave. It does not. Reindex can only work with data you still have on disk. If pruning already ate the relevant range, the wallet is trying to remember a movie after somebody burned the first half of the reel.

One useful workaround, if your goal is to see what is still unspent rather than rebuilding your full wallet history, is to import the descriptors with timestamp set to now so it skips the historical rescan, then run scantxoutset against those same descriptors. That scans the current UTXO set, so it can still find live coins without needing old block files. It will not reconstruct old transactions or labels and all the cozy wallet history stuff, but it is a decent way to sanity check what is actually still there on-chain before you decide whether a full unpruned rescan is worth the hassle.

One other thing I would double-check, because it can produce the exact "some funds show up, most don't" headache, is whether you imported the full descriptor set including the internal/change descriptors and the correct range metadata. Pruning is the obvious suspect here, yes, but a too-small range or missing change descriptor can quietly make a wallet look half-empty even on a healthy node.

Also, if you are choosing a public test network for wallet workflow testing, I'd seriously consider Signet. Regtest is great for deterministic local work, Testnet is chaos with a pulse, and Signet sits in the nice middle where the network actually behaves like it had breakfast.