Excellent, thanks a lot!
Thank you! Also @vaklinov and @zab!) 
Quite amazed that I missed this thus far. Since when is this package offered?
1 Like
- Within a particular shielded transaction on the block chain, the commitments and nullifiers are stored next to the zk-proof, all inside the
JSDescriptionconstruct. - The commitment tree is stored in each node’s block chain index, specifically within the “view” of the block chain that also tracks the usable UTXOs for transparent transactions (src). This view is updated each time a new block arrives (src).
- The list of spent nullifiers is stored in two places:
- The mempool tracks a global list of spent nullifiers.
- The wallet tracks spent nullifiers for its transactions.
2 Likes
A few days ago? I posted a forum topic here, and post regularly on twitter with this same username when I release new things
Yeah, like I said in my earlier comment, you have to bring your private spending key out of cold storage regularly, like every few months, in order to keep it valid.
Maybe we could maintain both branches of Zcash — the one where counterfeiting detection and garbage-collection are running, and everyone knows the current monetary base (i.e. lost spending keys results in everyone knowing that the money is gone), and the other one that takes longer, doesn’t have as much counterfeiting-detection, and we don’t know how much money is held by long-since-deleted spending keys, but you can safely store your spending keys off-line for long periods of time (maybe 10 years, maybe indefinitely).
I must admit that I am very fond of the “private key on a piece of paper in a safety deposit box” type of long term, offline storage that bitcoin (and current zcash) support…I mean, it’d be a shame, for a purely hypothetical example, for someone’s kids to not get their inheritance because the money “expired” in a vault somewhere!
5 Likes
Could these be documented with more context and in a coherent manner after this AMA? 
1 Like
Yes, tighter engineering, optimizations and potential changes to the circuit design (mentioned elsewhere in this AMA) can reduce the cpu and memory requirements to enable light clients, say a wallet running on a mobile phones, to be able to generate a zk-proof i.e. create a shielded z transaction. It would be somewhat slow but feasible.
The light client itself would be similar to Bitcoin SPV clients, that is, if it’s not possible to retain a full copy of the blockchain, it must trust other nodes. There are privacy concerns here that would need to be explored further.
Some tickets related to SPV: Delegated proving protocol for light wallets and Delegated JoinSplit Detection Protocol for SPV Clients.
3 Likes
There are basically three reasons for the low level of adoption of shielded transactions:
- There were various bugs at launch that inhibited their creation or usage.
- There were various default mining policies that inhibited their inclusion.
- At present, the primary users of Zcash are miners and speculators, who have less of an incentive to leverage shielded transactions than users making “transactional” transactions.
Our post-launch releases have included numerous changes addressing the first two points. The third point is more of a community effort, encouraging vendors and services to support Zcash, and building tools and apps to make its usage easier and broader.
7 Likes
Well for example nav coin uses the double blockchain to disconnect sender and receiver. But the system around that is very transparent so creating a total new wallet for example is harder.
Nav coin tech however is quite simple but very effective. Every tech, nav, zcash and Monero has its strong points. Would be great if lessons learned could be shared. The coins would stay unique but improve the privacy they want to offer.
I should’ve linked The Encrypted Memo Field to ask for a code sample. But I see there’s some code at GitHub - whyrusleeping/zmsg: A small program for sending messages via zcash encrypted memo fields!
1 Like
yeah zmsg works great!
1 Like
One of the things I want to prioritize in 2017 is making it easier for third parties, like wallets, exchanges, mining pool operators, etc. to support z-addresses.
We have a lot of ideas about how to facilitate that, some of which are various ways to make shielded transactions faster and less memory-intensive.
4 Likes
re: Third party wallets… Has there been any communication between Zcash and Electrum?
1 Like
Great questions and answers!!
Because of the flexibility of zk-SNARKS it would be possible to add such an option in a future Zcash version,
if the team would decide to.
For example, you could add a feature where you can send money that could then only be spent, by someone knowing several secret keys. This corresponds to what’s called multisig in bitcoin, and in fact, you can do it also in Zcash if you use transparent addresses.
I guess one way to already do it today with shielded addresses, would be to write the secret key controlling the coins as a bitwise xor of a few strings, and store these strings at different places, and delete the secret key.
4 Likes
Any responses available for this question? Are there currently any plans to audit the monetary base?
This was the only response I saw to that question.
1 Like
Since asking my initial quesitons something clicked… I tend to forget that the public keys I see are usually compressed - the number space of public keys is vastly more than that of private keys… So the odds of any random number being a valid public key are not good…
19 posts were split to a new topic: Slow money & I-got-robbed button