nathanielhourt
commented
8 years ago Unfortunately, I don't understand what you're proposing. I'm not sure how to read the notation you're using, i.e. * 96Hn21UeQf 1. You say "*" is the subject address... What is the subject? And what is the main address? What does "1 being what is in every subject" mean? I might be just being dense, so please bear with me. :]
If I had my guess, you're approaching this from a bitcoiny mindset, which makes it difficult to think about how the system should be implemented, as bitcoin has no meaningful data storage capabilities (the closest thing is OP_RETURN, which is a pain to use in practice). It's possible to do voting on Bitcoin, of course, but it's much easier to think of how to implement a voting system on a blockchain with real data storage capabilities, such as Bitshares. Implementing a suitable data layer on Bitcoin then becomes a separate problem (which other projects, like factom, are already tackling).
On Bitshares (and other Graphene-based chains), data transactions can be published which reference an account who published them (that account must sign the transaction) and contain arbitrary data which can be catalogued by any server that understands it. In this way, third party apps can use Bitshares as their storage backend. Our system uses Bitshares (currently; other chains can be added in the future) to store contests and votes on those contests.
The design of our system thus far is that FMV runs a server that tracks voting data on the chain (see the GrapheneBackend subproject for that server's code). Clients query that server for the list of transactions that contain active contests, and look up the relevant data from the chain. They can then publish votes on those contests, and the server will tally those votes and provide the results to any client which requests them, along with a full list of votes factored into those results as necessary. The easiest way to audit a contest's results is to build and run the server yourself and verify that the results it reports match those our server reports.
Does that make sense? Can you help me understand your idea, perhaps by contrasting it with the system I've just described?
sloanonlinux
So let's say someone is given the right to vote in the blockchain. They are given the private key to an address containing 1 vote unit for nearly infinite subjects, which might look like this:
"*" being the subject address (which every one possible is unused) and 96Hn21UeQf being the main address, and 1 being what is in every subject.
If this new voter had to give his photo ID, do a quiz, sell his soul to the devil and come out of the closet in order to become a voter, he may anonymize himself by transfering the votes out of that address while the network censors the first address.Hmm, might allow faking?And now the votes are starting! First one is Trump vs Hillary!
1st address is subject, 2nd is mathematically garanteed not to be controlled by anybody (no private key possible) 3rd might just be words on a website (Vote for trump!! 5PmvgaBA8F NTagf1qqvQ
reader checks 5PmvgaBA8F on followmyblockchain.info and votes for hillary insteadcan't tell what votes are available on blockchain like this)Voter votes for trump: From: 5PmvgaBA8F 96Hn21UeQf To: 5PmvgaBA8F NTagf1qqvQ 1 vote
Voter now cannot vote for Hillary unless this election is repeated at another subject address. His account now reads:
Meaning that his 5PmvgaBA8F account is empty.
What do you think?
PS: This system would not work well with the standard verification technique of fees&mining.