Are you restoring with a private key or a seed phrase (I assume a seed)?
Hello. When starting zcash 5.10.0 from a clean shutdown, I always receive this error:
2024-09-30T17:46:57.121296Z INFO Init: main: Verifying last 288 blocks at level 3
2024-09-30T17:46:59.186983Z INFO Init: main: No coin database inconsistencies in last 289 blocks (945 transactions)
2024-09-30T17:46:59.190071Z INFO Init: main: block index 66427ms
2024-09-30T17:46:59.536651Z INFO Init: main: nFileVersion = 5100050
2024-09-30T17:46:59.536683Z INFO Init: main: Keys: 112 plaintext, 0 encrypted, 112 w/ metadata, 112 total
2024-09-30T17:46:59.536694Z INFO Init: main: ZKeys: 3 plaintext, 0 encrypted, 3 w/metadata, 3 total
2024-09-30T17:46:59.551395Z INFO Init: main: wallet 361ms
2024-09-30T17:46:59.793156Z INFO Init: main: LoadWallet: inconsistency detected between available Orchard notes & spend information; starting with -rescan.
2024-09-30T17:46:59.793214Z INFO Init: main: CWallet::InitLoadWallet(): Rescanning last 2664806 blocks (from block 0)...
2024-09-30T17:47:59.000743Z INFO Init: main: Still rescanning. At block 22057. Progress=0.008763
This is very painful for me, because it takes about 3 days to complete the rescan.
My configuration is as follows:
txindex=1
rpcbind=::1
rpcallowip=::1
exportdir=/root/.zcash/backup
maxconnections=1024
metricsbind=::1
metricsallowip=::1/128
prometheusport=9000
How may I avoid having to complete a rescan every time I start the software?
If you added txindex = 1, this is expected behaviour. You just need to keep it running until it is synced.
Thank you, @daira. It was fully syncâd when I performed a graceful shutdown, which is why I am confused.
From what I understand adding txindex=1 tells the node to âindex all transactions that have ever happenedâ every time you start the node. This makes it faster to search for data in your local saved files. This could be useful for a person running a block explorer for example.
So if you donât want it to reindex the entire chain when you start the node you should leave that off.
Otherwise just leave the node running 24/7 and you wonât need to wait for the resync when you restart.
The txindex flag does not induce a reindex every time by default.
What command are you issuing to actually stop it? zcash-cli stop?
1 Like
Thank you, @Shawn. When I see âLoadWallet: inconsistency detectedâ in the logs, it indicates to me that the wallet is corrupt in some way. You are saying that this is not an error, but rather an artifact of txindex=1. To test this, I commented out the txindex option and ran zcashd -reindex. It completed successfully, and then I safely shut down the node. Upon restarting the node, I saw the following:
024-10-07T01:17:15.516285Z INFO Init: main: LoadWallet: inconsistency detected between available Orchard notes & spend information; starting with -rescan.
2024-10-07T01:17:15.516349Z INFO Init: main: CWallet::InitLoadWallet(): Rescanning last 2672029 blocks (from block 0)...
2024-10-07T01:18:15.001886Z INFO Init: main: Still rescanning. At block 18536. Progress=0.007690
2024-10-07T01:19:15.000761Z INFO Init: main: Still rescanning. At block 44142. Progress=0.014013
2024-10-07T01:20:15.003225Z INFO Init: main: Still rescanning. At block 71418. Progress=0.020541
This indicates to me that the txindex option was not at fault, and the issue lies elsewhere.
Ctrl+C from a foregrounded zcashd session running in tmux.
These are the logs emitted when I stop the node using ctrl+c:
2024-10-07T01:15:23.885255Z INFO main: tor: Thread interrupt
2024-10-07T01:15:23.885338Z INFO main: torcontrol thread exit
2024-10-07T01:15:23.908537Z INFO main: opencon thread interrupt
2024-10-07T01:15:23.908660Z INFO main: net thread interrupt
2024-10-07T01:15:23.908798Z INFO main: metrics-ui thread interrupt
2024-10-07T01:15:23.908835Z INFO main: msghand thread interrupt
2024-10-07T01:15:23.908849Z INFO main: scheduler thread interrupt
2024-10-07T01:15:23.909113Z INFO main: addcon thread interrupt
2024-10-07T01:15:23.966084Z INFO main: txnotify thread interrupt
2024-10-07T01:15:23.966485Z INFO Shutdown: main: StopRPC: waiting for async rpc workers to stop
2024-10-07T01:15:23.966717Z INFO Shutdown: main: StopNode()
2024-10-07T01:15:24.562160Z INFO Shutdown: main: done
This looks healthy to me.
1 Like
I believe you are correct, I misunderstood how txindex works.
1 Like
Any ideas, @daira?
Looks like it needs a -rescan to complete. Did that finish?
Yes. Just now, I safely shut down my node (which was fully syncâd) and restarted it, and now I see the following:
2024-10-10T16:50:28.676165Z INFO Init: main: LoadWallet: inconsistency detected between available Orchard notes & spend information; starting with -rescan.
2024-10-10T16:50:28.676253Z INFO Init: main: CWallet::InitLoadWallet(): Rescanning last 2676206 blocks (from block 0)...
It will take 3 days for this complete, which is very painful for me.
1 Like
I understand your frustration. How old is your wallet? Once this completes, Iâm curious if it fixes the issue. If not, please post any errors 
I believe my walletâs birthday is from some time in early 2023, but I am not certain.
Iâve successfully completed a dozen rescans in the past two months. The problem is not being fixed by a rescan, which is why I am raising the issue here on this forum.
These are the log messages that appear after a rescan:
2024-10-09T06:43:18.007515Z INFO Init: main: Still rescanning. At block 2671360. Progress=0.994259
2024-10-09T06:43:31.529187Z INFO Init: main: rescan 192376013ms
2024-10-09T06:43:31.735532Z INFO main: txnotify thread start
2024-10-09T06:43:31.735637Z INFO Init: main: mapBlockIndex.size() = 2672030
2024-10-09T06:43:31.735662Z INFO Init: main: nBestHeight = 2672029
2024-10-09T06:43:31.735917Z INFO Init: main: setKeyPool.size() = 101
2024-10-09T06:43:31.735933Z INFO Init: main: mapWallet.size() = 44
2024-10-09T06:43:31.735942Z INFO Init: main: mapAddressBook.size() = 3
2024-10-09T06:43:31.736319Z INFO main: torcontrol thread start
2024-10-09T06:43:31.908752Z INFO Init: main: Loaded 24882 addresses from peers.dat 172ms
2024-10-09T06:43:31.962557Z INFO main: dnsseed thread start
2024-10-09T06:43:31.962762Z INFO main: net thread start
2024-10-09T06:43:31.962904Z INFO main: opencon thread start
2024-10-09T06:43:31.962906Z INFO main: addcon thread start
2024-10-09T06:43:31.963035Z INFO main: msghand thread start
2024-10-09T06:43:31.963197Z ERROR Init: main: ContextualCheckTransaction(): transaction is expired. Resending when caught up with the blockchain, or manually setting the zcashd txexpirydelta parameter may help.
2024-10-09T06:43:31.963977Z INFO main: receive version message: /MagicBean:2.1.1-1/: version 170100, blocks=0, us=0.0.0.0:0, peer=1
2024-10-09T06:43:31.964167Z INFO main: receive version message: /MagicBean:2.1.1-1/: version 170100, blocks=0, us=0.0.0.0:0, peer=2
/MagicBean:2.1.1-1/:
Im not sure why your MagicBean says this.
Should say:
INFO main: receive version message: /MagicBean:5.10.0/: version 170110
Are you sure you are running the correct zcashd in your system?
1 Like
Thatâs the version of a remote peer, not my version.
Yes:
# zcashd --version
Zcash Daemon version v5.10.0
1 Like
Not sure then, lets see if others can chime in. GL
Always wondered who runs those other version numbers.
2.1.1-1 is labeled zelcore so it could be a consensus compatibility issue with the alternate chain i.e. you arent actually running a Zcash node.
(Theres like +80 or so 5.10.0âs still on as well)
[We need to be aware of the semantic versionings that are already present.
Upgrade to v7 may require a sub version to differentiate it from existing v7]
1 Like
A post was split to a new topic: Recommended ZEC transaction fee settings?
Does the Ledger support Zcash, allowing the use of transparent, shielded and unified adresses? Moreover, does the Zashi Wallet integrate with Ledger devices for managing these types of Zcash addresses, similarly to how itâs done with Ledger Live?