> 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 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.