Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Smart Contract to guarantee submissions #43

Open
arianabuilds opened this issue Dec 14, 2021 · 4 comments
Open

Smart Contract to guarantee submissions #43

arianabuilds opened this issue Dec 14, 2021 · 4 comments
Labels
security Possible risk of attacks verification Verifying votes cast & counted correctly

Comments

@arianabuilds
Copy link
Member

No description provided.

@dsernst
Copy link
Member

dsernst commented Dec 14, 2021

Notes on how to integrate this with a smart contract:

SIV (Secure Internet Voting) Smart Contract

Goals:

Enforces that once SIV has issued a signed vote submission receipt via email,
the voter can be confident that their vote will be in the final tally.

If it's not, the voter can automatically claim the pot of money in the smart contract.

Transaction Details:

  1. At the end of the election, SIV posts
    a. Merkle Tree of all the votes. Size estimate: 256 bits for each hash * num of votes * 2 (for Merkle Tree height). So for an election with 100k voters, approx 51 megabits.
    b. election_id
    c. sends some money to the contract as the bounty (in a USD stablecoin like USDC). Initially, maybe $500, over time we would increase up to $50k, $1m, $50m.

  2. Anyone can post a "bounty claim transaction"
    a) signed vote confirmation receipt

    In response to Transaction 2, the smart contract checks =>
    1. Does this confirmation receipt have a valid signature?
    2. Does the election_id match 1b ?
    3. Is the hash of the vote in the confirmation receipt truly missing from the Merkle tree posted in 1a?

If all 3 checks pass, send the bounty from 1c to the address that posted transaction 2.

To prevent front-running, separate transaction #2 into 2 separate blocks.
2a is they post the hash of the signed receipt
2b is they post the full signed receipt.

If it's been x days (e.g. 45) since Transaction 1 was posted without any successful claims,
the money gets returned back to address from Transaction 1.

@dsernst
Copy link
Member

dsernst commented Dec 14, 2021

As a starting place, we can just post the Merkle tree at the end of the election, before building out the smart contract aspect of this.

@dsernst dsernst added the P: 5 label Dec 14, 2021
@dsernst dsernst changed the title Merklize Encrypted Vote Submissions Smart Contract to guarantee submissions Dec 15, 2021
@dsernst dsernst added security Possible risk of attacks verification Verifying votes cast & counted correctly labels Mar 12, 2022
@arianabuilds
Copy link
Member Author

arianabuilds commented Mar 12, 2022

Start with

  • better signed submission receipts
    • rn Mailgun has the private key
    • optimize what is signed: sign just a very short message that has hash of a submission & the election id

@dsernst
Copy link
Member

dsernst commented Jul 31, 2024

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
security Possible risk of attacks verification Verifying votes cast & counted correctly
Projects
None yet
Development

No branches or pull requests

2 participants