Privacy and inflation in cryptocurrency are not technologically mutually exclusive, they’re mostly orthogonal. Eg, yes, technically you can have both.
The problem is that in purely a private, zero-knowledge cryptocurrency, it’s difficult or impossible to inspect the actual currency issuance rate and ensure that some Byzantine miner/validator hasn’t found a way to hack the issuance algorithm and issue more currency (to themselves) than the system is designed to. For example, ZCash had a famous bug regarding this issue a few years ago, that they patched before disclosing it.
That’s an ongoing technical challenge the industry is working on.
> The problem is that in purely a private, zero-knowledge cryptocurrency, it’s difficult or impossible to inspect the actual currency issuance rate
Satoshi could have made mining reward increase at 2% per year, but very deliberately decided on hard cap on how many will exist. This decision made early adopters literally and metaphorically invested in bitcoin's success.
Are you saying that some detail of zk-Snark makes that not possible for cryptocurrencies based on this technology?
No I’m saying the exact opposite. The inflation schedule can be any arbitrary algorithm. It can be a fixed amount like Bitcoin, or a continually increasing one like your 2% example.
Zk-snarks don’t change that. It’s still a choice by the developers based on the economic objectives they’re trying to achieve, and snarks don’t prevent that.
But problem is that in a fully-shielded, 100% private, snark-based blockchain, it’s difficult or impossible to verify that the actual coin supply is what the whitepaper says it should be. Since all the tx’s are hidden, you can’t inspect the blockchain data and just count all the coins in UTXOs or account holdings to see what the total money supply is at any given time and reconcile it with what the issuance algorithm says it should be.
Lack of transparent supply auditability is a feature not so much of zk-snarks but of Confidential Transactions, which use Pedersen commitments to obscure amounts. Knowing the discrete logarithm of just one particular point would completely break these commitments and all cryptocurrencies based on them, by allowing undetectable inflation. They thus require complete confidence in the computational hardness of the Elliptic Curve Discrete Log Problem.
Yup, fwiw I'm not actually aware of a fully shielded zk-snark cryptocurrency in production yet, was just using that as a hypothetical example, like a ZCash with only z-addresses.
Ouch what a nightmare. At that point it seems like the best way may be to start over? Like have everyone who can prove they have old-money get new-money on a first-come-first serve basis. If too much money shows up you know you got owned. Otherwise you are fine. If too much money shows up years down the line, you just deny them new-money, which screws over people who bought-and-forgot but everyone else is ok.
>Upon detecting this condition, the Zcash Company would begin its investigation into the possible source of the vulnerability as well as which pool, or pools, are affected. If we are able to identify that the bug affects only a single shielded pool, we might choose to effectively deactivate that pool by invalidating any of its outgoing transactions. A necessary consequence of this action is that any legitimate funds would also be lost forever in the affected pool.
The mechanisms for this remote disabling are not mentioned in detail, and I don’t really mind, but this feature seems difficult to square with their desire for transparency. It’s an anti-feature perhaps serving a justifiable goal, but if this feature is possible to be abused, how would we even know if it had been?
I'm not sure what they mean there, but I'd guess they mean a hard fork. As with the Ethereum post-DAO fork, you don't have to accept it, but to the extent it seems legitimate, most of the value would go along.
It sounds like that plan has been codified in recent clients, so they should automatically reject transactions that would cause a pool's balance to go negative.
The problem is that in purely a private, zero-knowledge cryptocurrency, it’s difficult or impossible to inspect the actual currency issuance rate and ensure that some Byzantine miner/validator hasn’t found a way to hack the issuance algorithm and issue more currency (to themselves) than the system is designed to. For example, ZCash had a famous bug regarding this issue a few years ago, that they patched before disclosing it.
That’s an ongoing technical challenge the industry is working on.