Very exciting. As things like this become more well-defined, and start to solve the security/ease-of-use problem, I think (hope?) that we'll see some truly groundbreaking applications of distributed decision making tools.
I'm doubting it. The reason is that they're both really hard to come up with and really hard for end-users to understand. That last part is important for widespread trust and verification. It's why I've always been in favor of centralized models with distributed verification. Especially simple computations that can just be re-run on available data with tamper-detection and comparisons of hashes, etc.
You mean something as trustworthy and tamper proof on a large scale as paper ballots and manual tallying? I still haven't seen any electronics that can be practically verified by the public comparable with the centuries old manual solutions that anyone can follow. Using electronics means getting a massive TCB with many orders of magnitude less the number of eyes that can actually inspect the computations being run (both because of organizational reasons and lack of knowledge).
According to Halderman* it might take us 10 years, if ever, to get machines the public can trust and verify on the scale that is needed for nation-wide elections.
Given the sorry state of current phone and laptop security, the problem of having a massive TCB is not solved, not with building on Ethereum either.
It's all in the protocol and implementations: you don't need to trust huge TCB's and manufacturing of specific device. Low TCB, diverse, clients doing the checking is all you need. The paper comparison is unfair given online and electronic is assumed in the requirements of the OP. Something closer to paper in usability, cost, or security would be:
Scantegrity, like other secure electronic systems, scores low on usability[1].
Recently the CEO of Fox-IT reported a delay to our minister in the Netherlands[2] with researching the specs for a usable and secure vote printer and vote counter[3]. It's not as easy as people think, especially the elder seem to have trouble with it.
Thanks for the data. I'll factor that into future comments. The direction that leads, though, is improve the usability rather than toss out the whole system or its principles.
My main recommendation if anyone asks with intent to deploy is paper and optical readers. Cheap, easy to use, easy to check at booth, and easy to audit later. I prefer computers stay out of voting as much as possible. However, if they're there, Scantegrity line and Civitas seem like top contenders to build on.
Also note in any analysis that secure voting has so many seemingly-contradictory requirements and attack points that any solution will likely pose difficulties. I expect some responsibility and effort from the system's users just like they must put effort into learning to drive. That said, the usability can certainly improve and we should put every effort into that.
Absolutely agree on this. This right now is more of a Minimum Viable Product, but I'm already working on a new application (or rather social experiment) for decentralized decision making. Exciting times ahead with new technologies such as Bitcoin, Ethereum and IPFS :D
Plus, you don't really need decentralized voting so much as decentralized checking. That's where the effort should be. Blockchains are a total waste of time and money for this kind of thing. Especially with so many prototypes in existence that use less energy/money with good security properties.
Ou I absolutely agree on that. This is nothing more than a simple Proof of Concept for voting on Ethereum/a Blockchain. Definitely also agree that the ideology of "decentralize and blockchain everything" is wrong.
In the current implementation of PublicVotes, it costs around $1 to record some 200 votes into the Blockchain. This is quite expensive compared to systems such as Civitas, but it is arguably, cheaper than the current system where governments often count vote ballots by hand. (at least that's how it's done around here in Italy).
Nonetheless, I do think though that Smart Contracts can play an important role in future voting systems, and obviously they can empower entire governments. I will work on a Liquid Democracy model next for which Smart Contracts make a lot of sense.
> This is quite expensive compared to systems such as Civitas, but it is arguably, cheaper than the current system where governments often count vote ballots by hand.
Maybe cheaper, but I'm not sure if having to trust my computer with an important vote like that is better than having to trust a voting booth, ballot box and my eyes when the votes are being tallied. I think the slowness of manual tallying is a security property since anyone can inspect the computation while it's being run. All other technologies like Civitas, Scantegrity etc. are not cheaper but more expensive than this manual process and open up great possibilities for state level adversaries.
I think your system (using peoples computers) might be trusted when the stakes are lower though. Interesting project :)
I think the Ethereum approach is actually a good one. Ethereum will be the subject of quite a lot of study and scrutiny and its security properties should become very well understood.
Once that is true, then you can analyze the voting contracts specifically, which is a smaller problem.
Projects like Civitas can only be as strong as the amount of interest in them. But projects based on Ethereum can be, on some level, as strong as the entire aggregate interest in all Ethereum contracts.
That's not true at all: you need interest and expertise. The security requirements of voting systems are well-understood and go way back. Many people's first experience was probably reading Schneier's Applied Cryptography where it spelled them out along with example attempts. Many papers and projects since then. The cryptographers designing voting schemes usually model them to show through mathematical or manual analysis that they possess the security properties.
Your proposal is that people without knowledge of secure voting systems or cryptography throw something together with a lot of press. That approach hasn't produced a secure anything, much less voting scheme. Further, experience with tools such as OpenSSL shows the "many eyes" hypothesis it relies on will also be of limited use. Best to learn what pro's know about something, figure out what's worked to varying degrees, build on those, or build something better with similarly good properties.
Good thing is that this is a side project for author's enjoyment and learning.
> That's not true at all: you need interest and expertise.
I was talking about interest specifically from the computer science community. Ethereum can, at least in theory, provide proof-level security. Have you read about it at all? I don't mean to be insulting, but I am not sure if you are just defending yourself or if you really are saying you think Ethereum plays no role in this kind of project.
> Your proposal is that people without knowledge of secure voting systems or cryptography throw something together with a lot of press.
No, my proposal is that people build on Ethereum. Which is the target of much cryptographic scrutiny and will be more and more so as it (or whatever similar thing gets the brass ring) takes off.
I am not suggesting "just throw some crap out there and let the internet handle it". I am suggesting rigorous academic proofs to show that Ethereum has the general purpose computing properties that it has, and then rigorous academic proofs on the specific voting contracts people write for Ethereum.
I appreciate your dialog on this subject, but you are really putting words in my mouth. I would ask that you dial it back a little and please try to respond to what I'm saying, not what you think people in general often suggest to you.
Hmm, I'll backtrack since you've clarified your position and it's more reasonable than what I thought it implied in discussion's original context.
Alright, any secure voting concept must first start with the requirements for secure voting. The link below has a nice chart and explanation of them. I'm only linking it for that is I've neither read nor endorse the rest of the paper: just first result in Google that had correct properties for reference. Schneier's Applied Cryptography was where I originally learned them.
As you can see, the requirements are hard even on the surface due to the contradictions. Examples include simultaneous secrecy, verifiability of counts, and accountability for overall process integrity. Keeping it close to traditional model laypeople understand while implementing all these countermeasures is even more difficult. Eliminating subversion risks that aren't on that list makes computers in general pretty risky and some people don't have Internet. So, any attempt at addressing this will be done by well-researched amateurs or pro's with a design that offers a balanced solution to all these plus a robust implementation strategy. Anything less is to be discounted immediately unless the use-case justifies lacking one or more properties. So, I dismissed the project immediately. Good news it was just for author's fun/learning.
Now, onto your other points about Ethereum. Your idea about studying Ethereum, understanding its security, optionally proving variants, and maybe building a system on top of those properties is the right way to go. So much to do that the project might be dead before the cat and mouse game gets far enough to trust it: usually takes 10+ years for anything that's a paradigm-shift. That was the case for most decentralized, OSS software focusing on anonymity or security. I hope not for this, though, as I'm sure the design will teach us new things worth learning.
That said, you're right in that I think Ethereum plays no role and have little knowledge of it. Good perception. I read early that it was a blockchain approach with programmed contracts and such. If we're talking Bitcoin-style, most blockchains I've seen are ridiculously inefficient compared to prior P2P techniques, esp distributed transactions. Often more complex and slow, too. My default recommendation is to build on prior, non-blockchain solutions to problems any time they exist and already have good properties. This is the case for voting and even programmed contracts: a tech we did in 90's under banner of agent-oriented programming with languages like Safe/Tcl, Telescript, and DEC's Obliq that implemented everything from contracts to on-site analysis of product/financial databases. Those, except Obliq, ran fast on 350nm 100-200Mhz CPU's, a few MB RAM, and 28Kbps Internet. Not sure about Ethereum but Bitcoin community is currently sourcing 28nm ASIC's for mining and the blockchain is huge.
So, I opposed both by default. One because it was a toy project that lacked the necessary properties. The other because it was based on horrifically-inefficient tech and might have inherited those properties. That said, descriptions I've read were interesting and the ecosystem is picking up with interesting claims on cost/benefits. I plan to evaluate its architecture at some point. I might find that I'm entirely wrong about its CPU, memory, or network efficiency. It might also lack delays and costly mining of Bitcoin. I leave it to you to help me there as you're probably knowledgeable about it. If they eliminated those, then I might build some extensions.
So, that's all I was saying. All... several paragraphs. I need to work on brevity as much as I did IT. Sorry about that lol.
I get that security is your thing, but don't you think that telling someone to ditch their side project and critizing the underlying technology is extreme given that it's basically a side project?
I don't think OP is suggesting that they use it for anything more serious than a quick poll at the moment.
Oh no, that's a fair critique. You could say my comment is conditional. There's two ways it may be interpreted depending on the project's intent:
1. Many projects are running with the idea that Bitcoin-style tech will change the world and let's all build on it for anything security-related. They intend to see eventual uptake of whatever they make after a certain amount of development. If it's one of those, then my critique stands fully.
2. If it's a side project for fun/exploration, then my critique becomes a precautionary note that doesn't apply to it. There's nothing wrong with making arbitrary projects for fun or learning: plenty right about that on the contrary. :)
I haven't done a thorough review of either. They just both have good traits from a design and security perspective. So, I bring them up both as examples of better path and something for further review/development/improvement.
Through Ethereum this creates a transparent voting system where anyone can audit a poll, since everything is recorded in the Blockchain. Additionally, votes cannot be altered once they are cast, ensuring the integrity of the system.
Right now this is a Proof of Concept though, more voting applications will follow.
The website is currently a single Point of Failure, since it is the gatekeeper for recording votes into the Blockchain. With this proof of concept I did not want to build a fully decentralized voting application that ensures that 1 person == 1 vote, I rather just wanted to display how Ethereum and the Blockchain can be utilized for voting. Once a vote is recorded into the Blockchain it cannot be altered anymore. The question of feasibility of this application is obviously very much up in the air.
But overall, there are some interesting concepts to protect such systems against sybil-attacks, so that we can ensure that 1 person == 1 vote any nothing more.
Just checked, seems that that account went out of Ether as there were too many votes (more than 100). Didn't expect this much traffic haha.
But to basically explain what happened, each poll has a minimum 0.2 Ether which are used for paying the network for executing the smart contract. Since more than 100 people have voted on the system, it means that the account (which holds the Ether) went out of tokens and now nobody can vote anymore.
I'm right now working on fixing this by creating a balancing system that basically creates a faucet. But feel free to create a new poll. You can send me the link here and I'll send some Ether to get you going.
Hey everyone. Anyone that wants to create a new poll and doesn't have any Ether, please just post here with your poll link and I will send some Ether to your poll so you can get started :)
Anyone can comment on its ability to scale? Not sure exactly what to ask about (I guess performance?), but do you think this could scale to say 200 million people?
