Currently the system handles votes through an IP-based system, meaning 1 IP == 1 Vote. If you have already voted on a poll you will be automatically redirected to /voted and won't be able to vote again.

The issue I have with this current implementation is that it doesn't solve the sybil attack problem, since the barrier to cheat the system is still too low for an attacker. Proxies, VPN's, etc. make it super easy to change ones IP, and thus being able to vote again and influence the out come of a poll.

I think that the only true solution to this is a decentralized identity system that solves the sybil attack problem by design, but currently there is no such system in existence (or even in development). So what do you guys think, what is a better solution to the current IP-based restriction system?

Currently the system renders a template (e.g. vote), even though the user should be automatically redirected to voted, since the user has already cast a vote. Need to improve the system so it reflects this logic. Right now it feels a bit clunky.

Bug Report

Description

When creating a poll, the scenario that the transaction to activate the poll is revoked due to chain reorganization is not considered.
When the transaction is executed but then revoked, the record in MongoDB will mark it as active while it is actually not activated on the blockchain.

Reproduce Steps

1. send transaction to create poll
2. When the transaction is executed, it shows in the UI.
3. Let blockchain reorganize by importing a side chain
4. The transaction is revoked and returns to transaction pool.
5. The poll is still active on UI.

Expected Behaviour

If the transactions revoked by chain reorganization, the created poll should also be removed.

In the current system, the server is checking every 3 minutes if Ethereum addresses associated with specific polls have a certain amount of Ether or not. This is a setInterval function in Meteor.

Is there a more efficient way to set this up?

In order to create a more decentralized system, I think it would be good to integrate OpenVotes with IPFS to store, or at least backup, poll information. It should be noted that only public polls should be stored unencrypted on IPFS, for private polls we can encrypt them.

In the current system design, the client has to initiate the poll. The way it works is basically that the server is there to watch if a specific Ethereum address associated with a poll has a minimum balance, if the account matches that criteria (because the creator of the poll sent some Ether to the address), a new button will appear on the poll page requesting the user to make the poll live. This button basically initiates the poll contract on the Ethereum network.

My question is: Should we change it so that the server automatically initiates the transaction for the poll contract once a minimum balance criteria has been met, or should we keep the system as is, where the client initiates the contract? The only reason to go for the system where the server initiates the poll is to reduce the steps required for setting up the poll and automating the system. This way the poll creator will not have to worry about anything once he/she sent the Ether to the specified address.

What do you think?

In order to reduce costs of setting up polls, we need to setup a faucet. Every time a poll is ended, the leftovers from the Ethereum Account should be sent to a faucet account which is then used to reduce costs globally on all polls. i.e. a balanced accounting system. Additionally, if for example an account ran out of funds (because the poll was for example really popular with lots of votes), the faucet account can jump in and ensure that the poll can continue to run.

Detailed description about the system coming soon.

Make it possible for Slack users to easily start a new poll in a similar fashion to https://www.getsubcurrent.com

Add a button on the poll page that makes it possible for the user to track the Ethereum addresses balance client-side. What this means is that the user does not have to wait for a full 3-minute cycle of the server to check the Ethereum addresses balance, but instead can do it herself after having made the transaction. This makes it faster to get a pull go live.

Create an API, so that website owners can easily post polls on their website and users can participate in the voting process by simply clicking on their desired choice without being required to go to the OpenVotes website.

https://github.com/pipermerriam/ethereum-alarm-clock

Bug Report

Description

When voting on a poll, the vote is validated immediately when the transaction is sent, but at this time the vote transaction is not executed.

Reproduce Steps

1. send transaction to vote on poll
2. don't start mining
3. the vote has already taken effect even the transaction is not executed.

Expected Behaviour

The vote should only count when the transaction is executed