Possible attacks and actor model

We focus mainly on the voting, but the same model can be used to discuss other simmilar problems

Actors and motivations

We are concerned with 3 different types of actors: Center, Briber and User.

Devs

We want to hit both goals make bribers overpay and make users unable to reliably sell their votes in case they want to.

Center

The Center is tasked with the organisation of the voting. We assume that Center is usually thaught of as an MPC and at least 1 part is not bribed.

The main purpose of the Center is to provide infrastructure to conduct voting. As an outcome the Center will publish a voting result and a proof of correctness of its computations.

Bribers

They have their own opinion on the voting subject and benefit greatly from some of it's outcomes. They attempt to bribe users.

Users

Have an ability (provided by some sort of prior registration) to vote. They value their vote, but also they value money.

Core assuptions

We assume that each User and the Center have a secure Setup phase prior to any other communication. This setup phase is used to register a user in the systemю.For exaple add their public key to a commonly known registry. We assume that bribers can not interract in this setup phase.

Formal setting:

Voting

$k$ candidates, the winner(s) is(are) chosen by some aggregation on user votes, e.g majority.

Center

MPC with $1$ of $n$ trust.

Briber

Estimates a user vote for their candidate to cost $b_v$ and a corrupted user vote to cost $b_c$.

User

Estimates his vote cost as $u_v$.

Evolution

1) Setup phase:

Each User and Center are communicating by the Setup-Phase-protocol uninterrupted and uninfluenced by the briber.

This does not imply that user is not planning to take actions to make his vote "sellable"

2) Bribe attempt:

Briber and User negothiate a Bribing-protocol. After the voting ends user will provide a ZK-proof of him following this protocol correctly to the briber.

3) Voting:

Voting-protocol transactions are submitted.

* Steps 2 and 3 are happening at the same time, but most of the time the analisis will reduce parallel evoution to sequentual.

Possible attacks

Here we discuss some of the attacks that come to mind. Both from user and from briber's end.

Credible Briber aka FTX argument (This one is more social)

Suppose the voting is repetative (more like if the briber is repetative) and there is some cryptoeconomic stake involved. If the briber has not stolen any stakes previously it is plausible that they will not steal the stake next time

Structured user random

If user wants to cell their vote and if they are asked to generate some random number, they can take a structured number (e.g. 0x0123456789ABCDEF0...) and pretend that that is their random.

This attack can prove a statement "This number was generated and used when the protocol required a random number from me"

Oblivious signature

Briber can propose a 2-party MPC protocol to user, in which:

• briber-party knows the transaction
• user-party knows the private key
• signed transaction is revealed only to briber-party
• ZK-proof of execution correctnes will be revealed to briber-party

This protocol will use the same arythmetic scheme that is used in regular signature over some 2-party MPC implementation and a collaborative ZK-SNARK for the proof.

This protocol ensures both: privacy of the private key and privacy of transaction.