IdeaWell

Project ideas from Hacker News discussions.

Source code of the Estonian online voting system

Original Article

Hacker News Discussion

📝 Discussion Summary (Click to expand)

Three prevalent themes in the discussion

  1. Verifiability and trust in electronic vs. paper voting
    Participants repeatedly questioned how a voter can be sure their electronic vote was counted correctly, contrasting it with the observable chain of custody in paper elections.
  2. “I know the answer is 'you don't', but suppose I vote vote electronically for candidate A. In the end, the candidate loses with 764 votes. How do I convince myself that my vote was counted in the 764 votes, and that it was not a randomly chosen number (with a RNG skewed around 'plausible' scores) ?” – phtrivier

  3. “You convince yourself the way you do with any elections: you trust the people/system that counts the votes. … the requirements of a secret ballot … and the fully verifiability you are asking for are mutually exclusive. You can have either one but not both at the same time.” – juhanima

  4. Cryptographic solutions and their limits
    Many commenters proposed cryptographic techniques (hashes, signatures, private keys, blockchain) to provide verifiability, while others stressed that crypto alone cannot replace physical oversight and public trust.

  5. “You solve all of these with cryptography. Your ID card contains a private key, you use that key to sign a transaction. It doesn't matter that machine you are running on is compromised as these details can be verified at a later date.” – himata4113

  6. “I've spent a lot of time thinking about this problem, and my conclusion is that cryptography alone is not the solution… 1. The public needs to believe it, and hypertechnical solutions are a hard sell. 2. Any blockchain approach needs to preserve the secrecy of the ballot… 3. You still need to have the cryptographic rubber meet the physical road somewhere … otherwise the results can be entirely fictitious.” – cryptonector

  7. Status and purpose of the public repository
    The thread frequently clarified that the repository is not actively developed but is kept up‑to‑date to reflect the exact code used in Estonian elections, aiming for public scrutiny.

  8. “The intention behind this repository is to make source code of the Estonian online voting system available for public review. The repository is not used for active development, but will be kept up to date, so the code that can be found here is the code that is used for election.” – jeff_vader
  9. “The repository is not used for active development, but will be kept up to date, so the code that can be found here is the code that is used for election. As the voting system used for legally binding elections must strictly follow the legislation, the actual development … is supervised by State Electoral Office of Estonia.” – piiritaja

🚀 Project Ideas

Generating project ideas…

VeriVote: End-to-End Verifiable Voting with ZK Proofs

Summary

  • Provides voters with a cryptographic receipt that proves their encrypted ballot was included in the final tally without revealing how they voted.
  • Uses homomorphic encryption and succinct non‑interactive arguments of knowledge (SNARKs) to enable public verification while preserving ballot secrecy.
  • Core value proposition: lets any voter convince themselves (and others) that their vote was counted, addressing the verifiability gap highlighted in the HN thread.

Details

Key Value
Target Audience Election authorities, civic‑tech groups, individual voters seeking verifiable assurance
Core Feature Voter receives an encrypted ballot receipt and a zero‑knowledge proof; anyone can check the proof against a public bulletin board to confirm inclusion
Tech Stack Go/Rust backend, Circom + SnarkJS for ZK‑SNARKs, PostgreSQL for storing commitments, React/TypeScript frontend
Difficulty Medium‑High
Monetization Revenue‑ready: SaaS subscription (per election or per 10 k voters) + optional premium support

Notes

  • HN commenters asked “How do I convince myself that my vote was counted?” and noted that cryptography alone is a hard sell; VeriVote gives a tangible, publicly checkable receipt that non‑technical observers can verify with a simple web tool.
  • Enables discussion on balancing secrecy and verifiability, and offers practical utility for pilots in municipalities looking to adopt end‑to‑end verifiable elections.

AuditChain: Transparent Election Log Verification Service

Summary

  • Collects cast‑vote records (CVRs) into an immutable, append‑only log secured by a hash‑chain and periodic blockchain anchors.
  • Provides tools for risk‑limiting audits: auditors can request random samples, compare them to paper ballots, and verify that the digital tally matches the log.
  • Core value proposition: gives election officials and independent observers a tamper‑evident trail and easy audit workflow, solving the trust‑in‑machines problem raised in the discussion.

Details

Key Value
Target Audience State/local election officials, independent audit firms, NGOs, political parties
Core Feature Immutable CVR log with API for sampling, verification dashboards, and automatic blockchain anchoring (e.g., to Ethereum or a permissioned Tendermint chain)
Tech Stack Go (or Rust) for log service, IPFS/Filecoin for off‑chain storage, Tendermint/Cosmos SDK for consensus, Grafana/Prometheus for monitoring, React admin UI
Difficulty Medium
Monetization Revenue‑ready: per‑election licensing fee or usage‑based pricing (e.g., $0.01 per CVR stored)

Notes

  • Commenters suggested publishing a “blockchain head every 50 ballots” to allow public verification; AuditChain automates this with configurable anchoring intervals and provides audit‑ready exports.
  • Addresses the need for a “manual, statistical random sampling method” by offering a one‑click sample generator and verifiable proof of inclusion, facilitating practical post‑election audits.

DenyVote: Coercion‑Resistant Voting with Deniable Receipts

Summary

  • Allows a voter who is forced to show their vote to produce a deniable receipt that can be opened to reveal either the true vote or a fake vote of the coercer’s choosing.
  • Uses deniable encryption (e.g., plausible deniability via chameleon hashes) so the receipt is cryptographically valid under either opening, protecting the voter’s privacy under duress.
  • Core value proposition: mitigates coercion and vote‑buying threats mentioned in the thread, giving voters a practical defense without requiring changes to the underlying voting protocol.

Details

Key Value
Target Audience Voters in high‑risk environments (activists, journalists, citizens under authoritarian regimes), election‑integrity NGOs
Core Feature Voter obtains a deniable credential; under coercion they can present a fabricated opening that matches the coerced choice, while the real vote remains secret and verifiable only by the voter
Tech Stack libsodium (for deniable encryption), Rust core, React Native mobile app for credential management, bulletin board service (same as VeriVote/AuditChain) for publishing commitments
Difficulty High
Monetization Hobby (open‑source project; possible future donations or grants)

Notes

  • HN discussion highlighted concerns: “spouse, rouge employers, mafia, corrupt politicians… you can now 'sell' your vote.” DenyVote directly answers this by providing a coercion‑resistant receipt mechanism.
  • Enables practical utility for pilot programs in areas where vote buying is a known problem, and invites discussion on the trade‑offs between usability and strong deniability.

Read Later