@ erikpukinskis

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.