I’m seeking assistance in recovering my shielded balance from a backup prior to the 5.0 version. I had a wallet on zcashd version 4.7, which held a balance on shielded addresses. During the update to version 5.0, I accidentally deleted it. However, I do have an earlier backup of the wallet.dat file and the HD seed.
I’ve successfully restored the Docker backup with the old wallet.dat, updated, and synchronized it. However, the balance appears to be empty, and Z-addresses created after the backup are not recovering.
Could you please guide me in the right direction to successfully restore the shielded balance? Any assistance or insights would be greatly appreciated.
Legacy addresses will need to be restored using the private key import options.
With the seed it seems likely that you will have to recreate your previously held addresses and rescan to get the balance.
By recreating the unified addresses like you had before, you will get the same exact ones, and then you can rescan to update the balances.
I don’t think that same determinism works with legacy Sapling addresses but those keys should be contained in your wallet.dat folder.
Unified and sapling legacy addresses are both shielded addresses, but otherwise very different. Unified addresses of all reciever combos are restored with a seed and use the account hierarchy to refetch previously created wallet information when re-creating the addresses.
Legacy sapling addresses are not a part of any account systems and can only be restored with their associated private key, which may be held in the wallet.dat. Without it (key), they cannot be recovered.
(And technically, zcashd does not support seed import, you would need to use Ywallet and batch restore if you didnt have that wallet.dat file.)
Am I correct in understanding that the key for each individually generated shielded address is stored in the wallet.dat, and consequently, an earlier version of wallet.dat does not contain the latest addresses/keys?
Therefore, the only option left is to recover using the seed phrase, but Ywallet does not support pre-5.0 versions.
What other options could there be?
zcashd did not support seed phrases at all or the account model prior to v4.7.0, it was all private keys and your wallet.dat file.
Various other wallets did however support seed phrases prior to NU5 and Ywallet is (should be) compatible with them.
Zcashd is a special case where the current account system, address creation method and backup method is almost completely different than what it was pre-5.0.
Addresses created on zcashd before or after NU5 with z_getnewaddress have a key that you would have exported and backed up (or may exist in the wallet.dat file, not sure). This RPC call is now deprecated, it’s the old legacy way. Restoring them requires this backed up key. Without it, they cannot be recovered.
The new NU5 way with unified addresses and your seed is z_getaddressforaccount. You cannot export keys associated with these addresses. To restore balance to any of them, they have to be re-created under your seed and then rescan the wallet.
Pretty much the opposite of that, meaning there are no new keys stored anymore, just a seed. The old version did store those keys.
Alright. I had zcashd version 4.7 with a balance on shielded addresses. I made a backup, and I have the HD seed. I accidentally deleted it and reverted to an earlier wallet.dat, which does not contain my addresses, so it won’t help me.
Can I now recover the lost addresses using the seed generated on 4.7, and how can I do that?
Ywallet cannot recover these addresses from the seed.
What matters here is the method used to create the shielded address that held that balance. If it was 4.1 1, then it was the old method, and there is no mnemonic seed to import. You would have needed to export the private key. That line may have been from legacy Bitcoin which is where all the account stuff comes from anyways. 4.7.0 was the first zcashd version to support a seed.
If the funds were held in zcashd addresses at v4.4.1, those would be considered legacy addresses and they have no seed support at all, you need the key.
Unified shield addresses are a different story but it really sounds like that is not what happens to be the case here.
Like I mentioned above, some wallets did support seed phrases before zcashd native did, such as zecwallet fullnode which used a zcashd node but had its own account layer system on top and a seed. If this wallet.dat file came from a zec wallet full node instance, then the associated seed MAY be used to recover the addresses. That’s only if it came from a zec wallet full node instance however, and not a post v5.0.0 zcashd native seed, theyre different.
I mention this for the sake of exhausting all avenues of possibility, and if you were using zcashd native zcash-cli on the terminal, then you would absolutely know the difference, but some people confuse the two.
Actually, I’m gonna have to double check that some more, zwl full node was pretty old and maybe did not support seed recovery, zecwallet light did but that came later and is a totally different thing.
Zcashd never built support to import any kind of seed because before 4.7.0, it never exported any kind of seed. Support for HD sapling seed functionality In zcashd was never built out. Even today, there is still no method to import any seed into zcashd. It must be A. A post-4.7.0 zcashd generated mnemonic seed and B. contained in a wallet.dat file.
Like I said, what is important here is the method used to create the address because that determines what kind of backup it uses. Any address created In zcashd prior to 4.7.0 is legacy and is not associated with a seed, it has a key.
Address created with z_getnewaddress at all ever are legacy and also not associated with any seed.
Addresses created with z_getnewaddressforaccount are supported by the zcashd mnemonic seed.
When NU5 activated, users were required to create a wallet backup file with the ‘wallet backup tool’ unless they specifically passed a flag that did not require them to do so. This backup file would have contained your new seed and all of the legacy address keys that existed at the time of this backup creation. Any legacy address keys created afterwards would not have immediately updated this file. You would have had to update it manually. However, if the keys existed when you made this back up, then they should be contained in there.