The proving key would be required for the period in which old transactions can be created. Depending on how the hard fork is implemented, this may be a defined fixed-length window, or an indefinite open-ended one. The key thing though is that the network nodes would only need to keep the current verifying key indefinitely (which is very small); once a node has migrated to the new proving key, they could delete the old one.
2 Likes
Just to make a concurring point: Intel x86s hide another CPU that can take over your machine (you can’t audit it), The Memory Sinkhole - Unleashing An X86 Design Flaw Allowing Universal Privilege Escalation and it’s likely thing aren’t all good and well elsewhere either.
2 Likes
Thank you for your answer :).
Pablo.
Shielded transactions (aka z transactions) have always worked since launch. There were some bugs related to priority and relaying, which meant that z transactions were not mined (included in a block) in a timely fashion. We think most of these issues have been resolved in the latest 1.0.4 release. There are some edge-cases we need to work on, but in answer to your question, yes, shielded z transactions work and you should use them! 
Here is an example of a shielded transaction: Transactions - Zchain
Generating a shielded transaction requires between 3 to 4 GB of memory which includes the proving key (~ 1 GB). The most resource intensive code is found in libzcash which calls into libsnark to generate the zk-proof.
3 Likes
After resource optimization for generating zk-proofs, will that open up z-addr support for light clients? Are there any other needs before full Zcash light clients can be implemented?
2 Likes
Do you think libsnark has the potential to become more efficient in memory usage and processing time?
2 Likes
Was kinda hoping for a function name, at least.
1 Like
We recently added a standalone benchmark that directly exercises the JoinSplit creation pathway. Once you’ve built the Zcash source, run src/zcash/CreateJoinSplit. It prints out function names and timing data (collected by libsnark) for every operation during proving, which should provide the information you need 
2 Likes
That’s a good question. Currently, we can know that by reasoning about the logic: every miner validates every transaction, and each transaction comes with a zero-knowledge proof that it doesn’t violate conservation-of-money (i.e. a proof that the money coming out of the transaction is ≤ the money going into the transaction).
This reasoning depends on the soundness of the zero-knowledge proofs. If you could somehow get the miners to accept a transaction that created new money — if you could somehow forge a zero-knowledge proof or defeat the zero-knowledge-proof-verifier software in the miners — then you could counterfeit money.
In the future, I’d like to add another layer of detection of this: I’d like to have a regular (e.g. monthly) “accounting period” in which the existence of money must be publicly revealed in order for the money to remain valid. This would not damage the user’s privacy—the amount thus revealed would not be linked with the owner’s address or with any other transactions, and even the amount itself could be obfuscated by splitting it into 2 or 3 random sub-amounts before revealing it. But, it would allow everyone publicly to count the sum of how much money was revealed in that accounting period, which would give us a backward-looking detection of whether counterfeiting had occurred during that period.
To change the protocol to require this would be a “forking” upgrade, in the sense that it would require all users who want to use the new protocol to upgrade to new software, and if people didn’t upgrade — either because they weren’t paying attention or because they preferred the original protocol — then they would spawn off a parallel chain-fork.
A protocol upgrade like this could also institute expiration of old spending keys and old unspent notes, meaning that your wallet has to regularly freshen your Zcash balances in order to keep them alive. For example, the protocol might say that money which has been lying idle for more than a year expires and is not longer accepted by nodes. Wallets would refresh money once a month, so that people wouldn’t lose their savings unless their wallet got disconnected from the blockchain for more than a year. If you wanted to store that kind of Zcash in a long-term, off-line vault you’d have to bring the wallet out at least once a year to let it connect to the blockchain and refresh the money.
One advantage of this “old-money-expiration” feature would be that the current state maintained in the blockchain could be garbage-collected, greatly reducing the scalability problem and allowing substantially faster performance. Another would be that everyone would be able to tell — in addition to the upper bound on the monetary base mentioned above, which detects counterfeiting, a tighter upper bound on the monetary base, which detects lost spending keys.
1 Like
Oh, that’s something I’m interested in learning about: are there common problems / lessons for privacy-focused cryptocurrencies.
I think there are plenty of use cases where the amounts moved, frequencies and the parties involved should remain more or less secret all but selected parties.
The parameters are large because of the way SNARKs require you describe the computation you are proving correctness of and that the description must be included in the parameters. A program can be very short and describe a large computation. E.g
For i in 0 … 1 Trillion:
sum = sum + i
Of course, when you run this, your processor will execute 1 trillion separate add instructions, but the program is still short. SNARKs require you to actually write out the whole list of instructions, so the description is not short at all. But wait, it gets worse! Not just do you have to write out every instruction your program would cause to be executed, the instructions aren’t something short like add_immediate. They are multiple byte integers. As a result the description of the computation you are proving is very large.
2 Likes
The main improvement from bitcoin to Zcash is the addition of shielded transactions. However, blockchain statistics (such as https://explorer.zcha.in/statistics/value ) suggest that only about ~5% of ZEC are actually stored in shielded transactions. Not only does this suggest that most users aren’t using the primary feature of Zcash, it also limits the amount of anonymity provided to those who do use shielded transactions.
Are you concerned about the low level of adoption of shielded transactions? Do you plan to make any changes that might increase adoption of shielded transactions? And finally, are you concerned that implementing “accounting period” changes might further impact adoption of shielded transactions?
2 Likes
While I see the attraction of such a scheme, I don’t like what it does to the entire concept of a cold storage wallet, which is to kill it, no?
1 Like
For bugs, either give us a lot of information up-front, or be prepared to answer our questions 
Here’s a (probably-incomplete) list of things we generally need to know:
- The version of Zcash you were using (
zcashd --version) - OS name and version
- Error output (any messages displayed on-screen when e.g. a crash occurred)
- Relevant debug log output (generally at the bottom of
~/.zcash/debug.log) - A written description of the problem, and how you found or triggered it
Things we sometimes need to know (so can be useful to provide anyway):
- Linux kernel version (
uname -a) - Compiler version (
gcc -version) - Any non-standard things you did during compilation (extra flags, dependency version changes etc.)
Actions that can be very helpful:
- Backing up / making a copy of the
~/.zcashdirectory (to try and make the problem reproducible, and occasionally to send to us after redacting appropriately) - Taking a VM snapshot (really helpful for interactively testing fixes)
2 Likes
It depends on exactly how such a feature is implemented. For example, if the accounting period is applied only to z-addresses, then indefinite cold-storage would still work with t-addresses. It also depends on what is meant by “cold”: the cold wallet would likely not need to actually be connected to the network, just have a transaction made (which would be done in the usual way for making transactions with cold wallets).
1 Like
There are already ports of zcashd to other platforms. There are also some Zcash specific GUI wallets in development. We don’t maintain either of these, so they are not ‘supported’ by our team. However, Zcash needs more independent developers, so the more devs and geeks reviewing that code the better. We don’t currently have plans to implement our own GUI, and instead we plan to support third party GUI developers and porters. We’ve already started accepting patches for people working on ports.
We’re looking into a few different lines of support for third party wallets to support Shielded Addresses: helping folks port zcashd to more platforms, helping port just the proof-generation core (libsnark and libzcash) for use in other projects, helping with alternative implementations of proof generation and verification, and finally looking into protocol improvements to make accepting to or sending from a Z address more feasible for light clients.
Edit: Formatting tweak.
1 Like
Do you think libsnark has the potential to become more efficient in memory usage and processing time?
Yes, we expect libsnark performance and memory use to improve, in several ways.
First, there are possible improvements to the implementation, such as improved parallelization, just-in-time streaming of the public key from files, and optimized in-memory representations.
Second, libsnark is extended on ongoing basis with more efficient cryptographic schemes. For example, the new zk-SNARK by Jens Groth (mentioned by @arielgabizon above) is already implemented in libsnark, and we’re evaluating its potential use in Zcash. Similarly for more efficient hash functions, and other cryptographic improvements.
Lastly, there is the potential for faster implementations using hardware features such as vector instructions and GPU. And we’ve recently implemented GPU acceleration for the main ingredient of another (less efficient) SNARK.
3 Likes
For instance @iuptr the Java Swing wallet that @vaklinov wrote does shielded transactions in a GUI, you can run that on linux with a zcash full node, or if you are on a Mac, @zab and I bundled it into a Mac App with my port of zcash to Mac, and you don’t need to touch the command line at all to run it (its at https://zcash4mac.com )
3 Likes
The Zcash codebase! Otherwise, the libsnark README mentions some tutorial code.
Probably the best place to find the right people to ask these kinds of questions is the #zcash-wizards channel on the Rocket.Chat server or IRC (Freenode, OFTC or Irc2P).
1 Like