Critically important discovery regarding anonymity for crypto-currency, which renders my Zero Knowledge Transactions white paper (and as well Shen-Noether's both) worthless

Ring Confidential Transactions built on top of Blockstream's Confidential Transactions (or my roughly equivalent but apparently more efficient Zero Knowledge Transactions built on top of Denis' Compact Confidential Transactions) does not absolutely prevent undetectable abuse of the money supply.

The relevant (to your stated concern) distinction from Zerocash (and a friendly reminder to not conflate Zerocoin with Zerocash because the former requires equal revealed values and doesn't integrate with hiding values) is that there isn't a global trusted master key (generated once at setup of the sytem) to be potentially abused (if the trusted setup was gamed some how). Yet in both systems, if you can muster enough computing resources even just once (and/or break/weaken the number-theoretic cryptographic assumptions security), you can create unlimited money out-of-thin-air and this can't be detected (unless detection means everyone has the same level of breakage capability and all values can be globally unmasked rendering value hiding useless).

Homomorphic values and ring signatures come with potentially huge anti-DDoS costs as I have been explaining in a thread I started in the Bitcoin Discussion forum. In that thread, I have alluded to we might be better off to just eliminate homomorphic (hiding) values and also eliminate Cryptonote's one-time ring signatures and move to something like CoinShuffle, because we are going to need to do a CoinShuffle any way. The details on this tradeoff need to be further mulled over and elucidated.

So in summary, it is possible that Monero and Cryptonote (including Confident Transactions and the attempts to combine them with one-time rings) is one grand waste of time and effort, but that determination is not yet entirely clear to me. I need to spend some time writing down all the details so I can convince myself what are key determinants on this issue. It is possible that the conclusion may be a multifurcation.

Anonymity is very difficult to accomplish holistically especially at-scale (Monero is no where near accomplishing that at-scale) and it doesn't come for free.

Zerocash does hide your identity on the block chain even if your IP address is correlated across multiple transactions that you send to the block chain, because in Zerocash the payer(s) and payee(s) are obscured and proven in a non-interactive zero knowledge proof (NIZKP). This is accomplished by proving that the machine ran a certain program (and no other program) on the inputs and that result was "true" (i.e. verified), rather than proving something algebraically about the variables to the program. This computational witness requires the global master key setup.

Whereas, Cryptonote one-time rings mix the payer amongst a group of payers with the requirement that it is publicly verifiable that each payer can only be spent one-time. The one-time key is manufactured by the Diffie-Hellman (ECDH) like exchange that creates a new stealth payee address on each spend and that stealth address can only be spent once. So the problem is that if your IP address is correlated across spends, it becomes possible to link stealth addresses together as the same payee and then start to unmask the anonymity set of the payer rings.

So it would seem that Zerocash is the solution, except read my discussion at the quoted link about anti-DDoS protection. The problem is the huge verification cost for each Zerocash transaction and thus giving the attacker a huge asymmetric advantage when sending invalid transactions, i.e. unprotected Zerocash can be DDoS'ed to death.

And if using my suggested technique to create a hash-based signature as a first line of verification of incoming transactions sent to the block chain, then you've got to incorporate a simultaneity mixnet such as CoinShuffle to detach these hash signatures (and the payee's IP address) from the Zerocash transaction being submitted to the block chain. But then your anonymity is reduced back to the mixnet again so you've lost the benefits Zerocash provides. Perhaps Zerocash could devise a quick check on invalid signatures. I don't enough about the "moon math" in the white paper to deduce whether that is possible, but I 95% doubt it based on my understanding that such NIZKPs are a holistic math affair.

Perhaps instead of my hash suggestion (and as suggested by Gregory Maxwell at the aforementioned linked thread), each Zerocash (or RingCT) could require some PoW be attached to every transaction to rate limit spam, but the problem is the attacker has an asymmetric advantage by being able to place his hashing resources in venues with the cheapest electricity (e.g. 3 - 4 cents per kWh in WA State or China near hydropower) and leverage the latest ASIC efficiencies whereas the legitimate payer is running on retail electricity that costs 4 times more and non-optimum hardware that is at at least an order-of-magnitude disadvantage in power and speed. So the delay (or the transaction fees if the full nodes speed more on hardware to increase their spam bandwidth) will increase for legitimate payers asymmetrically to the attacker's costs. And that asymmetry will be amplified by the systemic ratio of the resources of the legitimate payers to the attacker's resources, thus if the anonymous system is only used infrequently then the cost of using it will be radically amplified (perhaps too high to be of practical use, although I haven't done some sample calculations yet). And for the system to be widely used (e.g. for microtransactions) the extra costs imposed by the attacker disincentivize its use when the legitimate participants don't value anonymity as a concern. Also the PoW required could vary per full node and vary in time (even in real time!) depending which nodes are receiving the most incoming DDoS spam, which complicates the determination where to submit a transaction and how much PoW is required to be submitted with it. So then it appears any any such Zerocash + PoW anti-DDoS system is going to be used only for anonymous mixing and not all transactions, but then the problem is the anonymity leaks as these anonymous mixes are then traded for coins in a system that is used in everyday commerce (e.g. microtransactions).

Even though I haven't thoroughly understood every technical aspect of it, the other problem with Zerocash appears to be that it can't merge the entirely opaque block chains, e.g. if there are two major chains fork due to a network split. Transparent block chains can be re-merged to the extent that double-spends are not intertwined. The major fault for Zerocash (that is not present for transparent block chains) being that I believe it is not possible to prove which coins were double-spent on both of the block chains. Normally this isn't a problem for an orphaned chain because you just throw away the orphans, but this is perhaps a problem in a major network split.

A ha! End-to-end identity anonymity is possible!



There is a simple solution for DDoS with Zerocash. Use my hash-based signature suggestion on a non-anonymous basecoin, when sending the anonymous zerocash (the Zerocash paper names these zerocoins, not to be confused with Zerocoin) transaction. Since on a spend transaction (aka pour) the anonymous coins are entirely mixed with all anonymous coins, then your IP address and your non-anonymous transactions do nothing to help anyone trace the anonymous coins. And putting the non-anonymous funds at-risk with the fast to verify hash-based signature (3 million verifications per second on an 8 core CPU!), solves the DDoS attack issue.

Alternatively it may be possible to mint the hash signatures in such a way that the anonymous coins are forfeited when doing a DDoS attack, but are still not non-anonymously linked to the hash based public key, instead of needing to use a separate non-anonymous basecoin. This would be preferred for permissionless commerce.

So thus unlike RingCT, no CoinShuffle (mixnet) would be needed. Unlike Cryptonote (and RingCT), Zerocash hides everything because the inputs to the NIZKP are never revealed! This is the advantage zk-SNARKs because it proves that a program compared the inputs in the desired way, without revealing what the inputs were. Whereas in CN and RingCT, we all see the input public key addresses and the proof of which public address is spending is obscured by the mix, but correlating the IP address across mixes can correlate which of those addresses were in both mixes. For CN and RingCT to be as anonymous as Zerocash would require they mix with all known (and future!) public key addresses.

Note that zk-SNARKs are very slow to verify (roughly 300ms for a Zerocash transaction) and consume more bandwidth so this can't be used for all transactions. It would be a mixer that you mint non-anonymous coins into when the slow verification and its higher fees are justified.


Apparently I am mistaken. Zerocash coins have serial numbers, so it should be possible to know which serial numbers have been double spent on both forks.

We can't escape from proof-of-work (PoW) and maintain decentralized consensus. Period.

By placing that comment in this thread about anonymity, that exhibits to me you don't have a very good grasp of the technologies of crypto since block chain consensus algorithms are orthogonal to anonymity algorithms.

Trees and DAGs are not a solution for block chain consensus (and they have nothing to do with anonymity). They fork uncontrollably. This will all be explained. Just let Iota, Railblocks, etc. go forth, then at the appropriate time it will be explained they are technically flawed. We can't escape from proof-of-work (PoW) and maintain decentralized consensus. Period. Proof-of-stake is discussed else where and I don't to repeat what I have already written in my archives (someday I will summarize it all in a paper).

Please explain the relationship between zk-snarks and trees.