I wanted to put back on the table an idea proposed by @tromer (in this comment: Technical AMA w/ Zcash core devs Feb 24, 2017 noon PST - #48 by tromer) during the February Technical AMA. The idea is to exclude t-addresses from any “freshness requirement”. I love this idea, because I think it appropriately balances the tension between auditability and preserving the cold-storage / durability features of Bitcoin
As a buyer of Zcash, I agree that being able to audit the total number of Zcash in existence is a very important feature to pursue. In the context of Bitcoin, it is comforting to be able to look at the blockchain and see that the total number of Bitcoins is as it should be. In making the transition to buying Zcash, it is jarring to have to “trust the crypto” instead.
I don’t feel comfortable with money that becomes invalid absent some action taken by the holder of the money. To me, that seems like a problem, not a feature. I don’t think we should abandon the cold-storage, completely-disconnected-from-the-network-for-an-indefinite-amount-of-time capabilities of Bitcoin.
As for the tighter-upper-bound that @zooko has mentioned, I don’t think this is needed, especially if it sacrifices cold storage.
As for eliminating t-addresses completely, I understand that the use of z-addresses is essential to fungibility, but I favor keeping t-addresses precisely because it would enable the @tromer idea of excluding t-addresses from the freshness requirement. Perhaps make z-addresses the default in wallet implementations (to encourage adoption of z-addresses), but keep t-addresses for cold storage purposes.
@hloo Thanks for the feedback. We do need to balance the costs and benefits of couterfeit detection (or prevention), cold storage, economic supply clarity, and other factors. @tromer’s proposal is interesting and simple, definitely something to consider.
One thought I have to balance the tension between the desire for cold storage and the desire for an accurate metric of active supply inspired by this is explicit up-front opt-in cold storage. Previously I had been imagining schemes in which users can revive any funds after a long time to support cold storage. But if they are forced to opt-in up-front to cold-storage, this has some econometric advantage, because there’s a clear distinction between ‘active supply’ versus ‘either cold-storage or lost-keys supply’.
Edit: This kind of opt-in cold-storage could tie into other ‘vault’-like features, such as requiring a long delay to remove from cold-storage to detect or help prevent theft.
Hi, @hloo! Thanks for the feedback. I have to say that I have heard loud and clear that a large number of people have a very strong objection to the notion of expiring stale money.
Not only in the previous AMA — where I think it was the biggest topic — but in numerous private conversations with lots of different stakeholders, I’ve heard strong discomfort with the idea of people having to proactively touch their private keys to the internet in order to keep their funds.
So I’m definitely reconsidering my stated intention to shift to a protocol that treats sufficiently old, unmaintained private keys as invalid.
I’m not entirely satisfied with the obvious alternative of indefinitely valid private keys, either, for various reasons.
One of the reasons is the previously discussed measurement of the shrinkage of the monetary base, which I value more than most people appear to value.
But another is the ability to shed technical debt. If private keys are valid indefinitely, then it is impossible to ever move to a codebase which implements only new and improved crypto. I don’t want to insist — against strong objections from the users — that I’m going to cease supporting ECDSA keys two years from now, but nor do I want to give people the idea that I’m committed to continuing to support ECDSA keys for ten years. Neither is true, currently.
One possibility may be that this could be part of The Future Friendly Fork (A Future Friendly Fork - Electric Coin Company). Maybe we could have one branch of the blockchain and the software which can assume that everyone else has kept their software and their private keys up to date annually, and another branch that strives to maintain backward compatibility and preservation of funds as long as possible. “Dyna-zcash” and “perma-zcash”
By the way, even if we were respecting inert private keys indefinitely, I would still want to work toward having only one kind of address, which does everything you want to do. So, instead of keeping t-addresses around because their amounts are publicly visible, I’d rather have something like “a way to publicly but anonymously announce your z-address’s balance”. Something like that. Anyway, just to say that User Experience (UX) is critical, and how many kinds of keys/addresses/objects there are is a critical part of UX…
We’ve looked into PoS as an option but settled on PoW. You can read more about our decision for this in this FAQ entry: Frequently Asked Questions - Zcash
My personal opinion is that, like Bitcoin’s Proof of Work proved itself, Proof of Stake needs to prove itself. I haven’t seen a description of an algorithm for PoS that I feel confident would work well in practice. If someone else like Ethereum does it first, and it’s shown to work well, I think we’d be open to integrate it.
Yeah, I would be totally open to switching from Proof-of-Work to Proof-of-Stake in the future if there were solid reasons to think that the result would be advantageous and safe. I’m glad that Ethereum is intending to “go first” so we can learn from their experiment.
From a user’s perspective, I’d like the Zcash team to set the right expectations. Like a predictable inflation rate, I’d like some predictable guidelines such as: we may remove algos at any time to protect the network, but barring complete cryptanalysis, we’ll give you X time to switch. Suddenly forcing transactions reminds me of demonetization.
On the same topic, could SPHINCS be used for (very) cold storage ? Assuming higher fees to account for larger costs for miners ? For a noob, it seems SPHINCS was built to last.
Thanks for the feedback! I totally agree that setting expectations and letting people plan ahead is important. We won’t do anything without appropriate planning and communication.
For now, since we as a community and an ecosystem haven’t decided on a lot of long-term things yet — such as the possibility of switching from Proof-of-Work to Proof-of-Stake — I would advise:
Don’t assume that Zcash will never change, even in important ways.
Do keep your private keys where you can get to them within a few months.
Do stay aware of big developments via the forum, news sites, or the blog.
Dojoin the Zcash Foundation! This is a way that you can make your voice heard and be part of the evolution of the Zcash community.
About your other question, I love SPHINCS! (It’s not that I love it because I helped invent it, it’s that I helped invent it because I loved the underlying ideas.) I do feel like SPHINCS would be a much better long-term digital signature algorithm (see Figure 0 at the top of A History of Hash Function Attacks). I haven’t thought through all the engineering and UX implications of your suggestion, though.
As I mentioned elsewhere on this AMA, I think increasing the number of types of things that users might hear about is a major UX cost, and so I would want to try to figure out how to make SPHINCS be the only digital signature algorithm. (Oh yeah, and also as I mentioned, I consider incurring technical debt to be a major cost, too.)
P.S. About advice 3 above, consider this as a motivating story: what if we find out that a crypto breakthrough or a quantum computer is being developed, and we estimate that in about two years’s time it will become possible to forge ECDSA signatures? So, in this hypothetical science-fiction scenario, we announce (see advice 4 above) that we’re migrating from ECDSA to SPHINCS, and that for the next 6 months ECDSA signatures will be valid (unless there is an acceleration of the breakthrough which requires an even faster deprecation), and that after that point ECDSA signatures will no longer be valid, and money stored under ECDSA private keys will be gone forever.
That’ll probably never happen, but keep your private keys where you can get to them within a few months.
Thank you, I’ve read some of it. But on the one hand, I don’t feel like I fit the target audience for papers, and on the other hand, there’s a ceiling for what I can learn from blog posts. But maybe it’s too early for this science to be in books.
I guess what I’m asking is what a path from undergrad math to Zcash’s zk-SNARK would be.
(edit: whoops, I think I clicked the wrong reply button)
