Open an issue on our issue tracker! Issues · zcash/zcash · GitHub
Be sure to search there first, in case your bug of feature request is already there, in which case add your comments there
Open an issue on our issue tracker! Issues · zcash/zcash · GitHub
Be sure to search there first, in case your bug of feature request is already there, in which case add your comments there
Hi,
The reason that a random number cannot be a public key, is that the public key is a long string with a very specific structure that most strings don’t have.
For example one part of the public key looks like
g,g^s,g^{s^2},…,g^(s^d)
for large d, for some fixed s, where g is a generator of some group,
and a random string would not have this structure almost surely
see my blog post
https://z.cash/blog/generating-zcash-parameters.html?page=0
I read somewhere that besides focusing on privacy through ZKSnarks it is your intent to stick to Bitcoin Code and features as much as possible, without branching into other things. Is this an accurate description?
Thank you.
With the announcement of Teechan (see Scaling Bitcoin with Secure Hardware) since Zcash is so similar to Bitcoin’s base protocol, do you intend to have Zcash work with Teechan?
Thanks.
Follow-up: Is there any specific information people should keep in mind to provide when opening an issue?
It turns out there is a fast method to “batch verify” many proofs.
This is because SNARK verifiers are based on pairing equations, and such equations can be bundled into one equation using randomness.
This batch verification could potentially reduce by a factor of 3 the verification time.
Also, we may move to a different Zero-Knowledge scheme by Jens Groth where the verifier is more efficient
And maybe double-check in chat too in case search fails…?
Would that kind of change be considered a soft-fork?
Per Zooko’s answer, we have already been thinking of changing the PoW. This would have an effect on GPU mining, and may make older cards with less RAM less feasible. But our goal isn’t to remove GPUs entirely! Our long-stated goal regarding the proof of work is to encourage decentralisation, which has two aspects:
These goals direct us towards a PoW that is balanced between GPUs and CPUs.
I haven’t really studied Teechan very carefully. I have an instinctive dislike of “trusted hardware”-based designs. I’m not sure if that’s a valid engineering prejudice on my part…
It would be a hard-fork (under the colloquial definition of a hard-fork where previously-invalid transactions become valid), because it would require changing the public proving key, which would require the network participants to know of the new key and accept transactions created by it.
Thank you for the prompt response.
So if that is the case, is it safe to say that GPU models that are currently producing high hash rates should continue to produce high hash rates? Older model cards would be affected the worst?
I tried to find something from the documents with regards to encrypting selectively based on receiver roles. Is there something like that in the works? I’m thinking something like attribute based encryption. (I’m new to this so, the question may not make sense.)
I don’t think we can answer that. It would depend on a lot of details of the Equihash implementation and the GPU architecture and we’re not the experts at that.
No, there’s nothing like that baked into the protocol yet. It’s an interesting idea though, so thanks for mentioning it!
Would the current proving key still be required to interpret the blockchain up to the point of such a hard fork?
IMHO that would be a safe assumption, although until we do more research, the definition of “high” is unknown. If we only change the Equihash parameters, then the algorithm is the same but it uses more memory, so GPU solvers running multiple solvers in parallel may need to instead be reworked to focus on parallelising a couple of solvers.
EDIT: I should point out that I am not a GPU developer, so you would likely get better answers on this in the #zcash-miner-dev channel on Rocket.Chat.
Without getting too technical, how are the commitment and nullifier trees stored for the zk-proofs? Are they completely distinct from transactions?
Edit: I guess with this, I’m mostly looking to know how transactions, commitments and nullifiers link with each other.
Hi
A very simple question is :
Since we are not able to know the amount of a shielded transaction, then how can we determine how many ZEC in circulation?
Thanks … If you can please a very tech-advanced and explained answer
Our primary intent is to provide new features that have strong privacy and to rely on Bitcoin’s proven design as a basis. That’s the Zcash team’s strength.
However, we may propose changes to other features or not adopt features that Bitcoin adopts moving forward, but if we do we will strive to be judicious & conservative with each case. One example is the switch to Equihash PoW which isn’t a privacy-focused change, yet we believe it’s a good improvement.
We already have some exciting new developments brewing for the main Zcash protocol and also auxillary integrations. One example is Blind Lightweight Offchain Transactions (BOLT) which are a privacy preserving analog to Lightning / payment channels.