The Electric Coin Company, maker of Zcash, writes about zero-knowledge proofs, Halo, security audits, cryptographic history and company governance.
HN links it for Halo 2 and Zcash technical explanations, and commenters use it when discussing zero-knowledge proofs, rollups and privacy coins.
> * the fact that 20% of the block reward is given to the founders as a "fee". i.e. 6 people will end up with 20% of a "global currency".
This applied to the first 4 years of issuance, so it's actually only 10% of the total supply, and it went to not just founders but also advisors, investors, etc, and some was donated to the Zcash foundation, so the portion that was personal profit for 6 people was much smaller! The bulk went into... paying salaries for quite a lot of developers. Since then another dev reward was agreed on (for the next 4 years), but this is going directly to the company+foundation directly building Zcash with no "founder share".
TLDR: the share of the Zcash supply of which "6 people" are receiving through in-protocol issuance is much smaller than 20%.
> * the fact that it's a "privacy focused" crypto-currency and the CEO said "we can make it private, but not for criminals" i.e. backdoored. (https://twitter.com/zooko/status/863202798883577856?s=20)
Zooko did NOT mean backdoors; he meant things like KYC at exchanges and giving people the ability to voluntarily give "viewing keys" to law enforcement that prove which transactions they actually send/received.
See some follow up tweets:
https://twitter.com/zooko/status/863516385426755585
https://twitter.com/zooko/status/864342017605750784
> * the fact it's a crypto-currency with a CEO.
Fair point! Zcash governance is definitely more centralized in that way (though there is a lot of community engagement,…
Sure.
Starting from the academic beginning and then going to commercial usage: Zerocash[0], a paper from 2014 (I'm an author on it), proposes using zksnarks to get a public ledger + privacy with no centralized parties. Instead of identifying the origin of your money on the blockchain and moving it to someone, you just prove in zero-knowledge your payment is correct. This showed strong privacy on a public blockchain was feasible. But slow (2 minutes per payment IIRC)
Three years and much work by others later, it takes ~2 to 3 seconds on a Pixel three to make a zk-proof for a payment. This can be optimized down to 1 second fairly easily (on that you have only my assertion currently)
This is commercially deployed in Zcash (the above mentioned coin with usability and adoption issues), a few other straight up forks, and a new coin called IronFish. And related protocols are in a few things on Ethereum (e.g., Aztec). If you want to test performance numbers, you can download one of these systems and try it yourself (Nighthawk is a decent mobile wallet for Zcash)
Current technical objections (again, beyond criticisms of Zcash as a coin itself)
1) Current ZK proofs require trusted setup. New ZK proofs developed by engineers at Zcash removed this[1]. So its not longer an issue for the technology (or for Zcash once it's deployed)
2) you have to scan the blockchain to get notified of payments. No, this happens to be how Zcash does it. As I said in a separate comment, it's easy to…
Git isn't relying on collision-resistance, it's relying on second-preimage[0] resistance, which is to say: in order to sneak a hash collision in to a git repository, you have to sneak _something else_ that's already trusted (e.g. via code review) into the repository; collisions can't (yet) be generated for arbitrary hashes.
I haven't heard of any second-preimage attacks against MD5, much less SHA-1, so mlindner was correct in asserting that MD5 would be fine (assuming 128 bits are enough). See also the analysis in [1].
More to the point, if you're able to sneak something into a repository in the first place (e.g. a benign file that generates a collision with a malicious file), then you're probably able to sneak in something more directly (e.g. [2]) that won't rely on both getting something in a trusted repository and then cloning from a different, untrusted source.
[0]: https://en.wikipedia.org/wiki/Preimage_attack
[1]: this is getting a bit old, but should still be relevant? https://electriccoin.co/blog/lessons-from-the-history-of-attacks-on-secure-hash-functions/
[2]: https://en.wikipedia.org/wiki/IDN_homograph_attack
There are a few reasons.
1. Audibility. I know for certain that my BTC is safe, sitting in a UTXO that everyone in the universe can see. Counterparties can verify the provenance of the coin.
With Zcash and Monero, you face the risk of (invisible/unknown) inflation (a property of an unauditable supply), protocol bugs (such as failures in the zkp) and counterparty rejection due to lack of coin provenance. This risk affects the market price.
Both these scenarios have happened, and could happen again. The first generation of ZEC had a broken zkp, which could be traced back to errata in the academic paper. [1]
XMR (and other CryptoNote deriv coins) were failing to check for low order keys, so you could 8x-spend tx's.
2. Lack of exchange exchange support for US people, eg: real USD into XMR. 'not on coinbase'.
* Kraken does XMR, but they also do not have a bitlicense (NY residents are blocked).
* Gemini only has ZEC
[1] https://electriccoin.co/blog/zcash-counterfeiting-vulnerability-successfully-remediated/
[2] https://jonasnick.github.io/blog/2017/05/23/exploiting-low-order-generators-in-one-time-ring-signatures/
Even stranger are comments made in this link:
https://electriccoin.co/blog/defense-against-counterfeiting-in-shielded-pools/
Especially this part:
>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?
> To expand on this a little bit, non-default privacy means that use of privacy features becomes de facto suspicious activity, thus rendering them useless.
That's not a true statement as far as I understand how Zcash works. Right now there are >742K ZEC in the shielded Sapling pool, so there are quite a few people using it and you can not tell their shielded transactions apart.
https://electriccoin.co/zcash-metrics/
> Another issue with Zcash is that it had a trusted setup, which is not an issue Monero has.
Yes, but they took a number of steps to make sure that the ceremony for creating the trusted setup discarded the keys used and there was no one listening in. (they were geographically distributed and destroyed the hardware)