As for question #2, more support for z_addresses in wallets and exchanges would be great for adoption.
When we decide what issues to prioritize, we’re definitely considering the needs of wallets and exchanges for this reason.
On question 2, you can see that payment disclosure and delegated proving, both of which are important for commerce and exchanges are listed on our roadmap: Home · zcash/zcash Wiki · GitHub
Right now zcash4win is at 1.0.6 already, I’ll be updating zcash4mac from
1.0.4 to 1.0.6 shortly, hopefully by the end of next week. Most of thr
changes in my ports were in the build system and dependencies. Very few of
the changes have been to the code of zcash itself, and those have almost
all been due to differences in the memory models on mac and win.
3 Likes
Why is the count so low by release level compared to the total nodes count?
On that page the total node count includes all nodes ever seen; the version counts are over a shorter period (I’m not sure exactly how long).
OK I was just wondering why the counts by release is less than 200 and seems like it should be a lot higher unless there is something I am missing here.
Yes, I still intend to do something like this (in contrast to Daira, who isn’t sure). I agree with Daira that there is a big design space and a lot of issues to think through. In answer to your question, it isn’t on the Sapling Roadmap, meaning that we’re not committing to do it as one of our current set of top five priorities.
1 Like
I’m curious about the level of technical understanding the devs anticipate one would need to set up payment off-loading to a home computer from a light client on their mobile phone? Would it be comparable to running zcashd in it’s current state or more like setting up an email server? 
In other words, do you see a lot of people flocking to third party services hosting payment off-loading or it being simple enough to run from home?
1 Like
There are two cases:
-
Using an off-load server that you run yourself. For that I would expect that the light client would have to be pointed to the location of the server it will use (probably by entering a configuration string), and the off-loading service would have to be enabled on the server. If there’s a firewall between the client and the server then it would probably need a port to be opened in the firewall config.
-
Using a public off-load service. This would be easier to configure, especially if some well-known services were baked into the light client. However, in the short term this would only be able to support off-loading spends from t-addresses to z-addresses, not spends from a z-address, because you wouldn’t want to trust the public service with your spending keys. We’re looking at options for splitting up the proof to allow this to work with less trust in the service.
2 Likes
That’s the answer to this question: I want to make future version of the protocol which requires all Zcash to be counted on a regular period (like once a month or once a year), and money that didn’t present itself to be counted would eventually cease being valid.
This would have a lot of complex trade-offs:
- On the downside, it would mean you can’t keep your Zcash wallet offline indefinitely (or written on paper or scratched onto a metal disc) — you have to let your Zcash wallet connect to the blockchain periodically (like once a month or once a year) in order to stay valid.
- On the upside, it would mean that all of the wallets, and all of the Zcash money, in the system are “up to date”. It makes it easier for the Zcash ecosystem to deprecate old protocols and old cryptography to make way for new.
- Also on the upside, it provides an accounting of how much money is actually currently “alive” — a Zcash wallet has (anonymously) proven that it is still alive and still knows the private spending key for that money. This gives us both upper-bound and lower-bound information about the current Zcash monetary base: on the upper-bound side it shows us whether there has been counterfeiting, and on the lower-bound side it shows us how much Zcash was lost (by deletion of the private spending key), or was expired because the wallet failed to prove its liveness.
I expect this to be controversial, and complex.
3 Likes
P.S. There are a lot of other trade-offs not mentioned above, and a lot of other parts of the design space where this could go (like Daira mentioned). For example, what if there were a “return to sender” behavior were if a private spending key goes idle too long, so the consensus rules presume it is dead, then its money goes back to the previous spending key and so on until it reaches a spending key that is still alive?
3 Likes
P.P.S. “Return to spender”. 
1 Like
In addition to @zooko’s answer about auditing, we practice very thorough code review and testing practices, and we try very hard to minimize the amount of security-critical code (which was a significant contributing factor to Zcoin’s bug). We also backport security fixes regularly from Bitcoin Core (which wasn’t an issue for the Zcoin bug but could be in other cases).
3 Likes
Re: hibernation
Technically possible — and another example of the breadth and complexity of the design space here — but I don’t want to support that feature. I want to use a currency where all currency in circulation has been proven to be alive recently, and where all wallets have been upgraded to the most recent version (within a year or so). I want to say “My business doesn’t accept your money if your money has ever hibernated for more than a year. Because I want to know how much money is in existence currently, and I want to know that my wallet can deprecate and reject old crypto and old protocols in order to make room for improvements.”
If enough people want the opposite — they want to be able to hibernate their Zcash for long periods of time, even though that means they can’t have as precise of a measurement of the current monetary base and they can’t have as rapid an evolution of the protocol — then I’ll suggest we make this be “the future friendly fork”. We’ll branch into two flavors of Zcash — one in which all keys, balances, wallets, and protocols have to be kept continuously up to date (within a month or a year or a couple of years), and the other in which keys can be kept dormant and offline indefinitely. I personally would be interested in participating and supporting both variants, if both of them had sufficiently active communities.
In the near future priorities list, the Sapling crypto upgrade has a general mention of efficiency improvements. Is there a resource for further details about those improvements or if not, some hints at what those improvements might include?
1 Like
I certainly want to think carefully about whether any proposed protocol changes would facilitate or incentivize bad behavior. I think the solution to the problem you sketch here is “Have things set up properly so that if you die your heirs inherit your Zcash!”.
2 Likes
Is BOLT compatible with Sprite?
In principle yes. The Sprite implementation on Ethereum uses smart contracts, but it could be supported with a much simpler abstraction that we could add to Zcash, I believe without any compromise in privacy. I’ve only skimmed the Sprite paper so I could be missing something, but we will investigate this.
2 Likes
Can you please describe in layman’s terms when a new block can begin being mined? For example when a solution to the current block is found by a miner or pool operator can the new block begin to be mined immediately or do they have to wait for network consensus to begin.
1 Like