Bitcoin Forum

The global decentralized secure electronic voting system is up and running, ready for you to spend .00000001 bitcoin to vote (we'll count by people, not by money, which will require a decentralized web of trust as I'll explain below), as the existing Bitcoin and optionally Bittorrent for uploading and voting on files whenever it starts working again. We get to include any 20 bytes in a Bitcoin address. Here's 1 where I put the bytes of "There Is No Spoonxxx"

These are the 3 calculation steps at http://gobittest.appspot.com/Address but this can be done automatically after we get it working manually.

5468657265204973204E6F2053706F6F6E787878

005468657265204973204E6F2053706F6F6E787878

Nonexistant but usable Bitcoin address: 18hJphGPYctV7DTmkywRMXxCYAA5xef96b

You can put money into that address, but nobody can ever take it out since nobody knows a "2 - SHA-256 hash of 1" hash that results in "There Is No Spoonxxx" (in textfield 2).

There is a 1-to-1 mapping, and easy way to transform, between all possible Bitcoin addresses and all possible Bittorrent hashcodes, and theoretically that's all you need to find it at some trackers, or whatever network of Bittorrent trackers we may create just for this.

Its done by putting any arbitrary data where the first 160 bits of the SHA256 hashcode of public key would normally go, but instead in the case of Bittorrent I put the SHA-1 hash which is 160 bits. 1 bit smaller and it wouldn't have fit, so I guess it was planned that way.

This 20 byte hash (in hex is 40 bytes), or any 20 bytes, like text encoded the UTF-8 way so it allows all symbols of all Earth languages, are mapped 1-to-1 with Bitcoin addresses, as explained here and an online tool to calculate it (put the 40 hex bytes in line 3, click, and take the address at the bottom) here http://gobittest.appspot.com/Address

You can convert between hex and string (if its a string) here:
http://string-functions.com/hex-string.aspx

Hash: 830EDF6CA03616114819E50A0BBC549280C3A90C
is the Bittorrent hash of:
"Ben F Rayfield moves aluminum foil with his mind in a clear closed box.wmv.torrent"
But since peer to peer is being censored recently, even though I connected and it said it uploaded to a few (including http://tracker.publicbt.com:80/announce and a few others), I wasn't able to download it or find it through its name or hash. You can watch it here (or search for "mind over matter - psi wheel in a clear closed box ") http://www.youtube.com/watch?v=9Ww8rI0BG9k on the centrally controlled part of the Internet instead, unless they censor it. I'm not that skilled at it anymore, but I was around year 2003 sometimes. Its a zen thing, but its just an example of what we should be able to vote on through Bittorrent and Bitcoin and URLs and if directly in the calculation of the Bitcoin address you get 20 bytes of text, but 20 bytes can say alot, especially if we agree on a standard way to huffman-compress it. We should stay away from the tinyurls since thats likely to be censored if we succeed in influencing the world with our networks of addresses and transactions and words and files and voting with the normal Bitcoin network.
Bitcoin address: 1CwyLWPQ4dbUBGVbWuPZn2ivm6ezLyjwzT


This Moneyocracy system represents how the world works, controlled by money, but we should try to fix that by using the set-theory abilities of the Bitcoin network to keep track of which Bitcoin addresses (of people) have transactions to which other addresses (of nonexistant but usable symbols to permanently put a very small amount of money in as a vote of importance).

http://blockexplorer.com/address/18hJphGPYctV7DTmkywRMXxCYAA5xef96b

"Hash160?: 5468657265204973204e6f2053706f6f6e787878"

Copy those 40 hex bytes to http://gobittest.appspot.com/Address and transform it (from line 3) to a string to get the Bitcoin address: 18hJphGPYctV7DTmkywRMXxCYAA5xef96b

Copy 5468657265204973204e6f2053706f6f6e787878 into http://string-functions.com/hex-string.aspx to get:
There Is No Spoonxxx (or transform it the other direction, it maps 1-to-1)


Really, go vote. Help build automated ways to do this. USA elections are coming up soon, and predictions of who is going to win are almost the same as who actually wins, so lets agree through this informal system who we want to win, and vote on many things like mind maps of how Wikipedia page names and politicians names and text files (if Bittorrent starts working) containing ideas relevant to those, how it all fits together. Our democracy can be fluid and decentralized and far more advanced than anything we have now. Its something I figured out in a few hours (not counting that I had already read Bitcoin's design doc and some about Bittorrent), with no changes to Bitcoin or Bittorrent needed. Think of what we could do with days or years.

I'm going to create a new Bitcoin address through the normal Bitcoin program, so it will start as an empty set. This is a way to do voting and mind mapping etc like set-theory and high-dimensional spaces. Every link has a money amount that nobody can ever spend, so it stays there representing the importance of the subject and increases the value of other bitcoins. We should count votes by people, after we create a decentralized web of trust to identify eachother by our patterns of thinking as demonstrated by the networks of sets with numbers pointing at other sets, not by id cards.

Here's the new empty set that I can add votes (numbers) to: 1MjpyfK1ajz6VJYvr8Fp5avs5nUSrtC98W

Subject, 20 bytes, use this to mean voting for the subject of some other Bitcoin address: votexxxxxxxxxxxxxxxx
Hash: 766f746578787878787878787878787878787878
Nonexistant but usable Bitcoin address: 1BoEFeGDLMj2mGV78Q8YSggH8L2tN69oMC

Subject: Ron Paulxxxxxxxxxxxx
Hash: 526f6e205061756c787878787878787878787878
Nonexistant but usable Bitcoin address: 18Wsu31yVWtTprwSit8aiawzpmR4SHRafr

Subject: Barack Obamaxxxxxxxx
Hash: 42617261636b204f62616d617878787878787878
Nonexistant but usable Bitcoin address: 173zLPDeCXQMzR5yUW2mZVsAJNVsz22mNP

Subject: Mitt Romneyxxxxxxxxx
Hash: 4d69747420526f6d6e6579787878787878787878
Nonexistant but usable Bitcoin address: 184KMuXZLfYDiNwar2DSpwWRy53HkbjuYq

Subject: My name isxxxxxxxxxx
Hash: 4d79206e616d6520697378787878787878787878
Nonexistant but usable Bitcoin address: 184e8oRuq4nnS1W6Jq2AM1ntRkvZ86UQTK

Subject: Ben F Rayfieldxxxxxx
Hash: 42656e2046205261796669656c64787878787878
Nonexistant but usable Bitcoin address: 174579taJUStXxxCTRvNGx2A6LTvVr8Pfp

Subject: certifies ident ofxx (This is how we build a decentralized web of trust)
Hash: 636572746966696573206964656e74206f667878
Nonexistant but usable Bitcoin address: 1A4ZRfCEn1LwzdGgSALcQjhjpj489PHoty

Create your own text or uploaded files. Its your choice what to vote/communicate on and how to hook it together and how to evolve these open source systems.

To those who think this could overload the Bitcoin network if too many people create too many subjects and transactions linking them together, here's something I wrote that includes ways to scale up Bitcoin https://bitcointalk.org/index.php?topic=53062.0 titled "   
MerkleWeb - statistical Godel-like secure-but-not-perfect global Turing Machine", but no software built yet, just that informal design doc as the thread and uploaded to http://sourceforge.net/projects/merkleweb Maybe somebody will continue my work? I have many projects to do first.

Nobody counts the votes. Bitcoin is a peer to peer network that counts their quantity and total money as they come in. We should make sure to not let the transaction history be deleted, since technically it can be deleted in a later version but for now older history of "votexxxxxxxxxxxxxxxx" is still at http://blockexplorer.com/address/1BoEFeGDLMj2mGV78Q8YSggH8L2tN69oMC There's the audit trail for everyone to see and build their own programs to calculate the quantity of votes and sender addresses per person (by their patterns of what their addresses associate to, or Certificate Authorities like web browsers use for example). I've done enough for now.

Think of this voting system more like http://wikipedia.org than the way governments do it. Money and businesses and paperwork and many other things get in the way of understanding who to vote for the normal way, but we can network our ideas together as weighted mind maps with this global decentralized secure voting system.

Go vote. Really, its a new way to use Bitcoin which has been working very well (not counting that time Mtgox, and not the Bitcoin network, got hacked because of their mistake in their custom software, Bitcoin is undefeated). This is relatively new, but still very secure, tecnology, an unprecedented event in Human history that the people built their own voting system. I stand on the shoulders of giants, and you can too if you build the remaining parts to count previous and later votes.


It takes 1-10 minutes for http://blockexplorer.com to count new votes (quantity of transactions, addresses, and total money, for us to count 1 per person later using intelligent software to match people 1-to-1 with parts of the network). We can't trust any 1 organization or website to count votes. The data is digitally-signed and in the peer to peer network for everyone to count. We could use some official USB sticks for identification, which we would get at the Department Of Motor Vehicles with the normal ID, if this becomes more than an informal election system. Its for all 7 billion people in whatever they want to vote or communicate about, free and open source except for less than a penny per action in the network. Don't forget to give a penny of voluntary "transaction fee" (in the Bitcoin options) so your transaction will be processed faster and more reliably.

Secure voting is now open source, with some unprecedented new abilities like social networking (if your Bitcoin address is associated with your name somehow) and optional file uploads and weighted mind mapping.


----Part of the Audit Trail----


http://blockexplorer.com/address/1BoEFeGDLMj2mGV78Q8YSggH8L2tN69oMC

Address 1BoEFeGDLMj2mGV78Q8YSggH8L2tN69oMC
Short link: http://blockexplorer.com/a/5VKCmZBEfy

    First seen?: Block 162833 (2012-01-19 03:27:18)
    Received transactions: 1
    Received BTC: 0.01
    Sent transactions: 0
    Sent BTC: 0
    Hash160?: 766f746578787878787878787878787878787878
    Public key?:
    Unknown (not seen yet)

Ledger?

Note: While the last "balance" is the accurate number of bitcoins available to this address, it is likely not the balance available to this person. Every time a transaction is sent, some bitcoins are usually sent back to yourself at a new address (not included in the Bitcoin UI), which makes the balance of a single address misleading. See the wiki for more info on transactions.
Transaction?   Block?   Amount?   Type?   From/To?   Balance?
d1c2aaf56f...    Block 162833 (2012-01-19 03:27:18)    0.01    Received: Address    

    15zi5XqWyLdkz72Y4iiGqAxkeCsKc6ciHV

   0.01



http://blockexplorer.com/address/18Wsu31yVWtTprwSit8aiawzpmR4SHRafr


Address 18Wsu31yVWtTprwSit8aiawzpmR4SHRafr
Short link: http://blockexplorer.com/a/48BtjFieqS

    First seen?: Block 162834 (2012-01-19 03:44:34)
    Received transactions: 1
    Received BTC: 0.01
    Sent transactions: 0
    Sent BTC: 0
    Hash160?: 526f6e205061756c787878787878787878787878
    Public key?:
    Unknown (not seen yet)

Ledger?

Note: While the last "balance" is the accurate number of bitcoins available to this address, it is likely not the balance available to this person. Every time a transaction is sent, some bitcoins are usually sent back to yourself at a new address (not included in the Bitcoin UI), which makes the balance of a single address misleading. See the wiki for more info on transactions.
Transaction?   Block?   Amount?   Type?   From/To?   Balance?
0bc57fc687...    Block 162834 (2012-01-19 03:44:34)    0.01    Received: Address    

    1BaM4mL487BZhbwdfaR7wovUwGmE2orsuU

   0.01
Bitcoin Block Explorer (MtGox Live mirror) - Donate: 1Cvvr8AsCfbbVQ2xoWiFD1Gb2VRbGsEf28

------


Just to make sure, put 526f6e205061756c787878787878787878787878 into http://string-functions.com/hex-string.aspx and get this:

Ron Paulxxxxxxxxxxxx

Ron Paul is also what tends to result from what I described here (but the election could go any of those 3 ways or possibly a 4th party): http://kurzweilai.net/forums/topic/global-decentralization-process

Vote through Bitcoin and/or Bittorrent, and maybe implementing the TruthValue C++ object in the OpenCog artificial intelligence metaframework would be a good plugin, able to predict stocks and global events that way. Many possibilities. The future is ours to create.

If you want to give someone bitcoins, make sure to ask them their preferred address first, since this way of using bitcoin addresses uses them like creating new empty sets instead of a wallet, but its not abusing Bitcoin because the free market of transaction fees will handle it, and if necessary there are MerkleWeb design docs explaining how to scale up the next version.

You would probably have to link the vote to dna because you can see someone voted from a node but bitcoin cant possibly tell WHO voted. Bitcoin doesnt have facial recognition either.

Since its based on connecting different systems through secure-hashes, as they refer to eachothers data, its compatible with most kinds of identification if people buy or government gives such hardware.

But first we need some people to try it as it is and figure out what other difficulties there may be. I'm confident that all the other problems that come up will be much easier to solve than identification. It can be solved without DNA or any kind of hardware identification if we create the patterns of the data to include a "web of trust" (as I wrote above), but people would need to understand what a web of trust is. Its similar to networks of friends. You don't check the id of a new person who 3 of your friends introduce to you by the same name each time, since you trust them to give you the right name, and then that new person can help identify more people with your existing friends as the web of trust grows in many overlapping ways. We can do it completely through social networking.

There is alot of value in using it as a weighted mind map. Maybe we should introduce it from that angle first?

Here's some examples of mind maps: http://webbrain.com But they're not nearly as advanced as mind maps through Bitcoin and/or Bittorrent because they don't overlap eachother and converge on what people agree on like Wikipedia, because they're not cryptocurrency-weighted or weighted at all, and because they're not in a global namespace like Bitcoin is and Bittorrent used to be and will be again.

whoah, so is this currently just a proof of concept or do you have plans to implement this somewhere soon?

Technically its already implemented, and I used it as demonstrated by the transactions to those nonexistant addresses (used as constant symbols).

I'll create a small software to do the calculations described, at http://sourceforge.net/projects/jmoneyocracy

For now I think its best to let people copy/paste between JMoneyocracy and the existing Bitcoin programs and optionally Bittorrent. Direct integration at the program level is not needed and would reduce trust.

This can be done right now, and based on the following things I wrote and other observations of the world, I expect the world is moving toward these ideas and it will soon spread like a viral youtube video.

This I wrote 7 months ago. I continued looking into why global events happen and it led to me creating this new way to use Bitcoin to organize the world.
"A Compromise To Avoid World War 3"
https://bitcointalk.org/index.php?topic=23054.0

http://kurzweilai.net/forums/topic/global-decentralization-process

http://kurzweilai.net/forums/topic/we-evolve-evolution

"Meta Paradigm Shift"
https://bitcointalk.org/index.php?topic=27624.0

Please take this seriously. I may be wrong about exactly when these ideas will lead to this exponentially increasing use of Bitcoin (or possibly new similar programs), but I know it will happen.

I created this thread to explain the danger to the Bitcoin network and what needs to be done so it all goes smoothly.
"WARNING Transactions and Addresses will soon be used as high volume data storage"
https://bitcointalk.org/index.php?topic=60386.0

Using the current bitcoin network?

This should get top priority to promote to the OWS movement. Its one of the best ideas to come out of the Bitcoin community. Thanks for reposting. I don't know how I missed this before. Sometimes saying things a little differently gets the point across.

what about spamming the blockchain?

wouldn't be better to use an altchain only for this with merged mining?

I think this idea is something worth looking into more (although I don't know if Bitcoin itself should be used rather than an alternative block chain).

The most important problem to be solved as I see it is this:

How can individuals protect their identity whilst at the same time only getting 1 vote?


Cheers,

Ian.

Here is an article related to using Bitcoin approach in electronic election system:
http://www.newscientist.com/article/mg21328476.500-bitcoin-online-currency-gets-new-job-in-web-security.html
They call it CommitCoin, not sure if it is alternative chain or something on top of Bitcoin network.

Wow - thanks for that link - looks like Bitcoin might well change the world in a lot more ways than at least I could have ever imagined.


Cheers,

Ian.

It's great to hear from someone who has that Bitcoin epiphany. Someone should coin a word for that.

Why can't votes be sent to bitcoin public address 1VoteForPedroxxxxxxx  (whatever base 58 allows and checksum)?

Am pretty sure that's what Ben had shown, however, the real problem is ensuring 1 person = 1 vote and that each vote is kept secret.


Cheers,

Ian.

I think BenRayfield is not a human (clearly, no human could come up with the stuff he posts).

BenRayfield must be a subroutine of that global turing machine, gaja cortex or whatever, I don't know.

BenRayfield for president!

That's already in the code.  :D

It is build on top of Bitcoin.
Paper: http://people.scs.carleton.ca/~clark/papers/2012_fc.pdf (http://people.scs.carleton.ca/~clark/papers/2012_fc.pdf)
Discussion: https://bitcointalk.org/index.php?topic=59956.0;all (https://bitcointalk.org/index.php?topic=59956.0;all)

Why didn't you use your own blockchain instead of spamming bitcoins blockchain?

I don't think this works.  0.0000001 BTC is meaningless, effectively every transaction costs at least 0.005 these days.  This is a lot more expensive than you think, and the implementation will be so convoluted I doubt it will catch on.

You have a giant gaping hole: either you let people directly vote with BTC (10btc is 10x the voting power of 1BTC), or you censor a huge number of people by guessing which addresses are connected with each other.  It is better to start from scratch.

PS: Seeing as how you claim to be able to move things with your mind, there should be much better uses of your time than this.
http://www.youtube.com/watch?v=9Ww8rI0BG9k

But by all means, try!  I'm happy to pocket the extra transaction fees. :P

I wish I could do this!!

Does this use something like this?

http://en.wikipedia.org/wiki/Homomorphic_encryption

I also think that a parallel chain and merged mining will probably be a better answer.

I don't see how you prevent double voting (you say web of trust but I think that can be cheated).
You need a centralized id system, but anyway this is cool.

I still don't see how you map the id key to the voting key anonymously.

But maybe you've explained it all in your long post. You should summarize it.

The following approach (as far as I can tell) should work and requires little more than a modified Bitcoin client to achieve:

- each "vote" contains an encrypted message (that only the party and the organisers can unlock) then only if this message has the right value is it considered an actual vote (this permits voters to send one or more dummy votes along with their real vote)

- to be eligible to vote you must first have sent someone else's vote to the nominated party (this is verified by having the party send a receipt to the final sender) certain specific voters (party members) would be sent their receipts in advance in order to create initial eligible voters (not really an issue to know that party members will vote for their own party)

- if a vote is received from an eligible voter then randomly decide whether to deliver it or relay it (if the voter is not yet eligable then just relay it)

- to vote send your actual vote and at least one dummy vote to several other voters who are not yet eligible

- once you have voted you need to wait (and continue to relay other votes) until your receipt confirms 6 times


Cheers,

Ian.

Here is my understanding of how this will work.
1. Print a ballot with a unique (on every ballot) address for each candidate. This means every candidate has many addresses.
2. Randomly hand out ballots to registered voters in each district. This makes it anonymous.
3. Send the minimum bitcoin to each address you vote for. (I'm not going to worry about buying votes, there are many ways to handle that.)
4. Count the number of addresses that receive value for each candidate, not the value amount.
5. The voting can be done from home. Paper ballots can be used to audit the election in each community.

Well maybe there is a flaw in what I have proposed but in my system you need no paper and can be audited 100% from the blockchain.

The anonymity is achieved by the fact that you never cast your own vote and that also you vote more than once (where other votes are "dummy" votes).


Cheers,

Ian.

But the party registering the voting addresses (associating addresses to registered voters) can know exactly what each voter voted.
Am I missing something?

If you check the method that I described you'll see that it makes it impossible for anyone to know who voted for who.


Cheers,

Ian.

Step two would randomize the ballots so the ballot with the adresses would not be assigned to a particular voter, but to any one of the registered voters in a district. The only way to track who voted for whom is to track the bitcoin adresses to IPs like any other bitcoin transaction.


[edit] Paper ballots are very important. Ask any American stuck with voting on a Diebold system.

@CIYAM Pty. Ltd.

Sorry, I don't see an equivalent of cbeast's step 2 in your proposal.
Also...
Then only the organizers can decrypt the votes and sum them, right?
Where's the decentralization then?

@cbeast

Can you explain the step 2 in more detail?
How can you give an address to each registered voter in the district without knowing what address your gave to each voter?
Also, how can you generate addresses without knowing the private key?

The anonymity in my approach is created by the fact that you don't actually cast your own vote - you cast a vote from someone else. When you receive another voters vote you also randomly decide whether to cast it or forward it (although in forwarding you might swap the contents for you own vote).


Actually as each vote requires a receipt anyone can count all the votes (they just can't tell who voted for who).


Cheers,

Ian.

How is it decided who sends who's vote?
How do you ensure that my vote is not  sent by two participants?


What's the receipt here and what does it contains?

The receipt is a payment (value not being important here) made by the "party" to the "casting" voter (although that vote won't be their own). It doesn't actually need to contain anything - it just used by the party and organizers to verify the delivery of a valid vote.

This ensures that that you have cast a valid vote (that is in fact another voters vote). Until you've cast a valid vote you cannot have your own vote cast (thus the need to seed the system with a few non-anonymous votes presumably by party members).


Cheers,

Ian.

With all respect, I think your system is not defined with enough detail. If you describe the process sequentially with enough detail you will see it's flawed.

Two candidates A and B
1) User c with addC commits A's vote for A.
  How the organization decides that is c (and not another voter) the one who has to commit that vote?
  How the organization knows addC belongs to c?
2) Now user c can vote. He sends his vote to d (who will know his vote, by the way) for d to commit it.
  How c knows that he has to send his vote to d and not, for example e?
  How does the system warranties that d doesn't change c's vote before committing it?

If the sequencing between voters is public and the votes themselves are public, everything is public.
If the votes aren't public and the organizers must sum the votes, the system is not decentralized.
If the votes are public but the sequencing between voters isn't, how does it works?

Everybody must be able to sum the votes independently for the system to be decentralized.
The mapping between the persons and the voting addresses must be blinded somehow for the system to be anonymous.

I recommend you to read the document I linked above.

You may be correct but I think I can explain the two points you have raised.

First point is that the organization doesn't decide who commits the vote - that is effectively a random decision. The organization doesn't need (nor would you want them to know) that it was A's vote but only that a valid vote was received by the party.


The ballot would be encrypted with a secret batch key (known only to each party and to the organizers with there being perhaps 1 of a possible fairly low percentage of the total number of registered voters) so there is is only a fairly low percentage of chance (the percentage chosen) that you can decrypt a vote, however, if you make sure that the user you first send your vote to does not belong to your own batch (by having a non-encrypted batch # that all can see) then subsequent users might be able to decrypt the vote but they now would not know whose vote it was (as your identity has disappeared during the relay).

To prevent tampering the rule would be that a vote submitted to a party that belongs to the same batch # as the user sending it would be relayed back to its sender (I guess this might be a slight flaw in that the small percentage of chance you have of receiving a ballot from another user from the same batch could give you an opportunity to change that vote).


Each ballot (whether the initial one sent to the user, one relayed between users or the final one delivered as a vote) would be public key encrypted to the destination user and the actual vote is encrypted with the batch key so no nothing is public apart the fact the tx's were sent between users.


The receipts provide the final way that anyone can count the votes. The role of the organizer is to simply verify that the parties have only created receipts for valid votes (by checking each vote with the secret batch key).

I am not sure whether or not I have nailed it yet but hopefully these points will convince you that my approach is not completely flawed.


Cheers,

Ian.

Simple. It's exactly the same way a merchant creates a unique address for every purchase. Every ballot is like a menu with all unique addresses for every candidate. The private key issue is a problem that could be addressed by separating powers and having the public keys assigned to candidates by an independent third party. After the election, the holder of the private keys can move the voting funds back to the local communities coffers or some other public trust.

Actually it is not so much that you can decrypt a vote (as the voters should not know the batch key) but there is the small percentage of possibility that you can match the encrypted ballot against one that had been sent to you by another user from the same batch.

Perhaps the easiest rule to avoid this occurring is that you must always relay to someone from a newer batch (although that would introduce a problem in working out how to process the ballots from the last batch).


Cheers,

Ian.

The following is a possible workflow for my approach.

Consider three voters (A,B and C) each belonging to a different "batch" with both A and B having exactly two votes (one real and one dummy) and C only having one (being a member of the final batch of "party members" that don't need anonymous votes):

A (A1 A2)
B (B1 B2)
C (C)

Now consider the following:

A sends A1 to B (accepted as A is in the first batch)
A sends A2 to B (accepted as A is in the first batch)
B relays A1 to C (accepted as A1 came from the first batch)
B delivers A2 and then sends B1 to C
C delivers A1 (as B has delivered one vote) and then sends C1 to B
B delivers C1 (as C has delivered one vote) and then sends B2 to A
C delivers B1 (as B has delivered two votes)
A delivers B2 (as B has delivered two votes)

So finally the votes were delivered as such:

A (B2)
B (A2 C)
C (A1 B1)

But if B had instead delivered A1 and relayed A2 then the result would be:
A (B2)
B (A1 C)
C (A2 B1)

Also if B had instead sent B2 to C and B1 to A then the result would be:
A (B1)
B (A1 C)
C (A2 B2)

And of course if B stuck to the original relaying of A1 then the result would be:
A (B1)
B (A2 C)
C (A1 B2)

So from this we can tell that A delivered a vote from B (but we don't know whether it was the real vote or a dummy) and we can tell that B delivered a vote from C (who being in the final batch doesn't need anonymity). We can also tell that B delivered a vote from A (but not which one) and that C delivered a vote from both A and B (but not which ones).


Cheers,

Ian.

Where are the signatures?

I don't quite follow what you mean - the ballots themselves are not individually signed as then it would not be a blind ballot. The ballots are, however, encrypted by a "batch" key (which is not known to the voters) so that they cannot be altered without it being discovered by the organizers/parties (this is why it would be necessary to only pass on ballots to voters from a different batch to your own).

The transactions form the proof that ballots were passed between voters and eventually were delivered to their intended parties.

So nobody but the organizers (or software that they run) know all the keys and can sum the votes, right?
If that's the case, your solution is not decentralized.

For sure the approach I am suggesting does require "organizers" as this is necessary in order to keep the batch keys secret (to prevent people knowing about each others vote).

The votes themselves (but not their owners) are actually transparent though as each vote had to have been correctly cast in order for a "receipt" to be issued for it (that what the secret batch keys are for). Effectively its a zero sum game.

The tally is itself visible to everyone and the "balance" of BTC (or lets just call it VTC) should show that the election was fairly run (each voter got x VTC and it was spent on legit votes as shown by the issuing of receipts).

The organizers cannot cheat the system as otherwise anyone could detect the missing votes (as being missing money).


Cheers,

Ian.

If they're the only ones counting the votes, they definitely can cheat the system.
They receive all the votes, throw 'em to trash and say "the result is A 20 votes, B 10 votes".

For the system to be decentralized, every participant should be able to verify the counting.
Please, read the pdf I linked. I think you're underestimating the problem at hand.

Absolutely. I think it's important to be able to audit the final tallies. After all, the POTUS in 2000 would have been different.

The organizers are definitely not the only ones counting as each and every party also verfies that each and every vote is valid and in fact after the poll is completed the secret keys themselves could be released (if not to the public then at least to a 3rd party) so that they can confirm the vote payloads that were all correctly decrypted.

For the organizers to trash the votes and make the results up would require all the parties to agree to it. If you have a political system that corrupted already then I don't think you'd even be having a vote in the first place (it would be called martial law).


Cheers,

Ian.

As said, this is not a decentralized voting system. Why use a block chain at all? Just a server run by the organizers that makes the encrypted votes public so that the voters can validate the valid votes. And then trust the organizers and the third party. Also, there's no anonymity, because the organizers (and the third party) know what each voter has voted.

The system I want has the following properties:
1) Everyone can count the votes.
2) No one can know what other participants have voted.

Well achieving what you want may not actually be possible but saying that the votes are not anonymous in my approach is just completely wrong - if you want to seriously criticise something please take the time to give the proof (I bothered to take the time to give you a workflow after you said I couldn't).


Cheers,

Ian.

Maybe I misunderstood something in your workflow, but can't the organizers know what everybody voted for?

Maybe you're right in your claim that achieving what I want is impossible, but is the aim of the pdf a linked and (Ben correct me if I'm wrong) what this thread claims to have achieved.

The workflow shows that they see every vote *but* they do not know which vote comes from which voter as the votes were secretly shuffled between the voters before being sent to their voting destination. So it *is* anonymous.


Cheers,

Ian.

Say we want to elect the major of my town.
We have a pool of voters V = {v1, v2, ... v100000}
The organization generates a set of keys K = {k1, k2, ... k100000} and give them to the voters.
The organization knows the mapping between V and K so it knows what every participant has voted.
The dummy votes and the relays just may hide the IP addresses of the voters, but that could have just be made suing Tor or i2p. It doesn't makes sense because the organizers know the voeters NIF.
If you want the organization to not know what every participant has voted, they cannot know the mapping between V and K.
If you can do that, I would suggest that instead of keys for a symmetric encryption algorithm, the organizers distributed privates keys of an asymmetric one and published all the valid public keys. That way voters could sign their vote and everybody could verify the results.
But...
Where does "secret shuffling" algorithm run? How does it work so that the owner of that computer can't know the resulting mapping?

I never wrote that you have n secret keys for n voters - I wrote that you have n / x secret keys so that your vote could only be identified as being "one of n / x". I used the term batch to describe n / x and a public batch # would also be assigned to each user. This # is visible to all other users so that you make sure you pick a user *not* from the same batch to send your vote to.

There is no 1 to 1 mapping - can you understand it yet?
 
(if you get this part then I can re-explain the rest again - if you don't get this part then I don't see the point in further discussion)


Cheers,

Ian.

Ok, so there's n keys and x voters.
How do you map the n keys to the x voters?
I think this shuffling algorithm runs on the organizers server so they will know the mappings between k(i) -> v(j). The key i belongs to the voter j.

Yes, this is the part I need to understand first. I don't really understand what you mean by batch here. A set of keys for each voter?
I don't see the point if the organizers know who owns each key.

There are not x voters and n keys - there are n voters and n / x keys. So there are less keys than voters. See?

I still don't see the point. Can you answer my questions below?

I don't really understand what you mean by batch here. A set of keys for each voter?
How do you map the n / x keys to the n voters?

I would be VERY HAPPY if there was a system for decentralized voting. I would mail the Gerald Celente's "direct democracy" and spanish's "Democracia real ya" (real democracy now) crew and all, but I still see it NOT_FEASIBLE.
I expect a surprise on this technical issue nontheless, but sorry, your proposal doesn't seem to meet the constraints.

I will read Ben's proposal when he learns how to write less than, say, ten lines. I have an hypothesis but not the time to make it become a proper theory: "It is impossible to go offtopic on a thread started by BenRayfield, even if your talk about the wheather or the sex of snails". He has covered it. Hi Ben, in case you read the threads you start.

It seems to be a really difficult thing for me to explain this to you - but as I'm still relatively new I'll do my best.

There are *less* keys (much less) than votes so that the votes *cannot* be mapped 1 to 1 (otherwise of course you would not have anonymity).

So lets say we have 1000 voters and we've decided to use 10 secret keys. Thus one secret key is shared by 100 voters.

In order for those voters to avoid sending their vote to another voter using the same secret key we label each group of 100 (which I termed a batch) with a simple # (i.e. batch 1..10 in this case as there are 10 secret keys). This batch label is *not* encrypted so that a voter makes sure they will pass on their vote to someone that belongs to a different batch.

Are you with me so far?

Ok, now I get it. The organization knows the key it gives to each voter and knows the 100 votes but not what voter has issued what vote.
In your example, if 60 vote to A and 40 to B, they don't know what each of these v1...v100 have voted as long as they don't vote all the same.

Next question.
How double voting is prevented?
v1 sends one vote for A and 2 votes for B. How the system knows that the second and third votes are invalid and don't belong to, say, v2 and v3?

Okay - good to get past that hurdle.

Your next question is where the actual blockchain comes in. Although the votes themselves are a payload - they are contained (or referenced) by a transaction (we now have the block chain to stop a double spend as it does in Bitcoin). You only have x amount of money to spend (which you are given by the organizers).

I envisage that for this type of system all coin would (if belonging to an alt chain) be pre-mined and the exact amount of coin available to the voters therefore being fixed (other ways might be to only allow vanity prefixed coins mined before a certain block to be able to be used for voting if not using a vote specific block chain).

If you are fine with this then we can review the workflow idea I put forward to make the process itself work.

Sorry for taking so long to understand you.


I have to send my address to the organizers for them to send me the voting coins, they know my address when I submit my vote.
It seems to me that this destroys anonymity.

But you won't be sending your own vote. :)

Your vote is sent on to a user from the next batch whose own votes are encrypted differently to those of your block and so who cannot work out who your vote is actually for (the ballot itself is the payload here not the money). To avoid a member of the next batch being able to easily work out what is what I think that each voter would actually randomly pick (from a group of say 100) a real or dummy vote for each party plus one that looks like a vote for a party (randomly placed within) that is actually some sort of UUID generated by each voter so that they will be able to check that their vote was indeed submitted (this would be included in the *receipt* which is of course sent to another user).

The approach for shuffling is a fairly simple one - eventually we want each member of each block to send another persons ballot. But as we randomly choose which members of the following batch to send the ballots to it is obvious that numerous members will be sent more than one ballot. Therefore when you receive multiple ballots you randomly send one as a vote and forward the other ballots to other members of your same batch (who you can tell have not already got ballots as their balance will just be the initial voting balance).

Still with me?

This thread is making my brain implode. I'm trying to understand the workflow. :-\


Decentralized voting is like the DNA to Bitcoin's RNA. Bitcoin will be the engine, (insert name for Decentralized Voting) will be the helm.

Not sure. If I send my vote multiple times what prevents other users to submit my vote more than once?

To submit a vote you must send your tx (and ballot payload) to a member of the following batch (with the tx having the correct amount).

No member of the following batch will send your ballot unless they can see that you have already previously submitted another's ballot (which has to be from a previous batch as each batch cannot submit ballots that originate from their fellow batch members). This is verified by checking that the user has got a receipt from the organizers (the receipt being for a valid ballot that didn't belong to your batch).

Once you have a receipt no-one from your own (or any other) batch should attempt to send you another ballot (so you can't get any more money) and no-one will deliver your ballot until your balance is only the amount of the receipt (perhaps the timing might be handled according to block #'s). The organizers will not accept a second ballot being submitted from any one user so I think this should do it.

I haven't really gone through in great detail how to be 100% sure you can't possibly "sneak something past the cracks" but I think if one or more confirmations are applied to determine the current "state" of a voter then such cheating should not be possible (at least not without significant collusion amongst voters who after all won't know who each other are).

I don't know, it may work.

Here's a recent thesis on decentralized voting. I haven't read it yet (is long), but looks really interesting.

http://uwspace.uwaterloo.ca/handle/10012/5992

Should we start a bounty?

In another thread one of the authors of Commitcoin mentioned about Scantegrity so will find some time to read up on this in the next couple of weeks.

I got the idea from his comments that such systems are already (have already?) been constructed so probably no need for any bounty as I suspect the software will be out there soon (although I don't know if it will be open source).

If Scantegrity it is not open source then you might run into some IP issues copying his approach. Assuming my technique is not the same (and I assume that it is not from the comments I read) then certainly it could be used.

Although this is an interesting intellectual excecise I do wonder whether Bitcoin itself is an appropriate vehicle as the # of tx's hitting the blockchain would rather dramatically increase if elections involoving multi-millions of votes were to be conducted in this manner. At the same time an alt chain might easily be 51% attacked (presumably by the government running the election) so that also is a problem.

Well, that would be a problem Maybe some places without software patents can use it. As far as I know, there's no software patents in europe yet, but I'm not a lawyer, don't take my word on this.


Merged mining to the rescue?

Am not really up on the subtle details of merged mining but I think that the issue of dealing with millions of tx's per day is something that Bitcoin will have to be able to handle well if it is ever to go up against any of the big payment processors.

Merged mining allows miners to use the same hashing power for mining various chains simultaneously . It's a good way to increase the difficulty of an alternative chain.

http://dot-bit.org/Merged_Mining

Yes I guess that merged mining could be a part of the solution.

BTW was thinking a bit more about the encryption of ballots (and the prevention of voter collusion) and was wondering if a private key were to be made public then perhaps it could be used to encrypt each and every vote (coupled with the pubkey of the party or organizer).

As everyone would be using the same "published" private key you would get anonymity but (unless my understanding is incorrect) only the party/organizer would be able to decrypt the ballots.

Yes, that would work but that completely removes the possibility of voters validating the results (and not only the organizers). You don't think that's important but I do.

On the contrary in a previous post I mentioned that each user would put a unique key (a UUID for example) in their encrypted ballot which would then be included in the "receipt" tx (as payload). In this way each user can verify that their own vote was correctly delivered to their party of choice (by another user).

Also with the receipt tx's the tally is available for all to check. And as mentioned way back the BTC (or VTC) balances should be a zero sum to prove that all votes were correctly processed.

I think this is really very close to what you are wanting to achieve with perhaps only the shuffling approach needing a little more attention for complete satisfaction. :)

Yes, yes. You can verify that all the votes have been correctly delivered.
What I want is each voter to be able to verify the counting.
The organizers can still receive all the votes, ignore them and report the result they want, can't they?

If they did that you don't think all the users would report that they didn't find their votes?

Once again each voter places a UUID in their ballot which needs to be put in the receipt tx payload. You scan all the receipt tx's (as you won't know who delivered your vote) until you find your UUID.

If you don't find your UUID or if that vote is not what you voted for you scream FRAUD.

Still think the organizers can just make up the results?

I get it. All the votes are public and with a UUID that only the voter (and the voter that committed your vote) knows. So let's summarize your method.

1) The organizers send 1 voteCoin to each voter. This prevents double-voting.

2) Every voter, with his own voteCoin submits the vote of another voter.

3) The votes are public for all people to see and calculate results. This prevents fraud.

But you have to explain me the step 2 again. I thought the votes were encrypted with a key that only the organizers knew.

Okay - nearly there.

1) The UUID would be encrypted along with the rest of the ballot so the user submitting your vote cannot see it. This number will only be known to the organizer/parties and to yourself (with the organizer/parties not having any way to trace that number to the voter as it is only used by the voter to later find their vote - in fact after verifying your vote receipt you can destroy that UUID so no-one can determine who you voted for later on).

2) Yes the votes are encrypted so that only the organizer/parties (which would be all parties not just the one you are voting for) know initially who you voted for. It is the receipt tx that then contains the same vote in plain text along with the UUID.

So the votes do end up being public and unencrypted and each voter can verify their own vote (you just can't verfiy other users vote unless they want to tell you there UUID). Also the total BTC/VTC of receipts should equal the total BTC/VTC that was sent out to registered voters who voted (am not really considering non-voters as I think an automatic dummy vote could accomplish that).

The point of the ballot (and UUID) encryption is to prevent the users colluding with each other to try and cheat the system. The workflow I showed earlier basically says that you don't qualify to have your own vote submitted until you have submitted a vote for someone else. The idea being that it is in your interest to help out with making the ballots anonymous.

Can anyone make the counting or only the organization?

As I've stated before for every registered voter there is a tx for them to spend (their vote) and every receipt (which holds the vote in plain text) is a tx of the same amount (their vote again - but cannot be linked to the initial one except by the UUID known to the user).

Anyone can count them - just not while they are encrypted (if you don't encrypt them then users, organizers or parties could collude to screw the whole thing up).

Encrypting the ballots is not a problem though because if the organizers/parties cheat then either the balances will not zero sum (which all other parties will also know) and/or the UUIDs will not match (which each user can verify their own vote was correctly processed).