Elections are no different than any other info security problem. Multiple checks at multiple locations in the process. Blockchain is not magic pixie dust that makes info security issues go away.
Elections are no different than any other info security problem. Multiple checks at multiple locations in the process. Blockchain is not magic pixie dust that makes info security issues go away.
Blockchains provide a verifiably immutable log. This is the exact primitive you want for elections - tamper-proof logging. It is genuinely a good technological solution to the problems of election legitimacy and validation. That isn't a defense of this article, or of any of the current blockchain/election projects, but in principle, the idea makes sense.
1. Any person can validate that their vote was counted.
2. Any person can validate that their voted counted towards their intended candidate.
3. The collective can validate that no person (i.e. no crypto-id) voted twice.
4. The collective can validate the exact true number of tallied votes (and, e.g. make sure it doesn't exceed the total number of eligible voters).
5. The collective can validate the tallying process. I.e. they can count all the votes on the chain, and themselves reproduce the sums.
That does not address the following:
1. Ensuring that a crypto-id was used by the appropriate person (Although if someone stole your ID, this would likely be discovered by the person it was stolen from, due to previous property #2).
2. Ensuring that a person was not coerced to use their crypto-id against their will.
Which are real problems that I would love to see solutions to. But that doesn't mean we shouldn't try to solve those first 4 as well.
This is a bad idea even in concept. If anyone can validate their vote went for the candidate of their choice, someone else can force them to perform the same validation for money, under threat of violence, familial ostracism, or whatever really.
I get that you understand there is a problem with coercion here, but it's not just an implementation problem, it's a problem with the concept.
I responded to this issue in the previous thread about this. But short answer is: create a verifiable but also deniable scheme.
I like crypto as much as the next person. But the bigger picture means that simpler, dumber systems that rely on lots and lots of humans are more suited to the problem space.
Let's start with imagining a statewide election with a million votes. To move the results by 1% would require 10,000 fraudulent votes. Now, how do we get 10,000 fraudulent votes?
First, we could stuff the boxes with fake ballots. Second, we could have false voter registrations and send "professional voters" around to vote at multiple polling places. Third, we could alter the results at the count, by giving a false count.
Now, let's introduce a process step: all activities that involve touching ballots, whether marked or unmarked, must be done in the presence of representatives of at least two political parties. In other words, if Team A is going to try to physically manipulate ballots or counts, they have to do it where Team B can watch them do it. How does that affect things?
And there's the process of running a polling place. At the beginning of the day, you get X number of blank ballots. They were delivered by two parties, and counted by two parties, and are presumably under some sort of seal. We know how many ballots are in the building. And there's a paper voter registration roll, with the names of every registered voter in the precinct. When a voter comes in, they look up the name on the roll, and the voter signs to say they voted. A tally is kept of how many voters sign. Each voter then gets a ballot, marks the ballot, and puts it in the box. At the end of the day, count the number of ballots. It should match the number of voters on the tally, and can be hand-checked against the number of signatures on the roll in a recount. Spot-checks of this at random precincts prevent widespread alteration without triggering a recount. The number of votes plus the number of remaining blank ballots equals the number of blank ballots at the beginning. So inserting fake ballots is hard. Inserting them in a way that can't be detected at count time or at recount time is harder.
So, how about false registrations and professional voters going around making multiple votes in different precincts? Remember, we need 10,000 votes to move the tally 1% in our theoretical election. Let's say one professional voter can make it to ten polling places over the course of a day. So you would need a thousand of them, trained, with targets. They would need to be either fanatical, or paid. And you need to do this with no leaks, no turncoats, no one who thinks "I could sell my story to the news for tens of thousands", no hidden cameras... yeah. (As an aside, this is why insistence on voter ID is misplaced. The difficulty of the problem prevents it far more than an ID step would.)
So how about altering the count? Well, if it involves altering the ballots themselves, it's a hard problem. (Unless you use those idiotically dangerous touchscreen machines, which ought to be illegal.) You need to remove valid ballots and replace them with altered ones, again with multiple parties observing. Or you can alter the final result count, but then it mismatches the paper ballots, and would be detected as fraudulent at recount time. Spot check hand-counts detect such issues.
Technical implementation example here: In Minnesota, we use Scantron machines. If there are multiple Scantrons at a polling place, we will hand-count one of them and compare to its electronic tally. The electronic tally from the machine is an unofficial result only, until certified.
Now, let's look at some easy things to do to manipulate elections! First, gerrymandering - draw district lines that make it nearly impossible for one party to win. I live in such a district. We're more likely to get visited by aliens than elect a Republican in my district. Second, voter suppression. Make it increasingly more difficult to vote - limit polling station resources in certain districts to force multi-hour lines, require ID, etc. These are popular and common. See how this works?
Blockchain doesn't fix ANY of this. Either it's already fixed, or could be fixed by improving the process based on models that are demonstrably good in other states.
Heck, they do fair elections in poor countries with high illiteracy rates, too. Just stamp each voter's hand when they vote. No one can vote twice because stamps are checked. Ballots can have symbols for parties rather than words. Election validation is easy.
Don't get me wrong - there's a ton of hype around blockchains that is completely unjustified. But there are a few applications where it may have some utility, and I think this is one of them. So it irritates me when I see people on HN jump on the "blockchain therefore hype" bandwagon without spending the time to actually think about when this sort of technology is useful and when it isn't.
A decentralized blockchain is far more trustworthy than a centralized database in this scenario. Say Russia controls the centralized voting database, they can just edit whatever value they want to say "Putin" and call it a day. It's not public. No one can verify their vote. It's under the control of one party. The entire point of decentralization is to ensure there is public consensus among multiple parties.
There are other discussions about how to allow or incentivize citizens to run nodes, mitigate lost or stolen IDs/private keys, prevent against spam attacks, etc...but it sounds like you aren't even open to discussing those because you equate the word "blockchain" with "snake oil".
And now you've told everyone exactly how millions of citizens voted.
It is exact opposite of what is wanted.
i disagree. the exact primitive you want is a verifiable counter, where people can be verified as being allowed to add one to the counter, with no ability to determine who added to which counter. that is different from a verifiably immutable log.
also, there are scenarios where a blockchain can be mutated, and i bet you that the election of a country would provide a very enticing target for subverting the blockchain.
> That isn't a defense of this article, or of any of the current blockchain/election projects, but in principle, the idea makes sense.
but in practice, maybe it doesn't? elections aren't some academic thing.
Then the main question is, is what you're willing to pay to append a record more than what the operators (miners) are willing to accept to append a record? In the case of elections, I don't know a lot of governments that would be willing to pay to do what they do for free today.
So basically even IF the blockchain was not costly, the nation would need to control the developers to control the blockchain in the case of consensus failure (fork) to make sure no one messes with the election results.
Yes they are. That's not what 'immutable' means. Immutability refers to an inability to change the past. Not an inability to fork the future. A blockchain is a persistent, immutable data structure. This is just a simple fact of computer science.
side note: I'd be wary of calling blockchain's consensus mechanism "computer science", it's more of a social consensus when consensus rules are different (ie. when forks are involved).
https://en.wikipedia.org/wiki/Immutable_object
Blockchains are immutable. Immutability is the property you want for elections. Blockchains are absolutely computer science. The consensus PoW mechanism is not part of 'blockchains'. It is a part of cryptocurrencies. Blockchains are simply a log-structured Merkle tree.
> We would know and be able to prove that they invalidated or ignored the results
To your new point, though, picture this: it's 2016 and you're running your election on the blockchain. Unfortunately, a consensus bug in the blockchain causes the updated nodes (say, half the network that updated) to split. The devs decide to go forward with the new consensus rules and abandon the other chain. However, we find that the tally on the abandoned chain elected Hilary and the tally on the new chain elects Trump. What happened? Were the devs co-erced? Did they introduce the bug themselves? Why was the tally different on the abandoned chain? Who collected the tally and wrote it to the blockchain?
How do we know or prove the legitimacy of the chosen blockchain over the abandoned one, as you claim?
Whether or not you could convince someone of it, it is so. The definition of an immutable data structure is that the contents of it don't change. It says nothing about interpretation. Immutability isn't some nebulous concept, it has a specific definition in computer science. And it is that the data itself does not change.
> To your new point, though, picture this: it's 2016 and you're running your election on the blockchain. Unfortunately, a consensus bug in the blockchain causes the updated nodes (say, half the network that updated) to split. The devs decide to go forward with the new consensus rules and abandon the other chain. However, we find that the tally on the abandoned chain elected Hilary and the tally on the new chain elects Trump. What happened? Were the devs co-erced? Did they introduce the bug themselves? Why was the tally different on the abandoned chain? Who collected the tally and wrote it to the blockchain?
> How do we know or prove the legitimacy of the chosen blockchain over the abandoned one, as you claim?
There is no need for consensus in an election-based blockchain, and this is not a new point, it's been my point the entire time. It's the point of all blockchain-election solutions. We can arbitrarily choose any chain, and then verify all the properties that we care about on it.
Okay, so which of the chains changed?
(Hint: neither changed; they can't change, because they're immutable).
You seem to have a chip on your shoulder with this idea the developers control the blockchains. Every time you see something about blockchain you seem to jump in and start arguing with people in favor of your pet issue. I've seen you do this on multiple threads now.
The irony is, there are some persuasive arguments for the idea that developers have too much control of blockchains, but you're not saying any of them, because you clearly don't grok the technology. You have a Wired-magazine-level understanding of the technology: you know the history and social systems around the technology but you clearly don't understand the concept of immutability as it applies to blockchain forks, or why consensus is both a social concept and a computer science concept when applied to blockchain, or how a block is validated.
In your defense, understanding blockchains requires a lot of background, and I'd say most people don't understand it. But most people aren't arguing so vehemently for their opinion.
The rest of your post is pretty offensive but I'm willing to look past it if you want to actually talk about your blockchain ideology with civility.
I honestly think the disconnect here is you're thinking in terms of bits and atoms and I'm thinking from the user's perspective. If we're going to build something useful with the blockchain, we have to think from the user's perspective. It doesn't matter if it's 2 separate "block chains", they're both attempts at finding consensus on 1 ledger: the Bitcoin ledger. That's the whole point of a distributed ledger: at any given time you may have disagreeing versions of it existing simultaneously, but it's still 1 ledger trying to find consensus so that users can know what happened actually. And if there are times where developers are ESSENTIAL to resolve ledger consensus failures, that is precisely the kind of central control that could be abused in ways Satoshi was trying to avoid. We don't even know if the 2013 bug was intentional or not. What if the developers were compromised and the fork was made so that someone could execute a large double-spend? What if this happens again in the future?
I don't usually go out of my way to tell people they are uninformed, but you're spreading very uninformed opinions around. You can't reasonably expect to spread your uninformed opinion around and not have people tell you you're uninformed. If you take offense to that, well, maybe you should limit yourself to sharing opinions about things you understand. I'm not saying this to offend or hurt you, I'm saying it because it's a fact you should be aware of.
I don't think you're dumb; you seem like a smart guy. You're just ignorant on a specific topic--and that's okay too--ignorance is fixable. But you should fix it before you start spraying your opinions on the topic around.
> I honestly think the disconnect here is you're thinking in terms of bits and atoms and I'm thinking from the user's perspective. If we're going to build something useful with the blockchain, we have to think from the user's perspective.
No, the cryptography (which has little to do with bits and nothing to do with atoms) affects users. You can't simply argue that you understand Bitcoin well enough because the social aspects of Bitcoin are the important part. Both the social aspects AND the cryptography aspects are vital to understanding--if you don't understand the cryptography you don't understand Bitcoin. Period. This is especially true when you make claims that are directly about the cryptography (such as that a block chain is not immutable) which show that you clearly don't understand it.
> It doesn't matter if it's 2 separate "block chains"
Since that is literally what a fork is, if it "doesn't matter" then why are we even talking about a fork?
> they're both attempts at finding consensus on 1 ledger
No, they're both (immutable) data structures which hold a ledger. "Attempts at finding consensus" aren't really represented by a data structure.
> What if the developers were compromised and the fork was made so that someone could execute a large double-spend?
You could start to build a plausible case for this by looking at the respective blockchains--which is, incidentally, an effect of them being immutable. But I thought this "doesn't matter".
But that's unlikely, because the fork was relevant for < 2 hours. The attacker would have had to spend their coin and the seller would have to release control of the asset they were spending the coin for, in that time.
And if a large double spend were executed, there's a good chance we'd know about it because the seller who received their coins on the 0.8 blockchain would probably be pretty angry about it.
Because if you did, you would understand that when your values (in this case, transactions) get modified unexpectedly even if they’ve been consistent for an arbitrarily long time, you cannot claim that your database is immutable. The fact that the individual attempts at consensus are immutable is irrelevant because the user only cares about the resulting ledger, which as I have proven to you over and over again is mutable.
I see what you did though, you defined “blockchain” as just an individual chain, not as the encompassing consensus-finding system... which to me is not a useful definition because it leads to misunderstandings like yours (ie. “the database is immutable”). Picture this:
Exchange: “Why did the Bitcoin I received vanish? I thought Bitcoin was immutable??!!!”
You: “Oh lol you’re terribly misinformed, it’s the data structures that are immutable, silly, not the actual database. Obviously the database consensus can fail and that can make you lose money, unless it’s controlled by trustworthy and honest people of course... who made you believe otherwise?”
That being said, this particular project is not a good example of any of that. But blockchain for elections is actually one of the few truly technically legitimate uses of the technology.
Secure cryptography and other algorithms that verify authenticity have the potential to remove all doubt. Blockchain has very little to do with it.
given a very specific and likely untenable list of assumptions about the way the entire human system works, yes, i'd agree that they might remove all doubt.
outside of textbooks, i think plenty of other comments here have cast doubt on how a blockchain voting implementation would solve real world problems in practice.
If a government is holding fair elections, they should be willing to spend money on the opportunity to prove that they are fair. That being said, you don't actually need mining in an election-based blockchain. Mining/PoW exist to solve the 'double spend' problem - but that's just a race condition. There's no need to worry about race conditions in elections. The global consensus can be computed slowly. The important property that you want is that each individual voter be able to mathematically verify that their own personal vote was counted towards the total, and counted correctly. Blockchains do offer that capability.