Well yes, they were not wrong to cite the ability to detect hacks like this as a feature over zcash. This same class of error could exist in zcash and we would never know. We know it happened here because of the ability to audit.

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.

Smells like the original Jurassic Park!

But at the insistence of Malcolm, Arnold tries different ways of counting the animals on the computer. The count reveals that there are 292 animals in the park, much higher than the official figure of 238. Malcolm concludes that the animals, including the deadly velociraptor, are breeding. Wu cannot believe it, because all the dinosaurs are female. http://www.novelguide.com/jurassic-park/summaries/iteration3

Or alternatively, the developers designed this hard-to-find typo/bug years ago and have now just quietly cashed out.

Seems very unlikely since it would inevitably cause many to lose faith in the currency. If they really want to cash out, they can just do what almost every other upstart cryptocurrency founder does and make it clear they're taking some of the pie.

If they just want out, the things that happen to the currency don't matter to them - they're already gone.

That's true, but if this was the epic exit scam they were planning for so many years, it's a bit disappointing.

410 BTC is half a million dollars.

True, but many of these currency founders are looking for millions.

Not saying it's impossible this is a scam, but I still doubt it.

You're assuming the one who introduced the bug was a founder with the ability to do that.

That's the assumption the parent poster made, not me.

Uh, no it's not. You're the one that mentioned founders. The parent poster just mentioned developers.

He said "the developers" and "years ago", implying the founders.

Making a currency is already a gold mine. Mine the first 100k coins and hide them for 5 years.