3 ms·

Have the primary key be a number or hash and publish the whole database, so you can count the number of votes yourself, or verify your vote, but cannot reverse

by paulmd 9y ago

Have the primary key be a number or hash and publish the whole database, so you can count the number of votes yourself, or verify your vote, but cannot reverse any single vote back to a person without knowing their voter number. Whether we structure this as a Merkle tree or a flat CSV is irrelevant. Of course, in neither data format do you have any way of actually authenticating the other votes, by design. Maybe the vote in the block before yours was a dead person, or never existed at all, how would you know? (this is what the crypto world calls a "sybil attack") Whoops, looks like we're back to trusting a centralized authority (the government, who issues the voter tokens). So why do we need millions of computers hashing away, again? Fundamentally, one of the design features of voting is that it's un-verifiable, i.e. you can say you're voting Bush and go into the booth and vote Gore, and nobody can prove otherwise. Otherwise you could have personal threats against you (boss/spouse/etc) and if you have a ticket that can be verified to show you voted Gore then you could suffer personal harm. Verifiability to the public is actually an bug in the system here - it should be verifiable to the government and no one else. The best systems produce a paper token that is retained at the voting site. You can then validate the number of tokens against the voting rolls/etc, but the "evidence" stays in the possession of the government (who we've already agreed must be trusted anyway since they're the ones maintaining voter rolls/issuing tokens and ballots/checking IDs/etc). I forget what the name of the theorem is, that says identifiers like domain names or onion names can either be unique/authentic, intelligible, or decentralized, pick any two. Well, you can also say that ballots can either be publically verifiable, trustless, or private, pick any two (where "guaranteed one-per-person" is a form of trust). Blockchain doesn't escape this, it is just a different format for the data (Merkle tree vs flat CSV).

philipodonnell 9y ago
> Maybe the vote in the block before yours was a dead person, or never existed at all, how would you know? Whoops, looks like we're back to trusting a centralized authority (the government, who issues the voter tokens). That's what I mean by the difference between counting votes and recording votes. All the dead people throughout history could record a vote, but that's doesn't mean they all have to count in terms of who gets elected. All you would need is a private key given to you by the government that is associated with your identity that you use to sign your vote. Then the government can only count the votes by the identities it trusts.
- paulmd 9y ago
  It doesn't matter whether the data format in this case is a Merkle tree or a flat CSV file. OK, we add an extra column in the CSV, now we have "secretvoterid, vote, signature", still no need for blockchain. Also, you are still fundamentally trusting a centralized authority - the government who issues the keys, and the same government you were worried about fudging the vote count. Maybe the government is adding people who don't exist (sybil attack), and the "signatures" on some of those votes are just random noise, how do you know? So your scheme gains you nothing. At the end of the day, the only trustless scheme for voting is being able to tie votes back to names so that illegitimate votes can be challenged by the public. Any other scheme requires you to trust the government to count votes fairly, or issue keys/voter tokens fairly (we can call these a "ballot"). Blockchain doesn't change this, and if we want to get rid of the secret ballot we don't need Blockchain to do so.
lagadu 9y ago
> Of course, in neither data format do you have any way of actually authenticating the other votes, by design. Maybe the vote in the block before yours was a dead person, or never existed at all, how would you know? In many European countries we do have that, as we carry our national ID cards[0] that have their own private key for signing documents and authenticating. Signing a vote securely isn't a problem but then the problem comes on how you sign it and keep it anonymous simultaneously. Also of course we trust that the state doesn't keep the private keys somehow when creating new cards. [0] https://en.wikipedia.org/wiki/National_identity_cards_in_the_European_Economic_Area#Electronic_identity_cards https://en.wikipedia.org/wiki/National_identity_cards_in_the...
- paulmd 9y ago
  Same problem though, the fact that the "token" is pre-issued vs election-specific doesn't change anything. If you are worried that the government is going to change the vote tally, should you not also be worried that the government will generate fake keys to vote in the election, or simply add rows with fake signatures? You need to verify that those rows are authentic, and that's not possible while maintaining a private ballot. The only defense is to have someone who can say "I.C. Wiener is not a real person", whether that's the government or the public. Private-ballot voting only works with the government as an "oracle". The government is the defense against sybil attacks (multiple voting, etc). You can have other systems if you are willing to let people see how each other voted, but private-ballot voting is pretty ingrained at this point. --- theory stuff: A trivial solution to the problems that blockchain approaches is "majority-wins". You take a vote and whatever the most participants agree is the "true" history wins (eg electing a master node in a distributed system). But how do you prevent one attacker from pretending to be a lot of people (aka a sybil attack)? What blockchain provides is a solution for sybil attacks - participants are individually financially incentivized to burn the maximum amount of power they can, and an attacker must burn more than the rest of them combined to succeed. As a general statement, "private" blockchains make little sense in that context, since you've removed the Red Queen's Race that provides the sybil-resistance. Most people are better off just using a database, since they really have no need of sybil-resistance anyway. The participants are trusted (f.ex when electing a master node in a distributed system), or can agree to trust some oracle (the party who runs the server). A regular database works fine for these cases. Without the cryptocurrency attached, what you really have is Merkle trees, not a blockchain. I love Merkle trees, I use them all the time in my filesystem (ZFS). But the "shape" of the data on disk does not provide any particular benefits in terms of consensus-resolution. For things like voting, distributing the vote tabulations as a flat CSV would be just as effective as distributing them as a Merkle tree.

by paulmd 9y ago

philipodonnell 9y ago

> Maybe the vote in the block before yours was a dead person, or never existed at all, how would you know? Whoops, looks like we're back to trusting a centralized authority (the government, who issues the voter tokens). That's what I mean by the difference between counting votes and recording votes. All the dead people throughout history could record a vote, but that's doesn't mean they all have to count in terms of who gets elected. All you would need is a private key given to you by the government that is associated with your identity that you use to sign your vote. Then the government can only count the votes by the identities it trusts.

paulmd 9y ago
It doesn't matter whether the data format in this case is a Merkle tree or a flat CSV file. OK, we add an extra column in the CSV, now we have "secretvoterid, vote, signature", still no need for blockchain. Also, you are still fundamentally trusting a centralized authority - the government who issues the keys, and the same government you were worried about fudging the vote count. Maybe the government is adding people who don't exist (sybil attack), and the "signatures" on some of those votes are just random noise, how do you know? So your scheme gains you nothing. At the end of the day, the only trustless scheme for voting is being able to tie votes back to names so that illegitimate votes can be challenged by the public. Any other scheme requires you to trust the government to count votes fairly, or issue keys/voter tokens fairly (we can call these a "ballot"). Blockchain doesn't change this, and if we want to get rid of the secret ballot we don't need Blockchain to do so.

lagadu 9y ago

> Of course, in neither data format do you have any way of actually authenticating the other votes, by design. Maybe the vote in the block before yours was a dead person, or never existed at all, how would you know? In many European countries we do have that, as we carry our national ID cards[0] that have their own private key for signing documents and authenticating. Signing a vote securely isn't a problem but then the problem comes on how you sign it and keep it anonymous simultaneously. Also of course we trust that the state doesn't keep the private keys somehow when creating new cards. [0] https://en.wikipedia.org/wiki/National_identity_cards_in_the_European_Economic_Area#Electronic_identity_cards https://en.wikipedia.org/wiki/National_identity_cards_in_the...

paulmd 9y ago
Same problem though, the fact that the "token" is pre-issued vs election-specific doesn't change anything. If you are worried that the government is going to change the vote tally, should you not also be worried that the government will generate fake keys to vote in the election, or simply add rows with fake signatures? You need to verify that those rows are authentic, and that's not possible while maintaining a private ballot. The only defense is to have someone who can say "I.C. Wiener is not a real person", whether that's the government or the public. Private-ballot voting only works with the government as an "oracle". The government is the defense against sybil attacks (multiple voting, etc). You can have other systems if you are willing to let people see how each other voted, but private-ballot voting is pretty ingrained at this point. --- theory stuff: A trivial solution to the problems that blockchain approaches is "majority-wins". You take a vote and whatever the most participants agree is the "true" history wins (eg electing a master node in a distributed system). But how do you prevent one attacker from pretending to be a lot of people (aka a sybil attack)? What blockchain provides is a solution for sybil attacks - participants are individually financially incentivized to burn the maximum amount of power they can, and an attacker must burn more than the rest of them combined to succeed. As a general statement, "private" blockchains make little sense in that context, since you've removed the Red Queen's Race that provides the sybil-resistance. Most people are better off just using a database, since they really have no need of sybil-resistance anyway. The participants are trusted (f.ex when electing a master node in a distributed system), or can agree to trust some oracle (the party who runs the server). A regular database works fine for these cases. Without the cryptocurrency attached, what you really have is Merkle trees, not a blockchain. I love Merkle trees, I use them all the time in my filesystem (ZFS). But the "shape" of the data on disk does not provide any particular benefits in terms of consensus-resolution. For things like voting, distributing the vote tabulations as a flat CSV would be just as effective as distributing them as a Merkle tree.