ewillbefull

There's no absolute requirement for using Facebook to communicate with others over the Internet, so there's no sensible reason why they (or anyone else) should be compelled to host content they don't like.

Just because certain platforms are popular doesn't really change things from a legal or a moral perspective, and it might be because of their editorial discretion that they are popular in the first place.

Banks, electricity companies, railway operators

These are bad examples in a discussion about speech protections... those businesses are providing services, not just engaging in speech.

Also, those businesses _do_ act to arbitrarily refuse to serve people. My bank sent me a letter last year saying that in ~10 days my account will be closed and they'll send me a check with the account contents. No reason, no appeals.

The 'trapdoor' is in the protocol by design.

Only due to ignorance. It is well known that the bases of a Pedersen commitment can and should be sampled randomly; a trusted setup is only subverting the security of the primitive.

That's great! There are many issues with trusted setups that people aren't paying enough attention to.

There is nothing new about this article. The article is pointing out that in addition to the trapdoors of the proving system, it's possible to subvert the arithmetic circuit used as well. The ceremonies used by Zcash have the property that the parameters are perfectly bound to the circuit.

Not sure why this isn't mentioned in the article.

This article is about the fact that there could be a backdoor, whose absence can only be proven by revealing all participants' toxic waste.

This is incorrect, as stated above. Instead of revealing their toxic waste, we reveal proofs-of-knowledge so we can use pairings to ensure the parameters encode the circuit correctly.

https://en.wikipedia.org/wiki/Brainfuck

The HolyJit repo has a brainfuck jit example in the repository: https://github.com/nbp/holyjit/blob/master/examples/brainfuc...

In our case, the use of grsec was one of the simplest counter-measures that achieved an almost purely additive security improvement. That's even when accepting the risk that grsec has security bugs in it.

If the participant did everything right, one of the only remaining ways that the secrets could be exfiltrated from the machine was by exploiting a theoretical vulnerability in xorriso, the software we use to read/write DVDs for airgapped communication in the ceremony. Even then, it was likely to leave an evidence trail on the DVDs for post-hoc review.

As an extra precaution, we needed to impose strict policies on the xorriso process. Grsec was trivial to employ using off-the-shelf Alpine Linux tools, and didn't require any dependencies which would increase the cost of auditing afterward. Grsec was also not likely to introduce bugs we couldn't catch in post-hoc review due to the evidence trail left on the DVDs.

The hope was to force an adversary to exploit both xorriso and grsec in practice. One important question is: was grsec likely to introduce a category of bugs that would not otherwise exist in Linux already? I think the answer to that question is no. Funny enough, just a day or two before the ceremony the Dirty COW vulnerability was patched in the Linux kernel, and we just managed to update our OS before the scheduled ceremony.

I'm Sean from Zcash, I coordinated the MPC and wrote the software. I messaged you on twitter or emailed you or something about this last year.

it made it sound like I repeated the number uncritically

I didn't say you regurgitated it. I said the person you talked to did, presumably after looking at libsnark or an unrelated paper.

The fact that competent experts could be unfamiliar with Zcash's crypto to the degree that they could disagree on basic facts like that is a sign of concern, precisely because it's yet another strong sign that the crypto is quite new.

I claim the person you talked to was looking at the wrong curve construction. 2^80 is quite a torch to carry into an argument and no experts that we know have ever suggested a security level less than 2^96. The only "disagreements" about security were far more subtle and reasonable than what your blog post suggested.

https://eprint.iacr.org/2017/602

The protocol scales linearly with respect to the number of participants, but as you can tell, each participant needs to do a lot of time-consuming computations.

Each participant needs to maintain custody of the hardware during the process of the ceremony, and then destroy the hardware afterward. If it was your turn, you'd do some stuff for an hour, and then it's the next person's turn in a round-robin circle. You had to wait maybe ~8 hours before it was your turn again. The protocol involved three rounds of this.

Nobody can abort (players commit to their moves in advance to defend against adaptive attacks) and so there needs to be a time when all N participants are available for the entire duration of the ceremony. This makes it very sensitive to scheduling problems.

If you want to do your own MPC, you also need to perform very expensive fast-fourier transforms in between round 1 and 2. In our ceremony that required a very beefy 128-core server and it still took over an hour.

I actually just found a log file from the ceremony's coordinator server (not a privileged server, just handles messages and archives them) which shows the timings of everything, which is kind of fun:

https://gist.github.com/ebfull/fde1e167ba35ca67e086ca458eabc...

The protocol could not scale to a large number of participants at the time. Just with six participants it took an entire weekend to perform.

To both yourself and the person you're replying too, please don't put words in my mouth.

What words did I put in your mouth? I cited the 2^80 figure in your blog post and a reasonable theory for why you would bring up such a figure. "Regurgitated" came across as snide so I apologize for that.

Note that you used this unsubstantiated figure to say "the fact that there’s disagreement is a bad sign." If there isn't actually any disagreement and the figure is unsubstantiated, why is it not baseless FUD? (BTW I notified you of this error in your blog post some time ago but never heard back.)

what I said is that post-hoc review hasn't been done, even a year after the fact.

I know, I wasn't replying to you. As I said, I believe more auditing is needed. I also don't believe some kind of one-and-done audit of the software/deterministic builds would satisfy either of us.

2^80 is not very weak. That's the level of brute forcing a SHA-1 collision. It's low for a new system, but not very weak.

Note that the 2^80 figure from Peter's blog post is really unsubstantiated. There's another curve in libsnark (which we don't use) that has 80-bits of security. I suspect what happened is whoever Peter was consulting with just repeated this number to him. We've spoken to many cryptographers who are experts on these curves, and none of them think that figure is reasonable. I actually don't believe there are _any_ cryptographers that have publicly made such a claim about the security.

2^96 was the original conservative estimate when the NFS attack was discovered, but subsequent analysis showed concrete security closer to 2^110 (and that's ignoring the unrealistic memory costs of the specific attack.)

How can they not have the basics of a secure toolchain?!?

We provided participants with a reproducibly built and stripped down version of Alpine Linux, employed grsec, wrote all of our crypto software in pure Rust, etc. All of our software is reproducibly built, hashed and signed. There is nothing (software-wise) that cannot be caught in post-hoc review. All of it is open-source: https://github.com/zcash/mpc

Several academic papers regarding our protocol have been published since then. We wrote a full security proof of the crypto. We hired NCC group to audit the ceremony as well: https://z.cash/blog/ceremony-audit-results.html

More auditing can always be done but this is a continuing process. The primary goal is to make it difficult for someone to undetectably compromise the ceremony.

Zooko explained afterward: https://twitter.com/zooko/status/864341289374023680

Zero-knowledge proofs for a given statement, by definition, reveal nothing about its witness. zk-SNARKs (used by Zcash) are statistically zero-knowledge; there are no cryptographic assumptions involved.

There is a tradeoff here that keeps being missed.

Ring signatures with small anonymity sets have very serious privacy drawbacks, but they have more sensible assumptions for protecting the monetary base integrity.

zk-SNARKs are the opposite: they don't compromise on privacy at all, but require stronger assumptions to protect the monetary base.

Zcash's zk-SNARKs are totally private even if that ceremony failed and even if the cryptographic assumptions underlying zk-SNARKs fall apart.

I find the comparison with Bitcoin perfect. The same people trusting PoW cartels to keep their system operational are complaining that zk-SNARKs require a parameter setup for proof soundness? That doesn't really make sense to me.

The next survey should ask which nightly-only features are keeping them on nightly. :)

I think you misread the parent comment. :)

It depends entirely on what you're doing. There are people who "save" cryptocurrency and depend on its long-term value, but there are also people who are more worried about going to prison (or being murdered/extorted) than whether their coins will be worth anything in a few years.

The problem is that non-private cryptocurrencies are permanent records of financial activity. I would rather risk soundness now than privacy forever, especially when there are post-quantum paths forward and our current assumptions are reasonable.

Some people (myself included) would rather the system become worthless than anyone's privacy being at risk.

At the time, the multi-party computation protocol could not scale to a large number of participants.

Worth adding here that it also appears Zcash stakeholders have been internally buying/selling their own ZEC at inflated prices on Poloniex to artificially increase both volume and the market price.

I don't understand this. None of the stakeholders have even received their money yet; this is publicly verifiable.

Mostly, I would urge people not to use Zcash for situations that require real anonymity. E.g. wikileaks accepting donations, or routing around captial controls in oppressive countries. And this is because I do not believe that the cryptography will hold up. There's too much of it, it's too new, and it's too interesting

I would disagree; the cryptography that people are more skeptical of in Zcash involves soundness of the zero-knowledge proofs. (i.e., if counterfeiting could occur) Privacy is protected by standard cryptographic assumptions that are relied on in other systems.

why only six

The protocol is expensive; it took 2 days with 6 people. After a certain point, it's not practical to add more participants without increasing risk. It requires gigabytes worth of communication per participant and many millions of curve operations.

The article you're citing is wrong. (I know because I fixed the bug.)

You misread my comment. There _is_ an oustanding privacy issue in Monero, one that is often overlooked by its proponents. Transactions involving the same individuals will appear closer together in the transaction graph, and this remains the case so long as Monero's transactions have so few mixins.

My favorite example of anonymity is Richard Stallman's description of an anonymous currency: you should be able to pay a publisher for every article you read on their website, without them being able to associate the payments.

There's a lot of absurdity in your comment, but I wanted to reply to one thing:

Not only that, the anonymity feature didn't work. You can't send to "z addresses" only.

This is untrue, there was a bug that _delayed_ mining of some transactions to z addresses, but not all of them, and it was fixed last week.

Disclosure: I am an engineer working on Zcash.

Anonymity is not a binary. Monero, even with the addition of RingCT, is vulnerable to transaction graph analysis (intersection attacks) that can de-anonymize users. Zcash takes a completely different approach that achieves ledger indistinguishability -- shielded transactions in the blockchain have no apparent relationship with each other, which is an essential privacy benefit.

Much of what I read in that thread is wrong or misleading: Monero does not have a trusted setup, but it's important to note that a failure in Zcash's setup does not disrupt the privacy of the system. The "poison-pill" vulnerability is not a concern in our system. The claims about the anonymity set are very misleading. It is possible to do far more than multi-sig in our system, we just haven't implemented it yet. The point about mining is specific to the paper and is irrelevant.

There are downsides to the system, such as our performance problems, but they are solveable given time. Zcash is obviously not the only player, but it's also going to continue to grow and adapt and improve, just like other cryptocurrencies will.

That's not the full picture.

Zcash has a "mining slow start" which slowly ramps up the mining reward for the first two weeks, to reduce the threat that a large amount of the ultimate monetary base would be in control of early-advantage miners. As a result of the significantly reduced supply, the price was very high shortly after launch.

Zcash requires two states, a state analogous to bitcoin, and the anonymous zcash state which has to be explicitely opted into.

It does not require two states, this is a misconception that originates from the paper which refers to "basecoins" and other obsolete terminology. The protocol was anticipated to be a sidechain of some kind, but due to technical limitations that never panned out. Our system does use two states, but I personally advocate for removing the "transparent" system in the future when we have things like private multi-sig.

Cryptonote are also auditable if a user wants to reveal information about a transaction. But even then the information is limited, it will show that payments came in and out of specific amounts, but it won't show the sending/receiving address along with those transaction IDs.

You can do all of this with our system as well, it was one of our design goals!