Honeypot Roulette: Detection Grid for Counterfeiting Attempts


#1

Secure Sampling of Public Parameters for Succinct Zero Knowledge Proofs is over my head, so I'm working from the simplified explanation from the zcash blog, with apologies for my ignorance of the true nature of the technology. In short, this suggestion is designed to work alongside secure multiparty computation (SMC) as a backstop and attack detection grid. I gather the generation of parameters is already hard, and this will make it harder, but if these honeypots are otherwise viable they could conceivably provide as much protection against counterfeiting after a successful shard collection attack as SMC provides in preventing the collection and that could be worth a great deal of effort.

I propose that while generating the SNARK public parameters, you generate as many more very similar parameters as possible, which should also be baked into zcash. These other sets of parameters would be tripwires, or honeypots, and the idea would be to create so many honeypots that even if attackers managed to collect every shard generated in the SMC, the first time they attempted to counterfeit they would almost certainly sound the baked in alarm that would stop all transactions across zcash and allow the extension or regeneration of fresh public parameters, forcing them to restart the difficult task of preserving/stealing every single shard and then correctly guessing the right combination on the first attempt at counterfeiting.

I have three alternate suggestions for generating these Honeypot Parameters -- the first two of which create Honeypot Minefield Parameters. The first suggestion is to have every party generate shards for more than one set of parameters, most of which would not go into the SNARK public parameters, but rather into similar looking Honeypot Parameters. The second suggestion that might be more efficient to generate if it is possible to do is to construct the public parameters in such a way that every possible reconstitution of the exact same shards creates a different parameter, all baked in, but only one as the SNARK public parameters. Every other reconstitution produces a key to a Honeypot which will sound the alarm when used. I suspect that even if there is insufficient transparency in the SMC for an attacker to figure out which shards to use in what way, another problem with the Honeypot Minefield is harder to get around. An attacker could create a small offline zcash using your code, attack it with every combination of shards until finding the right one, and then use the right one on the real zcash never even risking triggering an alarm.

Which brings us to the third alternative which could build on either of the previous two. Instead of creating a fixed set of Honeypot Minefield Parameters, create a large set of many parameters as possible that are baked in without a fixed identity as either the active public parameters or the alarm sounding, blockchain-freezing Honeypot Parameters, I call all these Honeypot Roulette Parameters because you'd also bake in a mechanism like a roulette wheel to choose which are the active SNARK public parameters. The idea would be that as transactions take place, zcash would frequently and randomly reassign which parameters from the bundle that have all been baked in would be the active secure parameters at that moment while every other baked in parameter from the SMC would act as alarm-based honeypot parameters until the 'wheel' spins again (perhaps spinning again with every entry on the blockchain). Ideally zcash would tolerate receiving a full bundle of all available public keys without regard to which was the active public key -- as long as the active key was in the bundle, no problem. But the network would care greatly in what order private keys were used. If any private key were used that was part of one of the many honeypot parameters instead of the one active SNARK parameters, the alarm would alert the network, the blockchain would freeze until parameters had been regenerated or extended.

This third alternative, in my mind, likely (how likely depending how how many honeypot parameters exist) defeats an attacker who would evade a honeypot minefield by preattacking a small offline fork of zcash. But I'm also sure, given my ignorance of how all this technology really operates, it and perhaps any possible implementation of the scheme may fail for reasons beyond my knowledge. I'm posting this anyway in hopes that at worst, I might learn more from anyone willing to discuss why this doesn't work, and perhaps to possibly contribute some useful idea. I'd be grateful to anyone willing to expound on the topic. Thanks and happy sunday!


#2

Thanks for your suggestion. As far as I understand it, each node would require the verifying key corresponding to every proving key that is used on the blockchain. Not only is having multiple sets of parameters probably not feasible due to their size, an attacker would only need to compromise one of those sets in order to forge currency.