Comment by josu | Hacker News Reader

Comment by josu | Hacker News Reader

Parent Full thread

You are completely right, I hadn't considered that. This is what Zcash has to say about it:

Since the value sent between shielded addresses is private, how can we determine the number ZEC in circulation?

Currently, we know that 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 someone could 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.

We are investigating options for the future which would enable accounting for all ZEC in existance(sic). Stay tuned to our blog for any proposals on this matter.

https://z.cash/support/faq.html

This type of challenge is implicit in any cryptocurrency with strong confidentiality (i.e. which conceals the amount being transferred from public view) unless you trust the "inputs-equal-outputs" proving mechanism (which, in Zcash's case, is the zk-SNARK that accompanies a shielded transaction).

One potential solution is to periodically require that all coins be unshielded (i.e. sent to a t-address) and passed through a turnstile mechanism (thus allowing them to be counted). After a reasonable amount of time, a new consensus rule kicks in that prevents coins from being spent unless/until they've been put through the turnstile. That would effectively allow for a full audit of the monetary base without compromising privacy.

What? This is totally incorrect. It is perfectly possible to build systems that verify total issuance while concealing amounts. Blockstream's Confidential Transactions does this, for example.

So you trust Pedersen commitments and range proofs to prove that the inputs to a Confidential Transaction equals its outputs?

As much as the elliptic curve discrete logarithm problem can be trusted to be intractable, yes. For which bitcoin has some billion dollar in bounties:-)

The crypto used in Confidential Transactions, or any implementation of it, does not only rely on ECDLP. There's plenty of scope for potential protocol or implementation errors. (The Zcoin issue, remember, is an implementation error.)

The CRYPTO relies only on ECDLP. That word, as it is usually used as a term of art, indicates the underlying mathematical assumptions. to say "it does not only rely on ECDLP" is to indicate that there are other trusted mathematical security assumptions, such as harness of EC pairing or the knapsack problem. This is not the case with confidential transactions, whose Pedersen commitments and Back-Maxwell rangeproofs rely on the exact same cryptographic assumptions as any bitcoin signature. It even uses the same library to create and check these commitments, with a minimal amount of new code.

Is there scope for new implementation errors? Yes, but only in the fully generic sense of it involving _some_ new code. Anything that is different involves changes, and any change brings the possibility of an implementation error. However Blockstream has tried to keep confidential transactions as close to the underlying bitcoin code base as possible to minimize that error, and unlike other solutions CT has been subject to academic review and external security audit.

I'm not aware of any proof that Borromean signatures, relied on by CT, are secure assuming only ECDLP. There is certainly no such proof in the paper https://github.com/Blockstream/borromean_paper/blob/master/b... .

[Edit: updated paper link to the most recent version, which still doesn't have any proofs.]

As does Monero's RingCT, which is based on Blockstream's Confidential Transactions.

Obviously there are implementation risks, but in terms of cryptographic risk you are correct.

Reply on news.ycombinator.com