I’ve been asked about a number of ideas lately involving voting systems and blockchains. This blog piece talks about all the security properties that a voting system needs to have, where blockchains help, and where they don’t.

Let’s start off a decade ago, when Daniel Sandler and I first wrote a paper saying blockchains would be useful for voting systems. We observed that voting machines running on modern computers have overwhelming amounts of CPU and storage, so let’s use it in a serious way. Let’s place a copy of every vote on every machine and let’s use timeline entanglement (Maniatis and Baker 2002), so every machine’s history is protected by hashes stored on other machines. We even built a prototype voting system called VoteBox that used all of this, and many of the same ideas now appear in a design called STAR-Vote, which we hope could someday be used by real voters in real elections.

What is a blockchain good for? Fundamentally, it’s about having a tamper-evident history of events. In the context of a voting system, this means that a blockchain is a great place to store ballots to protect their integrity. STAR-Vote and many other “end-to-end” voting systems have a concept of a “public bulletin board” where encrypted votes go, and a blockchain is the obvious way to implement the public bulletin board. Every STAR-Vote voter leaves the polling place with a “receipt” which is really just the hash of their encrypted ballot, which in turn has the hash of the previous ballot. In other words, STAR-Vote voters all leave the polling place with a pointer into the blockchain which can be independently verified.

So great, blockchain for the win, right? Not so fast. Turns out, voting systems need many additional security properties before they can be meaningfully secure. Here’s a simplified list with some typical vocabulary used for these security properties.

Cast as intended. A voter is looking at a computer of some sort and indicates “Alice for President!”, and our computer handily indicates this with a checkbox or some highlighting, but evil malware inside the computer can silently record the vote as “Bob for President!” instead. Any voting system needs a mechanism to defeat malware that might try to compromise the integrity of the vote. One common approach is to have printed paper ballots (and/or hand-marked paper ballots) which can be statistically compared to the electronic ballots. Another approach is to have a process whereby the machine can be “challenged” to prove that it correctly encrypted the ballot (Benaloh 2006, Benaloh 2007).

Vote privacy. It’s important that there is no way to identify a particular voter with how they voted. To understand the importance of vote privacy, consider a hypothetical alternate where all votes were published, in the newspaper, with the voter’s name next to each vote. At that point, you could trivially bribe or coerce people to vote in a particular way. The modern secret ballot, also called the Australian ballot, ensures that votes are secret, with various measures taken to make it hard or impossible for voters to violate this secrecy. When you wish to maintain a privacy property in the face of voting computers, that means you have to prevent the computer from retaining state (i.e., keeping a private list of the plaintext votes in the order cast) and you have to ensure that the ciphertext votes, published to the blockchain, aren’t quietly leaking information about their plaintext through various subliminal channels.

Counted as cast. If we have voters taking home a receipt of some sort that identifies their ciphertext vote in the blockchain, then they also want to have some sort of cryptographic proof that the final vote tally includes their specific vote. This turns out to be a straightforward application of homomorphic cryptographic primitives and/or mixnets.

If you look at these three properties, you’ll notice that the blockchain doesn’t do much to help with the first two, although they are very useful for the third.

Achieving a “cast as intended” property requires a variety of mechanisms ranging from paper ballots and spot challenges of machines. The blockchain protects the integrity of the recorded vote, but has nothing to say about its fidelity to the intent of the voter.

Achieving a “vote privacy” property requires locking down the software on the voting platform, and for that matter locking down the entire computer. And how can that lock-down property be verified? We need strong attestations that can be independently verified. We also need to ensure that the user cannot be spoofed into running a fake voting application. We can almost imagine how we can achieve this in the context of electronic voting machines which are used exclusively for voting purposes. We can centrally deploy a cryptographic key infrastructure and place physical controls over the motion of the machines. But for mobile phones and personal computers? We simply don’t have the infrastructure in place today, and we probably won’t have it for years to come.

To make matters worse, a commonly expressed desire is to vote from home. It’s convenient! It increases turnout! (Maybe.) Well, it also makes it exceptionally easy for your spouse or your boss or your neighbor to watch over your shoulder and “help” you vote the way they want you to vote.

Blockchains do turn out to be incredibly helpful for verifying a “counted as cast” property, because they force everybody to agree on the exact set of ballots being tabulated. If an election official needs to disqualify a ballot for whatever reason, that fact needs to be public and everybody needs to know that a specific ballot, right there in the blockchain, needs to be discounted, otherwise the cryptographic math won’t add up.

Wrapping up, it’s easy to see how blockchains are an exceptionally useful primitive that can help build voting systems, with particular value in verifying that the final tally is consistent with the cast ballot records. However, a good voting system needs to satisfy many additional properties which a blockchain cannot provide. While there’s an intellectual seduction to pretend that casting votes is no different than moving coins around on a blockchain, the reality of the problem is a good bit more complicated.

Banks and financial institutions seem to be all over the blockchain. It seems they agree with the Bitcoin community that the technology behind Bitcoin can provide an efficient platform for settlement and for issuing digital assets. Curiously, though, they seem to shy away from Bitcoin itself. Instead, they want something they have more control over and doesn’t require exposing transactions publicly. Besides, Bitcoin has too much of an association in the media with theft, crime, and smut — no place for serious, upstanding bankers. As a result, the buzz in the financial industry is about “private blockchains.”

But here’s the thing — “private blockchain” is just a confusing name for a shared database.

The key to Bitcoin’s security (and success) is its decentralization which comes from its innovative use of proof-of-work mining. However, if you have a blockchain where only a few companies are allowed to participate, proof-of-work doesn’t make sense any more. You’re left with a system where a set of identified (rather than pseudonymous) parties maintain a shared ledger, keeping tabs on each other so that no single party controls the database. What is it about a blockchain that makes this any better than using a regular replicated database?

Supporters argue that the blockchain’s crypto, including signatures and hash pointers, is what distinguishes a private blockchain from a vanilla shared database. The crypto makes the system harder to tamper with and easier to audit. But these aspects of the blockchain weren’t Bitcoin’s innovation! In fact, Satoshi tweaked them only slightly from the earlier research that he cites in his whitepaper — research by Haber and Stornetta going all the way back to 1991!

Here’s my take on what’s going on:

It is true that adding signatures and hash pointers makes a shared database a bit more secure. However, it’s qualitatively different from the level of security, irreversibility, and censorship-resistance you get with the public blockchain.

The use of these crypto techniques for building a tamper-resistant database has been known for 25 years. At first there wasn’t much impetus for Wall Street to pay attention, but gradually there has arisen a great opportunity in moving some types of financial infrastructure to an automated, cryptographically secured model.

For banks to go this route, they must learn about the technology, get everyone to the same table, and develop and deploy a standard. The blockchain conveniently solves these problems due to the hype around it. In my view, it’s not the novelty of blockchain technology but rather its mindshare that has gotten Wall Street to converge on it, driven by the fear of missing out. It’s acted as a focal point for standardization.

To build these private blockchains, banks start with the Bitcoin Core code and rip out all the parts they don’t need. It’s a bit like hammering in a thumb tack, but if a hammer is readily available and no one’s told you that thumb tacks can be pushed in by hand, there’s nothing particularly wrong with it.

Thanks to participants at the Bitcoin Pacifica gathering for helping me think through this question.

Freedom to Tinker is hosted by Princeton's Center for Information Technology Policy, a research center that studies digital technologies in public life. Here you'll find comment and analysis from the digital frontier, written by the Center's faculty, students, and friends.