[geofft]

Well, it's a reasonable translation - what precisely makes this vote a "blockchain" and not just a giant Excel spreadsheet?

There's no double-spend problem. There's a correct way to merge two ballots cast by the same private key: discard them both. Since all operations are mergeable in an arbitrary order, there's no need for proof-of-work or anything like that to determine which chain is the "correct" chain - any pile of ballots that contains all valid ballots is correct, and any partial pile can get the remaining ballots appended at the end.

From the whitepaper it looks like they're running their own "skipchain," which they refer to as a form of blockchain, but looks to me like a cross between a Merkle tree and a skip list with no proof-of-work mechanism. (It seems like a genuinely useful / novel data structure, I just wouldn't call it a blockchain.) And they're running some sort of proof-of-work consensus to gate additions onto this skipchain, and periodically storing the state of the skipchain in the Bitcoin blockchain.

I don't really understand why the latter two parts are necessary: the record of ballots should be self-authenticating, and it should be easy to tell if someone has removed a ballot, right? Is the idea that people are not likely to watch the skipchain a la CT log monitors, so they want to use Bitcoin because people already watch that?

On the one hand, they appear to have real cryptographers nad real research behind this. On the other, saying "blockchain" seems like a great way for someone running an unfair election to make it appear more legitimate....

[specialist]

I remain interested in tamper evident logging, to better enable end-to-end auditing. In all systems, including election administration.

I worked as a poll inspector. Documenting and proving the physical chain of custody is an important function.

I have yet to see a compelling use case for using blockchains in issuing ballots or counting votes. That's a different beast entirely.

[rlpb]

> Well, it's a reasonable translation - what precisely makes this vote a "blockchain" and not just a giant Excel spreadsheet?

This was my thought also. I could implement what I understand they did just using git. One vote = one line appended. With an append-only merge driver and Github push for publication. No blockchain needed for equivalent functionality and equivalent resistance properties.

[zepolen]

> There's a correct way to merge two ballots cast by the same private key: discard them both

What about the scenario where someone puts a gun to your head and forces you to vote for them - and you can't change your vote at a later period?

[tantanel]

In Estonia they allow you to vote multiple times and only the latest vote counts. They even allow you to then go and vote in the booth which renders your e-vote invalid. I don’t know the internals of how they store the votes but I can’t think of a way to do this without the side effect of knowing who voted for whom.

[toast0]

If you do this with two systems, the e-vote could be encrypted to the second system, but submitted to the first system. During voting hours, the first system would collect the votes and apply the latest value wins rules. Then, once voting is complete, it sends the votes (without envelope information) to the second system to tally. In order to know who voted for whom, you need collusion between the systems.

[geofft]

Hm, do they intend to solve that problem? (Can't the person with a gun just force you to destroy your private key after voting?)

One answer would be to just include the old ballot in the new one, so it's clear which one to invalidate if you see both.

I guess now that I'm thinking about it you also want to prevent ballots from being cast once the election is over, and timestamping an event as having happened before a given point is a valid use of an actual blockchain.

[zepolen]

Two ways:

1. Votes can replace older votes - although this has issues because they could just make sure you don't vote again by pulling the trigger.

2. Let the voter assign 1 and 2 to A and B himself when receiving the private key - which means that when the time to click 1 or 2 comes - only the voter knows if 1 => A or 1 => B which makes it impossible to know who he is voting for.

[walrus01]

blockchains don't solve problems at OSI layer 1 nor will they protect you from rubber hose cryptanalysis:

https://en.wikipedia.org/wiki/Rubber-hose_cryptanalysis

[imtringued]

This is quite an interesting idea! Selling votes becomes risky because the seller can just cancel his vote.