*From Wei in HackMD https://hackmd.io/NKohKwKgQyeyeQLpLepKig?view#Impact-of-revealing-spent-amp-unspent-voice-credits-on-collusion-resistance*

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.

Scenario:

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:

- 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`

- 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.

https://www.wolframalpha.com/input/?i=PowersRepresentations[34%2C+34%2C+2]