http://www.cs.cornell.edu/projects/civitas/
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.
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.
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 :)
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.
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.
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.
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.99....
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 don't think OP is suggesting that they use it for anything more serious than a quick poll at the moment.
Sorry if I'm misreading the tone of your post.
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. :)
Hope that clears it up.