Folks, this is the biggest issue between us and the launch of a permanent blockchain, so please read: How To Generate SNARK Parameters Securely - Electric Coin Company
2 Likes
What about implementing a system in place that counterfeits and “blows a fuse” showing that the attempt was successful and therefore marking the attempt and the transaction, leaving a trace signature which would act as a 2 step verifying mechanism of that transaction. It would both automatically disallow someone else to counterfeit and act as a verified proof of the transaction. Hopefully that makes sense.
If a security researcher wished to demonstrate in a publicly verifiable way that they had violated a Zcash security property enforced by the zkSNARK circuit, such as balance, non malleability, etc., they could do that by revealing all of the transaction inputs (in technical terms, the zkSNARK witness).
It is not possible to force an attacker to reveal themselves in this way.
1 Like
Is there a way for the system to attack itself before anyone can attack it? and can that be used in conjunction with this:
"Perhaps there could be a way to audit the size of the Zcash monetary base, without compromising the privacy of any users. That way, people could at least say “Well, we can’t be 100% sure that someone didn’t steal the toxic waste private key, but at least we can tell that they have not (yet) used it to counterfeit money.https://z.cash/blog/snark-parameters.html
But instead of counterfeiting a large value, it would be zero or the smallest possible value.
I’m quite new to cryptocurrency and welcome corrections to what I say below and any elaboration anyone cares to offer. FWIW.
The blog IDs the possibility of collusion as an issue with the shard approach, which I gather would be lessened if mining were more diffuse. As I understand it, early in a cryptocurrency’s life, mining is often very diffuse, done by individuals easily enough, but eventually if there’s enough profit potential, there’s a huge move towards dedicated hardware (ASICs I think) in places with cheap electricity and the incentive for individuals to mine disappears.
I’ve been reading comments on the issue tracker over at github and I believe I’ve seen several references resolving issues in a way that discourages that centralization, though I haven’t sensed that this is a top priority (I could be wrong about that). Less centralization should mean less opportunity to collude, and while you might never reach absolute zero chance of counterfeiting, diffusion should make sharding stronger. Right?
So my question is, does this counterfeiting issue make resolving other issues in ways that prevents/limits centralization paramount? Not just in theory, but is that something you’re actually prioritizing now in development for that reason?
Thank you =)
1 Like
Hello CCQ. Welcome!
The potential for collusion described in How To Generate SNARK Parameters Securely - Electric Coin Company is not about mining, it is about the secure multiparty computation to generate the SNARK parameters.
You are right that we do want to decentralize mining.
2 Likes
Looks like I have a lot more reading to do, but it helps to learn more of what I don’t know. Thanks for the reply =)
why not extend an invitation for the entire cryptocurrency community to participate in the generation?
If it is well publicized on bitcointalk, reddit, coindesk, etc, etc, and everyone has a chance to participate then that should pretty much quell any doubts about collusion, right? Especially since if even just one person deletes their key, it is secure. So a rational person will conclude that if I participate, then I will be certain it is secure and will be a much better advocate for zcash in the future.
yes? no?
1 Like
The messages that have to be passed from one node in the Secure Multiparty Computation to the next node are on the order of gigabytes in size. And, if any node fails (stops responding), the rest of the nodes can’t make progress without it, so we’d have to kick that unresponsive node out of the Secure Multiparty Computation set and restart the protocol.
So, for a bunch of practical operational reasons we can’t handle lots of participants.
2 Likes
From what little I understand, it seems air gapping any of the nodes would introduce too much latency, because the computation will require hundreds of thousands of rounds, and the nodes have to pass gigabytes of information in each round.
I have been trying to think of possible ways that an air gap might be made with an acceptable latency.
Would it work to use a fast blu-ray drive and a disk changing robot, something like one of these, but modified to swap the disks between two different drives?
or this one:
http://www.britishideas.com/2013/09/03/jack-the-ripper-bot-i-introduction/
Another possibility I wonder about, if the blu-ray system is too slow, would it be practical to make a special purpose memory board which would be alternately connected and disconnected to the air gap computer and then a bridge computer, using mechanical switches?
Or how about an SSD drive or an SSD RAID, setup so it gets mechanically switched back and forth between two computers?
That makes sense but if you want people to trust ZCash, you need to come up with a way to involve the community. Perhaps randomly choosing 10 community members who with to participate along with the devs is a good idea. Or choosing 2 representatives from 5 different communities is an option.
If you don’t personally understand the math, (I don’t), then you are trusting the developers anyway, both that they got the math right, and that they didn’t deliberately introduce some hidden flaw. Having some community members who don’t understand both the math and the code, run some code on some computer, has no more value than having a trained monkey run some code on some computer.
The biggest risk I see is that the NSA or some other well funded state level adversary considers it worth their while to target all members of the development team, especially during the Secure Multiparty Computation.
1 Like
Getting back to the air gap idea, it should be possible to make air gapped nodes in some kind of secure enclosure, inside a concrete basin, with a method to detect any breach of the enclosure and a self destruct mechanism upon breach, - maybe some thermite or something. The outer concrete basin should be designed to safely contain the burning thermite while everything within the enclosure gets destroyed.
The air gapped nodes should be setup to do everything from start to finish without any additional physical access, so that once the enclosure is sealed, it cannot be unsealed, and the destruction of the machine is guaranteed.
A video feed of all such enclosed nodes could be broadcast live on web cams during the Secure Multiparty Computation, and after the Computation is finished, the final destruction of the nodes should be an entertaining spectacle for everybody to watch live on the Internet, followed by a world wide celebration.
How does any of the above ensure that cryptographically sound data gets generated?
If we’re being really honest with ourselves, we can’t even be 100% certain that every integrated component of a given computing device is actually trustworthy - nevermind the expanse of software that runs on top of that…
You mean how does air gapping guarantee anything? It doesn’t, but compared to not air gapping, well you could say that not air gapping guarantees that the NSA can own every node in 2 minutes. As far as the components go, yes, probably the NSA has a whole library of zero day vulnerabilities against every sub component of every component of every computer. That’s why air gapping is the only chance of possibily succeeding in securely generating the keys if the developers are targeted by the NSA. Probably everything needs to be contained in sound proof faraday cages too. It would be ideal if we could print all of the computer components ourselves using 3D chip printers, but the technology for that isn’t quite here yet. So we’ll have to trust that although the computer components are all compromised and vulnernerable, they may at least behave well enough to generate the right results in an air gapped machine. Maybe not. But once ZCash is trading publicly, we will at least be able to observe the exchange rate. If somebody counterfeits too much, the currency would lose value. So long as the currency holds value, it means that whoever knows how to counterfiet is limiting how much counterfeiting they do.
1 Like
Here is another idea: Make a live boot disc that any computer can be booted from, and whichever computer is booted from this boot disk will automatically do the whole computation, from start to finish, without human intervention. When finished with the computation, the computer will write the SNARK parameters to a DVD or Blu-ray drive, and eject the tray.
The developers can audit the boot disc and all agree that it looks good. Then they all go shopping, and randomly buy a computer from a physical store. Then they take this computer, put it in a faraday cage, pack thermite all around it, boot it from their agreed upon boot disc, and let it run until the tray with the finished SNARK parameters ejects. Then, they shut off power to the computer before breaching the faraday cage.
Somebody reaches in to take the disk with the parameters, without otherwise touching the computer in any way, and then the thermite around the computer is ignited. This would of course have to be conducted in a location where it would be safe to burn thermite. Perhaps camping in the desert would be a good location.
With the developers all physically together, all watching each other, nobody could cheat. Since the computer would have been bought randomly from a random store, and kept in all of their sight the whole time, nobody would have a chance to sneak a cheating device into it.
If it is done as a camping trip to the desert, it could be done where there is a large metropolitan area with desert camping not far away. The large metropolitan area would provide a large selection of stores from which to randomly select. The more stores to choose from, the less chance that somebody could rig computers in all the stores ahead of time. If it were done in Southern California, the stores could be chosen from all of Los Angeles and Orange County, and then the computer taken to one of the deserts in Southern California. The computer should be selected from boxes visible on store shelves, and not brought by a store employee from the back room. Bringing a computer from the back would provide an opportunity for somebody to whisper in an employee’s ear and hand him a wad of cash. So the list of computer stores to choose from should include only stores which keep computers to buy visible on shelves. The store should be chosen using a random number protocol which takes input from all participants.
Once the computer is selected, it should be carried out to a pickup truck with an open bed, and secured in the back of the truck. Then all participants can drive in a caravan to the desert, following the pickup with the computer in the back. This way, even though people are driving in separate vehicles, the computer stays in everyone’s sight the whole time.
This type of process allows a larger number of participants, as many as can reasonably come in the store to watch. An even large number could follow the caravan to the desert. The process could be video taped, or even broadcast live.
When the disc is ejected from the sacrificial computer, the disc should stay in everybody’s sight, with everybody watching closely for any slight of hand, and immediately be put into a disc duplicator, and copies made for everybody.
The disc duplicator could of course be compromised too. So there would also need to be security protocol around the selection and use of the disc duplicator.
If you don’t like the idea of doing it in the desert, another idea would be for the developers to meet for a vacation someplace where they could rent some private cabins in close proximity, and setup an Intranet between the cabins, which does not connect to the Internet. Then each one could run a multiparty computation node in their own cabin, using whatever computer they choose, and be responsible for its destruction in a way of their own choosing when the computation is complete. The most important thing is to do the computation in a way that is not connected to the Internet, if possible.
However, if one of the developers was dishonest, they might try to hack the other nodes over the private Intranet. Ideally, the nodes should also be air gapped from each other, if there is any way to sufficiently reduce latency over an air gap.
The blu-ray drive method of air gapping could be made faster by having multiple blu-ray drives operating in parallel, multiplexed.
Wikipedia says there are write once FPGAs which cannot be modified once written. “Customers wanting a higher guarantee of tamper resistance can use write-once, Antifuse FPGAs from vendors such as Microsemi.”
Could you make a FPGA which generates its shard internally, and does all calculaions with the shard internally, never exposing it to the rest of the computer? Then only the FPGA would need to be destroyed.
If the math and code are opensource, then you don’t need to trust the devs 100%. You only need to trust that if there is a flaw or backdoor in the math that someone (if not multiple people) with a level of intelligence and education to understand the math would call the devs out and make a fuss.
You have a valid point about open source code. Supposing the devs choose some outsiders to participate in the computation, how would you know they hadn’t specifically selected outsiders that will cooperate with them in a dishonest scheme? What method of selecting outsiders could they use that you would trust?