> BLAKE3 appears to have 128 bits of security against all attacks.
That's not accurate. The best pseudo-preimage attack on BLAKE2s has complexity 2^{253.8} against 6.75 rounds (section 3.2 of https://eprint.iacr.org/2019/1492.pdf ). The best full-preimage attack on BLAKE2s is against 2.75 rounds. BLAKE3's round function is identical to BLAKE2s (although used in a different mode). Currently there isn't any known classical preimage attack on BLAKE3 better than these ones against reduced BLAKE2s. This should be interpreted with caution since the design has only just been published.
[Disclosure of interest: I know Zooko and work for Electric Coin Company. This is only based on a cursory review of the paper, though; I had not seen it prior to publication.]
Disabling SharedArrayBuffer is just stopping the most obvious method of exploitation; it's by no means a fix. Expect a slew of papers over the next few years on other methods of exploitation from JS.
But you don't detect that one case where you are actually compromised. You dismiss it like you do all the false positives. At best, when you get pwned you think back to having dismissed the key change warning and know what happened, but how does that actually help you?
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.
As far as I know we've never claimed that the distribution is flat or that the "effective anonymity" is equivalent to a uniform distribution over prior notes (I certainly didn't claim that). One of the advantages of Zcash's approach is that you don't need to know the distribution in order to have a strong privacy claim. As I said, this is because the content of a transaction is not revealed, and so the attacker's advantage is no better than guessing based on their prior knowledge (plus the little information that can be inferred from timestamps and number of JoinSplits in a transaction).
It's the same claim as for semantically secure encryption, for example: no competent cryptographer would claim that encrypting a message implies that the adversary's knowledge of the plaintext distribution is uniform; only that the ciphertext gives the attacker no further information (apart from length, typically) about the distribution.
The comment to which I replied (not by you) claimed that the anonymity set is all shielded transactions.
It is, in the same sense that the first order anonymity set of Monero transactions is all outputs included in the ring signature which can't be proven implausible (e.g. using the methods in Section 3 of the paper). However, Section 4 of the paper points out that a non-uniform distribution means this is reduced, in practice, to a smaller effective degree. The same method can be used with Zcash to estimate a smaller effective degree since many previous shielded transactions are probabilistically unlikely.
This is certainly not 'deanonymization' or 'tracing' or any such thing, but it isn't that in the Monero case either.
Note that the number of prior shielded transactions (not the proportion, and not the value) is what is actually relevant to the privacy of new shielded transactions. Roughly speaking, the privacy you get with Zcash is comparable to what you would get with Monero if you could use all previous shielded transactions (over 120000 of them, currently) as mixins. That's why the criticisms of Zcash based on the percentage use of shielding (either by transactions or value) are totally missing the point.
The number of note commitments can be found using 'zcash-cli getblockchaininfo' and is currently 301068 commitments, i.e. 150534 JoinSplits (so a bit more than the 120000 I said).
This bug had nothing to do with Zcash. Please correct your comment to say Zcoin, if that's what you meant.
In any case, Zcash is also derived from Bitcoin and builds with `-Werror` (edit: not `-Wall`, but we're working on that). That kind of minimal static analysis is certainly not sufficient to catch the majority of bugs, though.
C++ is not memory safe in any meaningful sense. There have been efforts to define a memory-safe subset, but typical large codebases, including Bitcoin, do not come close to falling within that subset.
Zcash, for example, is built with `-Werror` (edit: not `-Wall`, but we're working on that). So this is absolutely feasible on a Bitcoin-derived codebase.
That's not accurate. The best pseudo-preimage attack on BLAKE2s has complexity 2^{253.8} against 6.75 rounds (section 3.2 of https://eprint.iacr.org/2019/1492.pdf ). The best full-preimage attack on BLAKE2s is against 2.75 rounds. BLAKE3's round function is identical to BLAKE2s (although used in a different mode). Currently there isn't any known classical preimage attack on BLAKE3 better than these ones against reduced BLAKE2s. This should be interpreted with caution since the design has only just been published.
[Disclosure of interest: I know Zooko and work for Electric Coin Company. This is only based on a cursory review of the paper, though; I had not seen it prior to publication.]
-- Daira Hopwood