Hmmm, maybe in such a case - where you don’t need super high precision (as in: “You can vote for 24h, until midnight”) - we could just accept that if you enter your vote so late that it doesn’t reach enough notaries before the deadline, you are out of luck.
Then one could simply design the UI to only accept a vote (and show the countdown accordingly) up to one minute prior to the deadline. This would give Holochain a full minute to verify the transaction.
What I am trying to say is: In many cases we might not have to solve the problem and instead just avoid it.
I think I have an answer that could work quite well.
Part of the problem is that you usually want the vote to be cast anonymous, yet the results verified and trustworthy.
Maybe I was thinking that each vote would be an entry on the dht, which would create the problem with the global state of the outcome. But what if the answer of the question we are voting on is actually the entry. And each vote is just a participants signature. Then everyone can look at the answer entries (Yes, No, Abstention), count the signatures and thus see the results.
Now the question is, how do we verify that each participant has the right to vote, while still being anonymous. That could be built into the membrane of the happ, that you can’t even join the network without a valid Passport for example.
The anonymity could be achieved by creating a new private key for each voting-session or even each answer we give.
Considering the time window, that raises the question, if it’s possible to have an invalid signature of an entry, if it wasn’t signed in that time frame…
Does that even work in Holochain, that you can go to an entry and sign it without yourself being chosen as a validator and to store it? Guess I have to think a bit more on it. It’s too late here in Switzerland to think deeper
I like this conversation; a lot of good things are already being uncovered. Anonymous voters with new keypairs are especially interesting. Just want to address one question, then ask a few more.
There are two kinds of signature on an entry:
validation signature, created by the DHT nodes holding the entry,
provenance signature, created by the authors of the entry.
Because entries with the same content are all de-duplicated (no matter how many people create them, they all go to the same spot), the provenances (author signatures) end up being collected on the one entry. So ‘signing’ an entry would be as simple as writing it to your own source chain, then publishing it to the DHT. Double-votes are prevented by having validators audit the source chain leading up to the vote and making sure there are no other entries written with the same referendum ID.
Now for the questions!
Anonymity is a tricky issue. What you want to do is prove that you have a legitimate ID, without revealing your actual ID or linking it to your ballot. Most of the thoughts I have involve third-party authorities, which might be okay and it might not. What sorts of concerns do you all think might show up, and how do you think we could tackle the technical problem of ensuring anonymity and legitimacy?
What would ‘good enough’ consistency look like for different voting scenarios? When would it be okay to be a bit vague/forgiving with the voting deadline, and when would it be absolutely catastrophic?
With votes as public DHT entries, I could see early votes influencing later votes. What scenarios might require secrecy until polling closes, and how could we implement them using some sort of privacy mechanism (private entries, node-to-node messaging, encryption)?
The issue here is who’s time?
You might have a rule that says must be before midnight but I could change my machines time and it would be still a valid entry on my chain. If your rule is only accept an entry if it’s received before a certain time from an agents perspective then you end up in a situation where different agents will validate / reject the same entry depending on how long it takes an entry to get to them.
I think for this you would need some sort of trusted time server that could sign the entry with a trusted time when it’s received. Alternatively I know @wollum was talking about proving time using functions that mathimatically would take a minimum amount of time to complete even on worlds fastest computer.
That is simply brilliant. I wouldn’t have thought of it that way. Makes sense though, but we need to make sure it’s exactly the same entry.
That’s my conclusion as well. Third party authorities might be ok for a government run voting happ or inside a centralised/traditional community/organisation.
But what about a truly self organized distributed structure? I had the following idea:
to have a second happ, that knows the identity of every voter and also holds, that that person has voted (but doesn’t know how)
to have a distributed/sharded process to create a second anonymous ID (that might be used only once per vote, to make it more impossible to track). In a way that you can verify that the generated ID is valid, but you can’t backtrace it to the personalized ID. I’m not super clear how this could work securely and distributed though. I’m simply not clear enough on the capabilities of key generation, encryption and hashing. If it’s possible to get a public key from the node (or each node) that validates and registers my ID, which I then can use to create a key with which I can vote once and everyone can see that it’s valid but not who validated it or who I am.
I guess we need different layers of voting. one is anonymity, the other one is timing and if you can see the results during the vote.
Some votes nowadays are public, namely in smaller circles/groups/organisations or when representatives are voting.
When a big group and public group is voting with different and opposing positions, it’s usually private.
I’m definitely not and expert on the different levels of voting (and then with many groups there is a process to find consensus… which is again different), so maybe we need to include someone who is more versed in the social layers of voting and less the architectural and technical ones.
A possibility I see here, is that the voting node only publishes that he voted (in the registry happ maybe?) but not what. Then the voting window closes and the DHT with the entries opens for a day or two and then everyone can publish their entry. But the vote was cast before.
There seems to be a lot of key magic involved if possible
I feel like you’re exploring some promising avenues @raphisee. I can’t quite picture the whole thing yet; feel like it involves some sort of magical cryptographic proofs that I have yet to learn about, but it also feels like certain difficult scenarios are attainable with currently available algorithms. The criteria for the most difficult scenario I can think of:
Secret ballot (value not shown until polling closes)
Ballot has no knowledge of voter’s identity, but has to include proof that the voter was eligible to vote
If not a zero-knowledge proof, then some sort of Merkle proof that shows that an anonymous ID is connected to a registered voter without revealing the nature of the voter, and is the only anonymous ID generated by that voter for this vote. Bonus points: the third-party identity verifier can’t be forced to reveal the connection between the anonymous ID and the registered voter (plausible deniability). This would be strong enough for national elections.
I really like this idea:
This seems doable without resorting to exotic things like ZKPs: simply publish a private entry containing your vote. The header serves as proof that you voted. To this is added a random string, a ‘nonce’ or ‘salt’ value that prevents people from snooping the value of your vote by looking at the entry’s hash in the public header. Once the window closes, publish the same vote and salt, which should hash to the same value (more or less — the entry type influences the hash, so a private_vote entry of { "candidate": "Jane Doe", "nonce": "Ablhc7asi7gelh" } will have a different hash from a public_vote entry with the same value).
This is also very important:
I can talk about technical implementation forever, but I’m not as wise in the real human needs we’re serving.
For the ultimate in self-organised, distributed structure, @resilience-me has some very interesting ideas about proof-of-identity. ‘Pseudonym Pairs’. It involves random pairing with other people for verification of personhood, and relies on the statistical unlikelihood of being paired with someone who’s (a) a jerk or (b) willing to collude with you. @resilience-me does it guarantee uniqueness of personhood (i.e., this person doesn’t have any other identity in the system), or simply personhood?
Yes uniqueness, “proof-of-unique-human”. The solution comes from Bryan Ford a decade ago under MIT with his Pseudonym Parties, to do key signing parties at the exact same time in a “pseudonym event” and do recurring events with a period of time in between, he suggested a year I think.
I’m net generation and grew up more with social media, and his protocol had the problem of fake regions, so I had the idea to do the pseudonym event online instead, over video chat. The logical way to do that was in pairs, for a number of reasons. Also, to do them frequently, every 4 weeks, so that if you miss an event it is not the end of the world.
Pairs were possible because I came up with a “police mechanism”, to prevent bots (as in scripts that aim to beat random pairing to get majority in a pair) from attacking the network, any bot paired with a human had to lose, that is, they should not be in a position where they can force the other to verify them. That was solved with the police-mechanism. If you are peered with a bot, you can break up your pair, and you and the peer are sorted under another random pair (as a form of court. ) For a human being, you will still be verified, a bot will not.
In a similar manner, when “immigrating” into the network, you are “inspected” by a random pair of people. The network has a “virtual border” and to get across it you have to be inspected by the “border police” (who is just a random pair of people in the “nation” Pseudonym Pairs. )
As people who has lost their homes for others, I think Palestinians are the most favorite to build a global crypto-state! This way we can prove that only new solutions beyond a system in crisis can work; To build our nation beyond borders, so that together with the global community (state) we change the world …
When I started to work on this vision 15 years ago, I started to look into how the configuration of direct global governance could look like to map the world into capsuled layers and interfaces for organized communication depending on geographic actions/locations with global interdependence.
Through the internet, you can be active on any one of these layers according to the permissions given to you. People who live in a neighborhood on the 6th level will have their sovereignty to vote on specific issues related to their living space only. These issues are transparent to others so that they can learn, comment, etc. Also members from their neighborhood who are residents somewhere else would be having the same permissions. This is very much relevent for us Palestinians as most of people can not return to their homes which has been displaced from, but cyper-ly they would be able to that.
Maybe in general everyone can design to which neighborhood he belongs by defining where he is paying taxes, or this could be a free choice (need to be discussed deeper). Then it goes one layer higher to issues within the next neighborhoods between each other, then the whole city, etc.
The intensity of communication is most on the locality level, as the concern of the people around you counts most. From their you address issues which are to be communicated from the other neighborhood or the city, then to higher levels, furth and back.
A holistic interconnectivity
This is the way I have thought about it. I hope you can find something relevant in this stuff.
Notice how this structure is building a global deep learning machine run by people as global issues will evoke directly by the people.
Sorry if this is becoming less and less related to the original question. I am intrigued by the
I do not see how you would get uniqueness here. Can you explain?
So for me the problem is this:
There are a lot of registrations (e.g. Persons) and one wants to make sure that behind each of them is a real person intending to be registered and that no two registrations belong to the same person. And all this in a distributed manner.
To make sure that a double registration would be uncovered, you need to be sure to connect the two registrations if they were the same. You do not want to give each pair of registrations to enough referees that you can trust at least one of them, that are just to many.
The solution was invented by Bryan Ford in 2008, and it is to do the verification at the exact same time for everyone on Earth, preventing people from participating in more than one verification session.
I adapted that for the online space, instead of people meeting in local groups, they meet a random stranger online, in Pseudonym Pairs, http://pseudonympairs.tech/
Aah, I see. Thanks!
But then it is a problem if someone can not join the meeting. Even if you would require only to be present on say 75% of the meetings, a group of 3 could cheat out a fourth account. Plus you need to make sure that the videochat guy on the other end is not simultaneously identifying with someone else, nor is he only a video. One could quite easily train ai to fake such a videocall.
AND having mandatory global synchronous meetings every month is more than cumbersome.
The application I had in mind was Global UBI… At least for that I cannot see that…
The personhood tokens are disposable once a period has ended. If you miss an event, you lose out on a single period. I’ve set the periods to be 28 days. That way, the events are always scheduled to be on the weekend for all time zones on Earth, and, they are frequently enough so that you do not miss out too much if you miss one, and, they are seldom enough so that you do not always have to do the verification. Every period gives you a new, untraceable proof-of-personhood. Use mixers to anonymize it.
this topic has been dormant for some time. But it has been popping up in the back of my mind repeatedly. I kept wondering what would be the most elegant way to anonymize voting while retaining the capability for the voter to check if their vote has been published correctly.
It is a tricky problem. The best solution I’ve been able to come up with so far is this:
We need four groups of agents. The number of agents in each group is defined by the redundancy factor desired. Then the process goes as follows:
Group A (each agent performs those steps)
Create a temporary key pair
Create a voting address (so they can later locate their vote) and cast their vote
Package both the address and their vote and encrypt it with the temporary private key
Send encrypted voting package to each agent of Group B
Send their temporary private key to each agent of Group C
Publish confirmation that they have cast their vote (so they can’t vote again)
Group B
Wrap all individual voting packages into one big package
Publish the hash of that package to the DHT (to prove the correctness of their data without disclosing it)
Send the package to all agents of Group D
Group C
Wrap all temporary private keys into one package
Publish the hash of that package to the DHT (to prove the correctness of their data without disclosing it)
Send the package to all agents of Group D
Group D
Decrypt all voting packages using the temporary private keys (depending on the number of votes this might take quite a bit of trial and error to find the right key for each package)
Publish all the vote addresses with the correct vote!
Reflection:
Oh dear, that was a cumbersome process! But we have achieved quite a bit! These following points have been achieved:
Agents of Group B and C know the voters, but do not know the vote!
Agents of Group D know the votes, but not the voters of Group A
The voters of Group A can check, if their individual vote has been published correctly
The respective agents of Groups B, C and D can check each other to make sure nobody is publishing false data
One more thought:
Since Group B and C know both the voters (Group A) and the publishers (Group D), they might not know who cast what vote exactly, but depending on the number of agents in group A they could learn more than they are supposed to.
Imagine its just 10 agents in Group A and all vote yes…
So it might be necessary to do some additional rounds of obfuscation. In that case it would be clever to have smaller groups and more rounds, but have Group D decrypt all the votes (small number = little guesswork which key fits which package) and then encrypt the whole lot of them with a new temporary key…
Did all of that make sense to you? What do you think, is it a feasible approach? Is there a more elegant solution?
@jakob.winter I’m thinking this over – thank you so much for the illustration; it does a great job of explaining what’s going on in the process.
Questions:
Does group A connect their temp keypair to a real-life identity to prove that they’re allowed to vote?
If (1) is true, does group A have to send off a copy of that proof to group B along with their vote?
The thing I still can’t figure out is how to prove that you’re allowed to vote without out revealing who you are to the agents doing the counting, and without relying on a notary that’s trusted by both parties and knows who you are.
Well, in my above example it is simply assumed that you are eligible to vote (so that has to be determined separately).
But assuming you are qualified to vote: In step 5 of the graphic, the agents of Group A publish the fact that they have voted. Only after that entry shows up in their source chain, will Group B and Group C process their vote. So double-voting isn’t possible.
Ah, okay, so identity verification (by whatever means) is out of scope for what you’re exploring; you’re just exploring ways to split up the vote and the voter for anonymity’s sake. Got it!
