I have a unified address in the zcashd default wallet but when I do
zcash-cli z_exportkey
I get:
No serialized form is defined for unified spending keys. Use the emergency recovery phrase for this wallet for backup purposes instead.
I am at a loss. I want to transfer from sprout addresses and extract the uni-address (in particular I want an orchard shielded address) and key to computer file/paper.
So am I right in thinking whatever the wallet, the only way to backup is to use the backup facility of that wallet and live with a computer file?
Orchard does not directly expose the spending key, it uses seed phrases e.g the emergency recovery phrase.
Sapling does expose the priv key and it would be easiest to export the sapling key, import that into Zkool and then move your funds to wherever you like with a nice up-to-date gui wallet.
zcashd does NOT support importing seed phrases and the wallet cease to function in the near future.
what do you mean âit uses seed phrasesâ? doesnât the seed phrase relate to recovering the whole wallet?
is orchard a replacement for sapling? how long does sapling have to live?
I have to transfer one sprout transparent address and one sprout shielded address before sprout disappears. if I have a single uni address with just a sapling receivertype, can I spend those two addresses directly to that uni address or do I need to know the shielded address inside it?
and then how do I get the sapling address out of the uni address?!
Yes. The Nu5 upgrade changed the internal wallet. It marked non-unified addresses as Legacy and re-activated the previously unused Account system inhereted from bitcoind. This required the users run a Wallet-Tool that generated a seed that applied to the new account (though like mentioned, the functionality to import the seed was never added). The user could pass a flag and bypass that but point is that all unified addresses keys are derived from a seed now and private spending keys are considered Legacy. Funds in a unified address, regardless of which actual receiver address holds the funds, are recovered with a seed. Funds in a Legacy Sapling address are recovered with a key. However, you should be able to dump the key of the Unified Sapling receiver and import that into Zkool.
Orchard is a replacement but Sapling still has a long time to go.
Sprout is the original shielded pool type. You could say a Sprout-era transparent address but otherwise âsprout transparent addressâ is a misnomer, those are two completely separate types.
so that means I neednât do anything with my sprout-era address?
my zcash daemon was doing 3% per day post spamming incident then at about 2,100,000 it did 20% overnight and has continued at rapid clip today. Just as it was close to syncing or perhaps after, zcash-cli became unresponsive and timed out. I issued a SIGHUP to no effect then a SIGTERM and waited 30 mins - no joy. Finally a SIGKILL and restarted in console mode. It shows 2000 odd validated transactions and âRescanningâ but there it has remained for 4.5 hours when it normally takes seconds. strace shows activity but perhaps only an infinite loop.
Is there anything I can do?
more difficult? is there not to be a basic wallet associated with whatever comes after zcashd?
If the address that holds the funds starts with a âzcâ prefix, then you must move the funds.
If it starts with a âzsâ, âuâ or âtâ, then you could potentially recover in another wallet fairly easily, assuming you have the proper key or seed.
Zallet is the replacement for the zcashd internal wallet but its currently work in progress and it wont have any Legacy functionality anyways. Your best bet is to use up to date lightwallets.
in relation to my killing the uncommunicative zcash daemon after it likely finished downloading of the chain, was the state of being uncommunicative to be expected or should it immediately have come on-line?
I ask because of the âdaysâ you mention waiting for the âScanningâ stage of initialisation and whether this delay was inevitable whether the uncommunicative daemon was left to run or killed/restarted.
Unfortunately, yes. zcashd is historically (in my experience) pretty buggy, prone to becoming unresponsive and db corruption. This is part of the reason why itâs facing end of support sometime in the coming months.
after the chain is fully downloaded, and the daemon is still running, is there a scanning stage or equivalent that equals what I have encountered on starting it back up? in other words, after downloading is a delay expected before things come back on-line and the zcash client is responsive again?
Bandwidth and computational resources, but the chain is pretty much scanned linearly, and there are only so many things that can be paralized, anyways. Presumably the console will become responsive again once it syncs to the tip.
As a follow up, here is one example:
Take the following scenario, you have a unified address with 1 orchard and 1 transparent note, of equal value.
Iâd like to shield the transparent note into an orchard note, how can i accomplish this deterministically?
z_sendmany seems to be a crapshoot regarding which note it actually consumes as the input, there is no âcoin controlâ for picking an individual UTXO. I would prefer granular management
With zcashd, you could use âlockunspentâ to exclude a note from being included in a tx. I donât believe this functionality is intended to persist in zallet.
Yes, that is what it means. The cli is frozen because its not a very stable program. It would become unresponsive all the time when I used to run it. You could try to issue a zcash-cli command and see what the response is. zcashd was designed to run as a daemon anyways and you can check the process with top, htop or any other similar commands. You can also peek at the blockchain db size and see if it keeps growing.
being in rescanning mode could take ⌠.days, the implication being that this is entirely normal and at some point the cli will come back on line
the daemon is buggy and/or the blockchain is corrupt, the implication being that the cli will never come back
I find these two things mutually exclusive.
based on your no.1 I am now running the daemon which is in ârescanningâ mode after loading the index. I shall wait.
based on your no.2 I might wait forever.
can you say, with some clarity, how long one should wait before assuming the worst, and what to do then? download the chain all over again?
if the rescanning phase actually completes, is it, or is it not the case, that after a normal shutdown of the daemon, upon restart it will again go through this lengthy rescanning phase? a clear answer would be appreciated.
First is the initial syncing Zcashd with the main chain; the 270GB of data downloaded/validated.
Second then once synced, if you change the wallet (import private keys, change wallet.dat, etcâŚ)
then you need to perform the -rescan for the updated wallet to search its block database for every transaction involving your addresses to show an accurate amount of funds.
After that, your wallet is caught up, so if you shut down the node for whatever reason then you donât have to scan the entire chain for old transactions with -rescan , just start it normally and let it catch up from the last time it was synced and you can send/receive funds normally.
After shutdown and restart, it SHOULD pick up where it left off. You should pass a âzcash-cli stopâ command to stop the node correctly since the regular terminal is unresponsive and ctrl-c may not work there (not recommended anyways).
after two attempts waiting for ârescanningâ to end at start-up (4-5 hours then an overnighter), the daemon has on the third attempt crossed that stage in seemingly no time at all. ??!!
the first thing I did was importkey/importprivkey on the t-address and it worked.
and it would be easiest to export the sapling key, import that into Zkool and then move your funds to wherever you like with a nice up-to-date gui wallet.