[aazaa]

This article reminds me of every other article I've seen about blockchain voting. None of them start with a threat model. None of them talk about what's broken with voting. Mostly they just dive into technology, relying on the reader's imagination to address these points.

Here are some simple questions:

1. What are you trying to protect in a vote?

2. Why can't an SQL database with whatever levels of cryptographic assurance you'd like to add do the job?

3. What does a blockchain add to (2) that no other technology does, regardless of cost?

These questions are never answered, and indeed they are not answered here either. Instead, these articles lead with technology and rarely get around to what matters.

Often there's something like this included in the article:

> Blockchains are a technology which is all about providing guarantees about process integrity. If a process is run on a blockchain, the process is guaranteed to run according to some pre-agreed code and provide the correct output. No one can prevent the execution, no one can tamper with the execution, and no one can censor and block any users' inputs from being processed.

No. A block chain is a timestamping mechanism. Within certain very narrow boundaries, it makes certain guarantees about the relative ordering of events. A tamper-resistant log file? Yes. A solution to voting? Does that involve relative event ordering? If so, is that the central problem?

Electronic cash systems like Bitcoin will work work just fine without a blockchain, provided they can solve the double spending problem. Bitcoin solved it with a system for ordering transactions based on proof-of-work. There are other solutions, but all suffer from censorship pressures in ways that Bitcoin does not.

[mariusor]

> 2. Why can't an SQL database with whatever levels of cryptographic assurance you'd like to add do the job?

> 3. What does a blockchain add to (2) that no other technology does, regardless of cost?

I'll preface this by saying that I'm not a blockchain expert, but from the comfort of my own armchair I consider that the main benefit over a regular SQL database is the fact that you don't need to make it secret and protect it.

There might be other methods for storing a well-ordered list of events in a difficult to tamper with but at the same time public repository, but I don't know of any.

[throwawaylinux]

> I'll preface this by saying that I'm not a blockchain expert, but from the comfort of my own armchair I consider that the main benefit over a regular SQL database is the fact that you don't need to make it secret and protect it.

What are you needing to make secret or protect?

> There might be other methods for storing a well-ordered list of events in a difficult to tamper with but at the same time public repository, but I don't know of any.

Look at all the repositories up on github that are doing exactly this. I don't know why you would need to store voting results as well-ordered, but if you wanted to it's easily possible.

[mariusor]

Tamper proof is also a requirement, but if you're arguing about git having some of the same properties as a crypto ledger, I would agree.

[JadeNB]

> 3. What does a blockchain add to (2) that no other technology does, regardless of cost?

Not defending blockchain, but this seems like an absurdly high standard. To me, the cost of a technology is definitely one factor in evaluating what is better or worse for solving a given problem.

[acdha]

It might be a bit strong — I would phrase it as “What does a blockchain do better than the alternatives?” — but I think it's justified in this cause because of how inefficient blockchains are for most problems. It's not just the cost of all of the extra hardware but also the design impacts of what operations you consider fast and the reliability impact of a shared global view.

In particular, in this case the question I'd be asking is “how is this better than PKI?” because that can do the job with multiple orders of magnitude less overhead and would be suitable for use in scenarios with limited bandwidth or which are completely offline, which is realistic for voting.

[wccrawford]

I somewhat agree, but with the amount of money that has already been spent on failed electronic voting systems, I think "regardless of cost" is pretty accurate here.

[XMPPwocky]

Right - it seems like at most what you want is a Merkle tree published at the end of the election, with all counted votes (in a coercion-resistant way, using the mechanisms described). Need to order events to support a more complicated protocol? Do a "Merkle linked list" (i.e. a blockchain-ish thing but without a consensus mechanism, like a TPM PCR+audit log combination).

Why do you want to use a public blockchain? Well, they try to explain that.... try.

"So why is a blockchain better than a special purpose bulletin board? The answer is: setting up a k-of-n system that's actually trusted is hard, and blockchains are the only system that has already solved it, and at scale. Suppose that some government announced that it was making a voting system, and provided a list of 15 local organizations and universities that would be running a special-purpose bulletin board. How would you, as an outside observer, know that the government didn't just choose those 15 organizations from a list of 1000 based on their willingness to secretly collude with an intelligence agency?

Public blockchains, on the other hand, have permissionless economic consensus mechanisms (proof of work or proof of stake) that anyone can participate in, and they have an existing diverse and highly incentivized infrastructure of block explorers, exchanges and other watching nodes to constantly verify in real time that nothing bad is going on."

"anyone can participate in" is absolutely hilarious in this context. It's true, in the sense that pretty much anybody can buy a few kilograms of gold- if they have the money. Proof of stake is the most obvious here, because it's literally "the more money you have the more power you have"- there's SOME argument that this makes sense when the decisions made by stakers directly relate to the value of Ether, the idea being "rich person won't try to manipulate consensus, because that would make them much less rich" (especially if they actually get slashed). i.e. they have a stake in keeping consensus fair. But doing real-world elections breaks this entirely. Proof of work functions similarly, just indirectly, and also while spewing CO2 into the air and sucking down semiconductor manufacturing capability.

Now, a common answer is "well, yes, but we could detect that manipulation happened after the fact, and then re-hold the election or whatever, possibly slashing malicious validators if we can somehow encode that into the protocol at a lower layer". Congratulations, you've figured out why blockchains are useless here. The actual security comes from being able to detect fraud- and a single Merkle root published by the government per election (and signed, so any forks could be immediately detected and proven bad).

In other words, you want Certificate Transparency, not Ethereum. CT solves exactly the problem Ethereum tries to solve here, and does it much better, and without the obvious conflict of interest cryptocurrency voting advocates have (that if a government did use, say, Ethereum for elections, it'd drive the price way up, so anybody advocating that who also holds Ether has a bit of a credibility problem right out of the gate!)

And this is all predicated on cryptographic voting being a good idea in the first place - in the short term, it's just not. You can verify the protocol, but you can't verify the endpoint- are people going to vote on their own devices? Just wait til the first claims (justified or not) that a major botnet flipped votes undetectably (and coercion-resistance guarantees that it really can be done undetectably). Or maybe on voting machines like we have today? Take a look at what happened to Dominion last cycle- so much for making elections more trustworthy.

Paper is actually incredibly useful here, because it doesn't run code and everybody knows it. (You could say "oh this CPU has all its code in mask ROM and the code is formally verified" and maybe I could confirm that, but most people could easily be convinced, understandably, not to trust me). Voting machines that print out your vote on paper that goes into a box, in sight of the voter, where the voter can read their paper- that's brilliant here. Can you attack that? Sure- switch out the boxes when nobody's looking, etc, etc.

But if I see, on the screen of my phone, "vote confirmed for Candidate A", for all I know my phone's actually sent to the server that I voted for Candidate B. And coercion-resistance requires that my phone can't ever prove to me that it really did vote for Candidate A - the phone's the actual voter here, not me, I'm not participating in the protocol. I'm just providing my phone some private keys and, on an unrelated note, giving it touchscreen input- nothing ties the two together. This is really important to understand. Your device is the voter in cryptographic schemes like this. You just tell it who to vote for, and trust it when it tells you it voted for them. (There's a workaround here but it has UX problems that seem to make it a non-starter too.)

If I see, on paper, that my ballot says "vote for Candidate A"... well, that's what the paper says. If somebody looks at the paper later, they can be pretty sure that's what I saw on the paper, as long as nobody has messed with it in the meantime. And to ensure nobody has messed with it... well, we have hundreds of years of experience figuring that out. This is the key- paper that is later counted (or even only counted randomly to confirm electronic results) binds feedback to the actual voter with the vote. On a phone, network traffic is NOT bound to touchscreen input or display contents, and it can't be without breaking coercion resistance.

[mariusor]

I don't find your model of the paper ballot much safer than the one of voting through an electronic device. Yes the paper might say you voted for A, but the chain of interactions between you placing the vote in an urn and the vote being counted for A, is as long and as uncertain as in the electronic model.

You choose to trust the humans more, which is fine, but applications (or why not) devices with a well defined audit trail that they're doing what they're supposed to do are equally trust worthy (at least for me).

[XMPPwocky]

The second half of that summarized: if you want to do cryptographic voting, OK- but print out paper ballots too, with both the votes in human-readable format and a QR code or something containing a hash of the protocol transcript or something that allows confirmation that the cryptographic vote matches the votes printed on the paper. Then do risk-limiting audits.