I understand why a pruned node will fail to load a wallet file that’s too old (i.e. a wallet whose last witnessed block occurs prior to the earliest available block in the pruned node’s history).
I gather when attempting to do so you get “Error: Prune: last wallet synchronisation goes beyond pruneddata”.
However, I noticed the same error being displayed when trying to load a wallet.dat file that last witnessed a future block which the pruned node hasn’t yet seen.
I’m wondering why it can’t simply download (and discard as appropriate) blocks up to the one the wallet last witnessed, then continue marching on from there?
A sequence to reproduce the behavior goes like this (for simplicity, no transactions affecting the wallet took place between steps):
-
Take wallet.dat from a pruned node that hasn’t been synced in a long time, and move it to the environment of a full node.
-
Fire up the full node and let it sync. The wallet.dat file will get modified (e.g. with newer “best chain” marker… and maybe some other database engine housekeeping stuff I’m unaware of?).
-
Try to move the latest wallet.dat file back to the pruned node. You’ll see the error message I quoted.
-
If you use the wallet.dat from step #1 as a “crutch” to allow the pruned node to get up to date first, then restart it with the wallet.dat from step #3, it comes up just fine.
I’m having trouble reconciling why #4 works but #3 doesn’t (see also != operator on this line of code). It’s possible I lack sufficient understanding of what data a pruned node implicitly retains, outside the wallet file and the current UTXO set in chainstate folder.
