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.