{"id":"f4b90dda-b218-4db0-8f1b-b177ac14e6fd","arxiv_id":"2507.09453","paper_version":1,"verdict":"REJECT","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"high","formal_verification":"none","parameter_count":0,"one_line_summary":"A smartphone voting protocol using EUDI credentials, BBS signatures, homomorphic encryption, and a TrustChain ledger is proposed, but its one-person-one-vote guarantee is undermined by a replayable registration proof.","lead":"This paper proposes SmartphoneDemocracy, a voting protocol that lets citizens register and vote from a smartphone using EUDI digital identity, zero-knowledge proofs, and a peer-to-peer blockchain. A smart generalist might read it to see whether decentralized, verifiable mobile voting is actually close to feasible, and where the trust assumptions still sit.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Registration proof is not bound to the on-chain commitment, so one BBS credential can register unlimited commitments and cast multiple votes, breaking one-person-one-vote.","rationale":"The reader's weakest_assumption identifies a genuine, load-bearing flaw: the registration proof is replayable and not bound to the commitment cm, so the on-chain uniqueness mechanism cannot enforce one-person-one-vote. My independent reading of Sections V-C and VI-A confirms this. The paper's own Assumption A2 states that each eligible voter can register exactly once, but the protocol does not cryptographically enforce it; the Verifier's off-chain nullifier only prevents issuance of multiple credentials, not multiple on-chain registrations from one credential. This is not a matter of disagreeing with the field's consensus, nor is it a performance or implementation gap: it is an internal inconsistency between the claimed security property and the specified protocol steps. The performance microbenchmarks and prototype, while useful, do not address this correctness issue. A concrete fix exists (bind cm into the BBS proof or add an on-chain registration nullifier), but the paper as written does not include it, so the central claim that the system provides Sybil resistance without a central coordinator does not hold. The verdict of REJECT is therefore appropriate, and no adjustment is needed.","tokens_in":21360,"tokens_out":3638,"duration_ms":42608,"concrete_test":"Implement the Tx_reg validation logic exactly as described in Section V-C step 7: verify proof_reg against the Verifier's BBS public key and the public election_id, and on success add cm to LCommit. Generate one valid BBS credential, derive one proof_reg, then broadcast two registration transactions Tx_reg1 = (cm1, proof_reg) and Tx_reg2 = (cm2, proof_reg) with cm1 != cm2. If both are accepted, the protocol as written permits multiple registrations per credential. Then test a minimal fix: make proof_reg a BBS proof over a presentation header that includes cm (e.g., prove knowledge of the signature while also proving cm = Commit(secret_id)) and repeat; the second registration should be rejected. This distinguishes a documentation gap from a protocol flaw.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central Sybil-resistance claim in Section VI-A is that the protocol 'cryptographically guarantees that each valid registration can result in exactly one valid vote.' This relies on the registration transaction Tx_reg = (cm, proof_reg). However, proof_reg is a BBS selective-disclosure proof that reveals only election_id and proves possession of a Verifier-issued credential; it contains no reference to cm, and the validation in Section V-C step 7 checks only the proof against the Verifier's public key and the public election_id. Nothing binds the hidden secret_id inside proof_reg to the opened value of cm. A malicious voter who obtains one legitimate BBS credential can therefore replay the same proof_reg with any number of freshly chosen cm values (e.g., cm_i = Commit(secret_id_i) for arbitrary secret_id_i). Each such Tx_reg will pass peer validation and add a new commitment to LCommit. For each accepted cm_i, the voter can then produce a valid voting proof πvote with witness (secret_id_i, v), passing the Merkle-membership check against LCommit and the nullifier check with nfvote_i = H(secret_id_i || idE). Since all nfvote_i are distinct, the on-chain nullifier check in Section V-D step 6 cannot prevent multiple votes. The Verifier's off-chain registry (Section V-C step 2) limits each PID to one BBS credential, but it does not limit how many on-chain commitments that single credential can authorize. The claimed guarantee therefore fails exactly as specified; the protocol needs a binding commitment inside proof_reg, e.g., a presentation message that includes cm, or an on-chain registration nullifier derived from the same secret_id that is checked for uniqueness.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"SmartphoneDemocracy proposes a decentralized e-voting protocol on the TrustChain P2P ledger, combining EUDI Wallet-issued verifiable credentials, BBS selective-disclosure proofs for registration, Groth16 zk-SNARKs for vote validity, threshold Paillier homomorphic encryption for tallying, and public nullifiers for double-voting prevention. The paper provides a four-phase protocol (setup, registration, voting, tallying), a security analysis against a stated adversary, a qualitative risk table, and performance estimates backed by an Android prototype and microbenchmarks. The central claims are that the protocol provides voter privacy, Sybil resistance, universal verifiability, and practical feasibility for large-scale elections, all without a central coordinator.","tokens_in":21650,"tokens_out":5659,"duration_ms":61213,"significance":"If the protocol were sound, the synthesis of EUDI Wallet identity with BBS selective disclosure and Groth16 proofs on a P2P ledger would be a timely contribution to decentralized e-voting, and the estimated transaction sizes (~1.3 KB registration, ~1.1 KB vote) and sub-second proof generation would be attractive for smartphone deployments. The paper is also transparent about its limitations, explicitly acknowledging the trusted Verifier and the incomplete prototype. However, the central one-person-one-vote guarantee is invalidated by a missing binding between the registration proof and the commitment, the security analysis is assertional rather than formal, and the performance evaluation is component-level only. These issues leave the main contributions unsubstantiated as written.","major_comments":[{"comment":"The registration transaction Tx_reg = (cm, proof_reg) does not bind the BBS selective-disclosure proof to the commitment cm. Section V-C step 7 validates proof_reg only against the Verifier's public key and the public election_id; it does not check that cm commits to the hidden secret_id in the signed credential. A voter with a single legitimate BBS credential can therefore replay the same proof_reg with arbitrarily many fresh commitments cm_i, each of which is accepted into LCommit. For each cm_i, the voter can choose a fresh secret_id_i and produce a valid voting proof πvote and a distinct nullifier nfvote_i = H(secret_id_i || idE), so the on-chain nullifier check in Section V-D step 6 does not prevent multiple votes. The off-chain Verifier registry (Section V-C step 2) limits the number of issued BBS credentials per PID, but it does not limit how many commitments one credential can authorize. Consequently, the claim in Section VI-A that the protocol 'cryptographically guarantees' exactly one vote per valid registration is false, and assumption A2 is violated.","section":"V-C, VI-A"},{"comment":"The security analysis is informal: properties such as ballot secrecy (Section VI-C), anonymity and unlinkability (Section VI-B), and universal verifiability (Section VI-E) are argued narratively without formal definitions, adversarial games, or proofs. The risk table in Table V lists 'formal analysis of the ZKP vote circuit' as a mitigation for rows 2c and 4d, but no such formal analysis appears anywhere in the paper. Because the paper advertises 'a security analysis against a defined threat model' as a contribution, the absence of a formal framework leaves the security claims unestablished and the threat model incomplete.","section":"VI, Table V"},{"comment":"The performance evaluation consists of microbenchmarks of individual cryptographic operations on a Raspberry Pi and an emulator. The paper itself admits in Section V-G that the homomorphic tallying and ZKP verification were not fully integrated and the TrustChain layer was only partially tested. The statement in Section VII-A that the protocol is 'computationally and network-wise feasible for deployment in real-world, large-scale elections' is therefore an extrapolation from component-level timings and does not account for end-to-end behavior, concurrent load, network propagation, or storage constraints. The evaluation supports only component-level feasibility, not the system-level claim.","section":"V-G, VII-A, VII-B"},{"comment":"The abstract claims the system operates 'without a central coordinator,' but the registration phase relies on a single trusted Verifier that maintains a private nullifier registry (Section V-C step 2). This Verifier is a central server and its malicious compromise is not included in the threat model of Section IV-D. The authors acknowledge this centralization point in Section IX-A, but the claim in the abstract is still overstated and should be qualified whenever 'decentralized' is used for the overall system.","section":"I, IV-A(b), IV-D, IX-A"}],"minor_comments":[{"comment":"The text repeatedly renders 'Voters' and 'Voter App' with an extra space (e.g., 'V oters:', 'V oter App'). This typographical artifact should be corrected throughout the manuscript.","section":"Throughout"},{"comment":"The relation proven by πvote is described only informally. The public inputs and the witness (including the Merkle path, the commitment randomness, and the exact encryption relation) should be specified to make the protocol reproducible and to enable a formal soundness analysis.","section":"V-D step 4"},{"comment":"The Config row lists a size per transaction of '∼5 − 10KB' but a total of '∼10 KB (negligible)', which is inconsistent. Clarify whether the configuration is one transaction or several, and align the per-transaction and total sizes.","section":"Table III"},{"comment":"Appendix A is titled 'Security Analysis' but contains only a qualitative risk table. Since the paper does not provide a formal security analysis, the appendix should be renamed 'Risk Assessment' or the actual formal analysis should be supplied.","section":"Appendix A"},{"comment":"The OpenID4VP protocol is mentioned without expanding the acronym or providing a citation. Add the full name and a reference to the relevant specification.","section":"V-C step 1"},{"comment":"The bibliography entry [45] lists 'D. L. A. contributors' as the author. This should be replaced with the actual authoring organization (e.g., Dock Network) or a proper institutional citation.","section":"References [45]"}],"recommendation":"reject","confidential_remarks":"The registration replay vulnerability is decisive and invalidates the paper's central Sybil-resistance claim. While a binding mechanism (e.g., including cm in the signed attributes or in the BBS proof) could in principle repair the protocol, doing so would require reworking the registration phase and re-analyzing the security properties, which is beyond a standard revision. The informal security analysis and incomplete implementation further weaken the contribution. I would not invite a revision of the current manuscript."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague,\n\nQuick take: this is a readable protocol proposal for smartphone e-voting using EUDI, BBS, threshold Paillier, Groth16, and TrustChain. The integration is new, and the authors are honest about what is prototype and what is still design. But the security core is argued informally, and the replay concern in the stress-test note does not hold up on careful reading.\n\nThe paper does several things well. The phased design is clear; the choice of primitives is sensible (BBS for registration, Groth16 for vote proofs, Paillier with threshold decryption for tallying); and the authors correctly identify the central Verifier as a limitation. They ship code and run micro-benchmarks on a Raspberry Pi, which is real evidence that the crypto can run on modest hardware. The related-work comparison with Provotum, ElectionBlock, Alethea, SecureBallot, and zkVoting is useful and fair.\n\nThe stress-test note claims that proof_reg is replayable: one BBS credential lets a voter register unlimited commitments and cast unlimited votes. That is not right. proof_reg is a selective-disclosure proof over the hidden secret_id attribute; the voter cannot swap in a different secret_id without a new signature from the Verifier. A deterministic commitment yields one cm per secret_id; a randomized commitment yields multiple cm for the same secret_id, but then nfvote = H(secret_id||idE) is identical, and the nullifier check rejects the second vote. So one-person-one-vote does not collapse in the way the note suggests.\n\nThe real weaknesses are elsewhere. First, Tx_reg = (cm, proof_reg) does not bind cm to proof_reg, so the on-chain state cannot tell whether two commitments came from the same credential. That is not a direct vote-duplication attack, but it is a missing link in the chain of implication and should be fixed, e.g., by including cm in the BBS presentation message or by adding an on-chain registration nullifier derived from the same secret_id. Second, the paper says it 'formally analyzed' the security, but what is presented is a threat-model table with qualitative probabilities, not a proof. Third, the performance evaluation is component-level; the paper concedes that the homomorphic tally and ZKP verification are still design proposals, not integrated into the prototype. These are fixable gaps, but they mean the main claims are under-supported as written.\n\nFor whom? People working on practical e-voting systems, especially those wanting to leverage the EUDI Wallet. A serious referee could give focused guidance on binding, formal proofs, and end-to-end integration. I would not cite it in its current form, but I would bring it to a reading group to discuss the design and the gap between the cryptographic pieces and the claimed guarantees.\n\nRecommendation: send to peer review. It is a sincere design effort with real benchmarks, not a desk reject, but it needs major revisions before acceptance.","headline":"A clear, earnest e-voting protocol proposal that assembles EUDI, BBS, Paillier, Groth16, and TrustChain into a smartphone-centric design; the headline replay attack doesn't survive a close reading, but the paper's informal security argument and unbound registration proof need real work before the central claims can be trusted.","tokens_in":22190,"tokens_out":5140,"would_cite":false,"duration_ms":61801,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"SmartphoneDemocracy claims that anonymous, verifiable voting can happen on ordinary smartphones using EUDI credentials, zero-knowledge proofs, and a peer-to-peer ledger.","keywords":["e-voting","blockchain","zero-knowledge proofs","privacy","EUDI Wallet","homomorphic encryption","Sybil resistance","universal verifiability"],"falsifier":"After one successful off-chain registration, submit two registration transactions that reuse the same BBS selective-disclosure proof but post different commitments; if honest peers accept both and both can be followed by accepted votes, the on-chain one-vote-per-registration claim is falsified, because the transaction format binds neither the commitment to the proof nor the proof to a single use.","tokens_in":21156,"feed_emoji":"🗳️","tokens_out":17647,"duration_ms":183371,"temperature":0.7,"pith_summary":"SmartphoneDemocracy tries to show that a national-scale election can be run without a central authority, using only the smartphones of the participants. It combines the EUDI Wallet as a Sybil-resistant identity source, zero-knowledge proofs to break the link between identity and ballot, and a peer-to-peer blockchain as an open bulletin board. The paper's central claim is that this combination gives anonymous registration, secret ballots, one vote per eligible citizen, and a tally anyone can audit, at a computational cost a phone can bear. If that is right, elections could be held on infrastructure the voters themselves operate, with legitimacy derived from public verification rather than from trust in an election commission.","feed_headline":"One protocol lets smartphones cast secret, auditable ballots","feed_subtitle":"It pairs EUDI identity with zero-knowledge proofs to keep ballots secret yet publicly checkable.","key_machinery":"The load-bearing mechanism is the pair of anonymous identifiers derived from one hidden secret: the commitment $cm = \\mathrm{Commit}(secret\\_id)$, which appears in the registration transaction, and the vote nullifier $nf_{\\mathrm{vote}} = H(secret\\_id \\parallel id_E)$, which appears in the vote transaction. Registration is mediated by a BBS signature whose selective-disclosure proof lets the voter show they hold a valid credential without revealing the secret; the Groth16 proof in the vote transaction ties the ciphertext to a registered commitment and to a freshly derived nullifier. Peers enforce one vote per registration by maintaining a public spent-nullifier list, and tallying uses a threshold Paillier scheme so that only the sum, never individual ballots, is decrypted.","core_discovery":"The protocol separates identity checking from ballot casting. A voter presents an EUDI eligibility credential to a Verifier, which issues a BBS signature over a fresh hidden secret; the voter then posts a registration transaction containing only a commitment to that secret and a selective-disclosure proof. To vote, the voter posts a homomorphically encrypted choice, a nullifier derived from the same secret, and a Groth16 zero-knowledge proof that links the commitment, nullifier, and ciphertext. Network peers verify the proof and check that the nullifier has not already been spent, which the paper argues cryptographically guarantees one valid vote per valid registration; tallying is a public homomorphic sum followed by threshold decryption with zero-knowledge proofs on every share. The result is a protocol whose bulletin board and tally are fully public while the voter's identity and choice remain separate.","pith_inferences":["Implicit in the design but not developed is the gap between a decentralized bulletin board and decentralized enrollment: until registration uniqueness moves on-chain, the system's trust profile is closer to 'one trusted registrar plus a public ledger' than to 'no trusted parties.'","A natural testable extension is to add a registration nullifier to the registration transaction, so the same credential cannot seed multiple anonymous commitments; without such a binding, the on-chain record cannot by itself enforce one vote per person.","The same composition — a government-issued credential, a blind signature, and a nullifier — could be reused for anonymous one-response-per-person authorization in petitions, surveys, or participatory budgeting.","Because the paper's measurements are micro-benchmarks of individual cryptographic operations, the large-scale feasibility conclusion should be read as an upper-bound check rather than a load-tested deployment result."],"forward_implications":["A voter needs only a smartphone: BBS registration operations run in milliseconds and Groth16 vote-proof generation in under a second on a low-end single-board computer.","Anyone can audit the entire election by re-verifying every registration proof, vote proof, and decryption share on the public ledger and recomputing the homomorphic tally.","A one-million-voter election would put roughly 2.4 GB on the ledger (about 1.3 KB per registration and 1.1 KB per vote), which the paper argues is within reach of consumer peers.","A threshold number of key-share holders must cooperate to decrypt the result, so no single participant can decrypt individual ballots or alter the published sum without leaving detectable proof failures."],"supporting_citations":[{"why":"It supplies the EUDI Wallet regulatory framework from which the protocol draws Sybil-resistant eligibility credentials.","marker":"[41]"},{"why":"It defines the BBS signature scheme used to issue the anonymous voting credential and generate the selective-disclosure registration proof.","marker":"[44]"},{"why":"It provides the generalized Paillier threshold homomorphic encryption scheme, including the encryption-correctness proof and the electronic-voting tallying design.","marker":"[8]"},{"why":"It defines the Groth16 zk-SNARK used for the compact vote proof that links commitment, nullifier, and ciphertext.","marker":"[13]"},{"why":"It supplies TrustChain, the peer-to-peer blockchain used as the election's public bulletin board.","marker":"[23]"},{"why":"It establishes the zero-knowledge proof paradigm underlying the protocol's privacy-preserving validation.","marker":"[1]"},{"why":"It provides the cryptographic implementations used in the benchmarks that support the smartphone-feasibility claim.","marker":"[45]"}],"fun_headline_variants":["Privacy-preserving mobile voting with zero-knowledge proofs","Phone voting that separates your identity from your ballot","E-voting app lets you vote anonymously but verifiably","Decentralized bulletin board keeps voting transparent and private","ZK proofs and EUDI wallet power privacy-first mobile voting"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The one-person-one-vote guarantee rests on the assumption that each registration credential is used exactly once and that the anonymous identifier posted to the ledger is cryptographically tied to that credential; the public ledger has no independent way to enforce either condition.","fun_headline_variants_meta":{"raw":{"variants":["Privacy-preserving mobile voting with zero-knowledge proofs","Phone voting that separates your identity from your ballot","E-voting app lets you vote anonymously but verifiably","Decentralized bulletin board keeps voting transparent and private","ZK proofs and EUDI wallet power privacy-first mobile voting"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000905,"raw_usage":{"total_tokens":3881,"prompt_tokens":923,"completion_tokens":2958,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":539,"completion_tokens_details":{"reasoning_tokens":2880}},"tokens_in":539,"tokens_out":2958,"duration_ms":25648,"temperature":1.0,"reasoning_tokens":2880,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-06T17:56:07.663391+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"After one successful off-chain registration, submit two registration transactions that reuse the same BBS selective-disclosure proof but post different commitments; if honest peers accept both and both can be followed by accepted votes, the on-chain one-vote-per-registration claim is falsified, because the transaction format binds neither the commitment to the proof nor the proof to a single use.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"It supplies the EUDI Wallet regulatory framework from which the protocol draws Sybil-resistant eligibility credentials."},{"cited_title":"Looker, V","cited_arxiv_id":null,"evidence_quote":"It defines the BBS signature scheme used to issue the anonymous voting credential and generate the selective-disclosure registration proof."},{"cited_title":"A generaliza- tion of paillier’s public-key system with applications to electronic voting,","cited_arxiv_id":null,"evidence_quote":"It provides the generalized Paillier threshold homomorphic encryption scheme, including the encryption-correctness proof and the electronic-voting tallying design."},{"cited_title":"On the size of pairing-based non-interactive arguments,","cited_arxiv_id":null,"evidence_quote":"It defines the Groth16 zk-SNARK used for the compact vote proof that links commitment, nullifier, and ciphertext."},{"cited_title":"Trustchain: A sybil-resistant scalable blockchain,","cited_arxiv_id":null,"evidence_quote":"It supplies TrustChain, the peer-to-peer blockchain used as the election's public bulletin board."},{"cited_title":"The knowl- edge complexity of interactive proof systems,","cited_arxiv_id":null,"evidence_quote":"It establishes the zero-knowledge proof paradigm underlying the protocol's privacy-preserving validation."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"It provides the cryptographic implementations used in the benchmarks that support the smartphone-feasibility claim."}],"review_version":1}