Hacker News Reader

Comment by woah | Hacker News Reader

Are you talking about the fact that Zcash has, as a feature, the ability to make non-anonymous payments as well? Why would this be of interest to anyone studying the anonymity properties of Monero?

View on HN

> Are you talking about the fact that Zcash has, as a feature, the ability to make non-anonymous payments as well?

Last I checked virtually none of Zcash's transaction used the anonymous payment feature (presumably because the performance of it is very poor).

So it's plausible that monero transactions could practically end up with a larger anonymity set in absolute terms than zcash (especially for current monero, which has CT and a minimum mixin size).

I think it would be more accurate to say that Zcash, has, as a feature, a way to make anonymous payments, but it is rarely used.

There is nothing preventing memory usage from being brought into the ~250MB range. The performance issues stem from a legacy codebase built by academics and a focus on safety and enterprise features.

>So it's plausible that monero transactions could practically end up with a larger anonymity set in absolute terms than zcash (especially for current monero, which has CT and a minimum mixin size).

No, it isn't. There will always be a transaction graph between accounts, which limits the total number of possible routes between two participants in a trade.

To correct a minor point, none of the current Zcash code comes from the Zerocash academic prototype. All of the code that had come from the prototype was rewritten before launch (mainly in https://github.com/zcash/zcash/pull/625 ).

Much of the performance issue comes from a single design decision made in Zerocash: to use SHA-256 for the Merkle tree, PRF, and note commitment hashes. We'll be changing this for the Sapling update.

-- Daira Hopwood (Zcash developer)

My apologies, I had assumed the codebase was legacy due to some lamentations about not being able to use Rust.

I hope my portrayal of the performance issues was appropriate.

The legacy codebase issue we are lamenting there is just that the code inherited from Bitcoin is in C++. It's of course possible to interface between C++ and Rust, and that's what we're intending to do in future. It would have been risky to try to do that in the code we wrote before launch.

Yes, your portrayal of the performance issues was fine.

In the next version we'll clarify zcash shielded transactions are optional. Fwiw it's used by 28% of tx according to https://explorer.zcha.in/statistics/network and comments above, not "rarely used"

I'm not certain the source of these shielded transactions but the vast majority of value seems to be in unshielded transactions. Transparent value (unspent TX + unspent block rewards) = 1,070,918 while shielded value = 42,588 or around 4% of all value. That sounds like rarely used for transactions of any value to me.

And how much of that is from miners who immediately cash out move it to a transparent address?

Here are current stats about shielded and unshielded transactions in the last hour/day/week/month:

https://explorer.zcha.in/statistics/usage

And here historical stats about shielded and unshielded transactions in the most recent 100 blocks over the life of the blockchain so far (about 6 months):

https://explorer.zcha.in/statistics/timeseries?supply=false&...

Note that a big part of the shielded transactions is because coinbases are required by the consensus rules to be shielded when first spent. This was in order to provide a guaranteed privacy-set. If you make a shielded Zcash transaction today there is actually a very large privacy-set of possible previous transactions which could be inputs to your transaction.

In the long run we intend to improve the functionality of Zcash shielded addresses and to deprecate Zcash transparent addresses, so that all transactions are shielded and so that the user experience is simpler.

.. ask the author. He's the one that put that in the paper. Didn't you read it?

Reply on news.ycombinator.com