Impact of revealing spent & unspent voice credits on collusion resistance

From Wei in HackMD

It’s still an open question as to exactly how to describe the impact of making the number of voice credits spent per vote option public as it depends on how many voters there are and the distribution of votes. But here are some scenarios where a briber/attacker could learn things that they otherwise would not. The question is: how much damage could they do with this information?

Vulnerability 1: Eve can tell if not enough voice credits were allocated

From Tommy in the TG chat:

I think the bigger and more likely vulnerability is the fact that a briber can tell that the voice credit amount received is less than what they bribed for, or fits into any vote scenario, especially if no one else votes for it because it’s a scam - they’ll likely receive nothing at the end of the round which will be an immediate red flag.


Eve (CEO of ECorp) bribes Alice to spend 100 voice credits towards ECorp, which ends up being one of the few (albeit invalidated) votes towards the vote option due to the voters’ lack of faith in ECorp. Not only is it easy for Eve to determine voice credit distribution based on Vulnerability 2, it’s very likely that ECorp is going to receive less voice credits than initially bribed for ; even if ECorp receives over 100 voice credits from a small handful of sources - there’s a good chance it wouldn’t create the necessary vote scenario to provide plausible deniability (see Vulnerability 2).

Vulnerability 2: Eve can make better guesses about the number of voters per vote option

Let’s say that Eve is a briber. There is a MACI system which shows how many voice credits were spent per vote option after the tallying process is overss is overss is overss is overss is over. In this system, Eve can learn more information about how users had voted.

The more voters to each vote option receives, the more unlikely that this attack will succeed. But in the real world, there may be a long tail of vote options which receive very few voters.

For instance:

  1. Option A receives 5 votes and 25 voice credits were spent on it.

Eve now knows that exactly 1 person voted for Option A (rather than 5 people each spending 1 voice credit, or 2 people spending 4 + 9 voice credits, etc).

In other words, if we know that voiceCredits(option) == sqrt(votes(option)) then we know that numVoters(option) == 1

  1. Option A receives 8 votes and 34 voice credits were spent on it.

Eve knows that sqrt(34) is not a whole number. So it must be the sum of more than 1 square root. She makes the following guesses:

34 = 1 + 33
34 = 4 + 30
34 = 9 + 25 and sqrt(9) + sqrt(25) = 8. jackpot!
34 = 16 + 18

Eve thinks: maybe there are more than 2 voters.

34 = 1 + 1 + 32
34 = 1 + 4 + 29
34 = 1 + 9 + 24
34 = 1 + 16 + 17
34 = 9 + 9 + 16 but sqrt(9) + sqrt(9) + sqrt(16) = 10 so (9, 9, 16) is incorrect

and so on…

Maybe there are possible combinations in addition to 9 + 25. But Eve has at least ruled out a bunch of possibilities.

To automate the above, Eve can use WolframAlpha as such and find results which sum to 8.[34%2C+34%2C+2]


I dubious that this additional information is meaningful in any situations that would meaningfully impact the matching pool.

I do acknowledge that you may be able to infer some specifics for the long-tail recipients, but I don’t think that is where collusion does its damage. The quadratic match at the tip or the tail is near 0.

For any large scale bribery attacks (more than a handful of people), there would be to many potential combinations to meaningfully infer anything from the total voice credits spent.

1 Like

That said, another option that we haven’t explored yet is to lock in the matching funds at the start of the round.

In this case, MACI could have all the information to calculate the sum of the direct contributions and the match, for each project.

Obviously this would require some modifications to the circuits.