The silly season is coming to an end, and the time to mine-and-sell is nearly over and done.
For the fair-weather miners that means it’s time to flee to pastures new, complaining about how Zcash is a bust, and you’ve sold all your ZEC and bought Monero. So long, friends!
For the rest of us, this is what we’ve been waiting for. Time to mine and actually hold, hedging our bets against the future. There’s just one problem. How do you hold ZEC safely?
And that is why I am creating this fine, upstanding gentleman of a thread.
Having searched the forums and wiki pretty extensively, there is insufficient information on wallet backup, cold storage, and offline signing for my comfort.
If I’m going to hold ZEC, I don’t want to find out I’ve been holding it in a corrupted wallet for two years, or that I’ve only backed up some of the necessary files, or that I’ve leaked all my private keys in a puddle on the floor.
So let’s talk about how to hold ZEC safe and sound. What are the principles? How can we best encrypt? What exactly needs backed up to be guaranteed to be recoverable in future, and in future versions of Zcash. Should we hold in a t-address? Do we trust z-addresses for holding? Does holding in a Z-address sufficiently complicate the offline transactions, that we should avoid? What time is it? Who am I? Why does asparagus make my pee smell?
Would definitely love to see the founder’s reward in action here on zcash specific documentation on this topic with answers to all your zcash-related questions with a painfully clear step-by-step on cold storage as well.
Wrote a module last week which used that exact how to and have only been using it for own z-addresses.
Planning on storing in a deposit box, but don’t like the idea of leaving the sk in the clear.
So the QRcodes, addresse(s) and sk’s are going to be embedded in a plain txt file, then encrypted with gpg and ascii armor headers stripped.
Each page then printed and laminated.
For import, OCR would be used to extract the ascii armor, where the BEGIN and END headers are then appended, we decrypt and voila.
So far as t_addr key pairs go, the Zcash protocol uses private keys that are interchangeable with bitcoin - which means that any of the offline methods for generating bitcoin key pairs can be applied for the private portion of a t_addr pair. These resources typically generate WIF strings as well as QR codes which is helpful for people that want to make hard-copies of their keys.
For that matter, Zcash could be installed on an offline computer to safely generate some new addresses and then:
zcash-cli getaddressbyaccount “”
zcash-cli dumpprivkey [t_addr from above]
and then (still using the offline computer) import those private key(s) to a bitcoin wallet, such as Electrum, to generate QR code(s). I have no idea if such an approach would be useful for offline signing of messages that can still be verified with zcashd / zcash-cli…
For what it’s worth, for any given private key, the RIPEMD-160 hash portion of a bitcoin address (minus the prefix and the checksum) is the same when that key is used to generate a t_addr.