Someone mentioned in coindesk comments that an anonymous coin is a serious problem because you can’t determine if the code has been hacked to generate excess coin. In support of this, I found this in the blog:
Perhaps there could be a way to audit the size of the Zcash monetary base, without compromising the privacy of any users. That way…at at least we can tell that they have not (yet) used it to counterfeit money.”
It seems like a serious problem, requiring faith that Zcash will not be printed like fiat.
Did you notice with the previous release (or the one before) that newly mined coin has to be protected before any other transaction can be done with it? All Zcash starts as a transparent, auditable coin and, after that first protected transaction, it’s up to the users whether they want to perform transparent (auditable) transactions or protected transactions. So, unless these poorly informed people are concerned that zero knowledge proofs enable users to lie about their initial balance, which shows they know next to nothing about Zcash, they simply know nothing at all.
It is possible – if the “toxic waste” is created – for an arbitrary amount of zcash to be “minted” into any address without detection. That’s why the trusted set up is such a sore spot.
Also, if there is a bug in the code (unrelated to toxic waste) that allows an attacker to change the balance of an address, it’s possible that could allow forged coins to enter the system and circulate undetected.
It is an unfortunate weakness of the current design. I’m sure it keeps @zooko up at night. It also speaks to just how important the code audits are.
Yep, this is one of the things I like least about the current design. I don’t like putting all of our eggs into the prevention basket, and not having a detection and remediation defense-in-depth. But, I have an idea to help with this in a future version! But I don’t want to spill it here and now. It is late and I want to write it up nicely and post it before someone else does…
The whole toxic waste thing does not sound right. It’s like a goto statement. It does not have symmetry. It must have a more elegant solution that prevents it altogether. Proposition: If lack of symmetry is required, a security hole is being created from first principles and any solution is only a patch. Maybe no system seeking to be secure can emit any kind of “entropy”. Including showing that the monetary base is on track. It would need symmetry, meaning it can’t be mined in 2016 if it can’t be proven in 20xx only 21M were created in total. But “traveling back in time” like this would require hard code inside the keys (hashed into?) that no one can change without it imploding, validating all other blockchains that have not imploded. Maybe proof of work or proof of stake would not be needed if that could be coded.
When you say a user can make “auditable” transactions, do you mean you can optionally send public transactions on the ZCash blockchain, or do you mean a key could be released to read funds?
If the former, that seems like a very bad thing.
It is possible to send funds from one transparent address to another. In that case, everyone can see the details of that txn on the blockchain – just as with bitcoin.
It is also possible to have funds in a protected address, and then release a viewing key to for that address. Anyone with the viewing key can audit what’s gone in/out of that particular account. (You cannot spend from an account if all you have is an account’s viewing key).
Bear in mind that Zcash and Bitcoin share a lot of ‘DNA’ - even in the structure and readability of their blockchains. Zcash started life as Zerocash which was originally intended to be retrofitted to Bitcoin to provide what Satoshi left out.
I believe there is some misunderstanding about my question. My concern is about keeping a lid on money-creation to what it is supposed to be. Since you can’t see who or the amounts in the transactions, you can’t count how many coins are in existence at any point in time. In bitcoin, you can see exactly what a 51% attack is doing. You just can’t stop it. In Zcash you can see someone may have 51% hash power, but how do you know if they are abusing it or not? But the bigger problem is this: if a hole has been found in the core code and someone is creating coins without mining them, how will you detect the intruder?
It’s entirely possible in principle to have a zkSNARK proving system that does not have “toxic waste”. The rest of the Zcash protocol is independent of the proving system and only makes assumptions about it that are standard for the zkSNARK abstraction. There has been some recent work on such systems by the libsnark and Zerocash authors: Science Roundup - Electric Coin Company , but it is not yet practical. On the other hand, SNARKs were not practical at all only a few years ago, so I’m quite optimistic that this is solvable, probably within the life of Zcash barring any unforeseen disasters. Also as @zooko says, we have other ideas for auditing the monetary base that don’t depend on any new cryptography.
It shouldn’t be possible to send ZCash openly like bitcoin, that compromises it’s security. It damages fungibility by providing a mechanism to easily “blackist” anonymous transactions, and also allows tracing of funds through open transactions, possibly revealing information about parties that are trying to remain anonymous.
The only way a person could be fully confident that their transactions are anonymous would be to only send and receive transactions that are not open. (IMHO, that shouldn’t be optional.)
If an adversary wanted to blacklist anonymous transactions, then making all zcash transactions anonymous would result in zcash as a whole being blacklisted.
We don’t think that the existence of transparent transfers will in practice significantly compromise the resistance of Zcash to blacklisting attacks, because it will only be possible to trace UTXOs back to previous JoinSplits. The intended usage is isolated “islands” of transparent transaction usage in a sea of private transactions, not vice versa. Of course it is difficult to predict actual usage, but the purpose of Zcash is privacy, and I believe its user base will be sufficiently invested in that to accept the overhead of JoinSplits.
A possible solution to the problem of “toxic waste” would be implemented on the client zcash functionality protocol in periods of time (I do not know, every week) each network node zcash would have to generate a public key shard and destroy their corresponding private key. The network would reach a consensus on this public key all transactions must be verificas from there (like a new genesis block).
With the gradual increase of us would be (statistically) increasingly unlikely that all of us were in conspiracy to report his shard of the private key. Thereby creating an increased resistance in the network growth over time.
Obviously only that functionality would not succeed unless there was a way to monitor the total amount of the Market cap the currency. At any time, when a block is detected to show that fraudulent coins into the system, this block would be discarded and a new one would be generated as described above.
That’s an interesting idea. It’s not feasible with the current MPC setup because it’s a multi-round protocol and requires substantial computation – too much to be verified as part of the consensus protocol. I would also be worried about it providing attack vectors that aren’t possible when the MPC is only done infrequently.
I don’t see how new MPC setup could help audit total monetary base. It would just reduce level of trust required for proving and verifying keys.
Btw, once the current parameters are replaced with this new MPC setup, is it possible to know if current setup were compromised (with money being printed secretly) before new setup is put in use?
(To be precise, this doesn’t guarantee that the current setup was not compromised, just whether or not there has been any overall unexpected inflation of the monetary base.)
