Unprovable voting; re: amoveo-docs/design/voting_in_blockchains.md

[XertroV]

from amoveo-docs/design/voting_in_blockchains.md

Under Nakamoto security it is not possible to prevent people from proving how they voted.

With simple voting schemes this is true, but it doesn't have to be -- I think. Two relevant things come to mind:

1. Some voting systems use a receipt scheme to let ppl check/confirm their vote was cast as intended. This seems sensible. If the receipts are all public then a voter can't use their receipt to prove how they voted.
2. The submission of votes needs to be anonymous. This is possible to do even if the voters have different weights, but requires a multistep procedure. I came up with a method of doing online secret ballot in 2016 that uses 2 rounds of an oblivious shuffle (the first for creating an anon voting ID, and one for doing the voting itself). Here's an image that summarizes it: https://i.imgur.com/FmODTH0.png

I think if you have both of these things then there's at least the foundation for ppl not being able to prove how they voted. There are some issues re: receipts that are subtle, like if they're just random numbers then what stops someone colluding to choose the number in advance. IDK if that's a soluble problem (creating receipts that ppl know are theirs, but doing it in such a way that the voter can't collude beforehand).

[XertroV]

Oh, LMK if there's a better place to post criticisms/comments.

[zack-bitcoin]

There is a telegram forum for Amoveo discussion, discord as well. Links are all from here: https://github.com/zack-bitcoin/amoveo I don't know how oblivious shuffle works, and a google search doesn't find it.

Voters want to get bribed and sell their votes, so they would collude before voting had begun.

Even if there was a secure way to do voting, we still should not do it. It is a terrible way to make decisions, because of the rational ignorance problem, it is cheap for a propagandist to control the outcome. We should use futarchy when groups of people need to make a decision together.

[XertroV]

There is a telegram forum for Amoveo discussion, discord as well.

Is there anywhere public (or at least openly readable) for discussion? I don't mind moving if you'd like me to, but I prefer more permanent & accessible forums.

I don't know how oblivious shuffle works, and a google search doesn't find it.

It's detailed in the coinjoin paper (mirror) under 4.2. Looking at it now, I might have invented the term 'oblivious shuffle'; the authors don't use it. In any case, that's the process I mean.

Voters want to get bribed and sell their votes, so they would collude before voting had begun.

Yup; tho doesn't that rely on their ability to prove that the voted one way or the other? If they can't prove how they voted, how do they redeem the bribe?

Even if there was a secure way to do voting, we still should not do it.

I agree, btw. Some years ago I invented a market based system for governance decisions (called Issue Based Digital Democracy (IBDD), see 1, 2, 3) precisely b/c I think other systems (esp. those with an emphasis on ranked preferences) are inadequate. FYI, those links probably aren't going to be easy to read -- I was a much worse writer then. I have more written on that topic that I can link, too, but I don't think any of it is high enough quality to be proud of. The main idea was treating votes as a liquid asset that you can trade for a store of value, and that store of value can be used to bid (at auction) for unwanted votes on other issues in the future; the store of value was used to bid for chances to propose legislation, too.

Anyway, I haven't worked on that in a while and it's not my focus atm. Just thought I'd mention.

[XertroV]

Voters want to get bribed and sell their votes, so they would collude before voting had begun.

Yup; tho doesn't that rely on their ability to prove that the voted one way or the other? If they can't prove how they voted, how do they redeem the bribe?

One thing I just thought of; I don't know if, using an oblivious shuffle, voters would be able to run an (otherwise undetectable) extension to the protocol and soft-fork it, so that they could e.g.: control receipts; or generate a proof of how they voted; etc. Hmm.

[zack-bitcoin]

Twitter is public and permanent. I control this account @zack_bitcoin

It is like you said before. The voters can collude with whoever is offering them a bribe to select the random numbers ahead of time. Zero knowledge proofs can also be used so that the person paying the bribe can be involved with every step of the shuffle process, without having access to the private key or being able to steal funds from the person they are bribing.

I am looking at the coinshuffle paper. It looks like this involves some onion encrypting, where you keep re-encrypting your vote, so it needs to be sent to lots of other nodes to get totally decrypted. Kind of like a secure decentralized re-mailing service.

If the attacker knows your private key, and the vote you made, and all the salt you had used for encryption, they can completely unwrap the onion. They can re-do all the layers of encryption, and verify that the encrypted data is identical to the vote you revealed to them. So a voter is able to prove how they voted. This protocol doesn't work for anonymizing votes, in the case where the voters are motivated to de-anonymize themselves.

Im looking at what you wrote about voting. It seems like you are aware of a lot of shortcomings of voting protocols, but it isn't clear to me what mechanism you are proposing as an alternative. The "create futarchy" tab in the light node is how we make collective decisions in Amoveo http://159.89.87.58:8080/wallet.html

Making decisions for a blockchain community is easier than other kinds of communities, because we can go with whatever outcome maximizes the price of the currency.

The way it works is that first we have a binary market to bet on whether we go with plan A or plan B. This market allows you to split up the native currency into 2 forms. A-coins, which are valuable if we use plan A, and B-coins, which are valuable if we use plan B. 1 A coin + 1 B coin together is always as valuable as the native currency, because you can combine them back into the native currency. The market price of A coins is an estimate for how likely the community is to go with plan A.

Next we use the A-coins as the collateral to create a scalar contract. This scalar contract is betting on the price of the native currency. So it splits the A-coins into 2 types. One type that is like, long the native asset, and the other is short the native asset. So a market for this scalar contract, it is a prediction market that reveals to us what the price of the native asset would be, conditional on the community adopting plan A.

We make an identical market collateralized with B-coins. So this second market, it reveals to us what the price of the native asset would be, conditional on the community adopting plan B.

By comparing the price in these 2 scalar markets, we can see how plan A and plan B differ in their impact on the price of the native currency. We use whichever plan results in a higher price for the native asset.

[zack-bitcoin]

There is also a reddit for Amoveo. https://www.reddit.com/r/Amoveo/

[XertroV]

It looks like this involves some onion encrypting, where you keep re-encrypting your vote, so it needs to be sent to lots of other nodes to get totally decrypted. Kind of like a secure decentralized re-mailing service.

Yes. In the shuffling process the nodes are orderable (e.g., by sorting their public keys), and node1 encrypts like: e(node2, e(node3, e(..., e(node[n-1], e(node[n], vote)) ...))); i.e., each layer of the onion corresponds to one participant's keypair. Node2 'unwraps' (decrypts) the outer layer, and produces a similar onion with their vote and all subsequent nodes' pubkeys; then passes 2x onions to node3. Node3 does a similar process and passes 3x onions to node4, etc. Sort of like a quadratic pass-the-parcel.

If the attacker knows your private key, and the vote you made, and all the salt you had used for encryption, they can completely unwrap the onion.

I think an attacker needs to know all other the privkeys to unwrap, right? Like, if you used x25519 then the encrypted blob doesn't depend on your keypair (from memory).

That said, with voting you need to include more than just the vote b/c votes have low entropy. so if you include a nonce with the vote (which mb becomes the receipt or is part of it) then a colluding attacker can verify the original input. Not unwrapping, but the effect is the same.

So a voter could still prove how they voted provided the attacker can verify this before the shuffle is complete (or the voter could potentially commit to a nonce before the shuffling even starts, depending on the scheme). After the shuffle is complete, without some prior commitment, the voter could use anyone else's vote+nonce and the attacker/colluder wouldn't be able to tell the diff based on the output of the shuffle. They might be able to verify a vote if all the msgs are recorded and provided to the attacker (note: the shuffle protocol requires everyone to record all the msgs anyway for the blame game, so this is definitely available).

This protocol doesn't work for anonymizing votes, in the case where the voters are motivated to de-anonymize themselves.

Yup, I agree. Thx for helping me to change my mind.

but it isn't clear to me what mechanism you are proposing as an alternative.

A note: I don't endorse the idea anymore; it's something I was proposing, but I'm no longer convinced that it'd solve the problems I thought it would.

I can describe the mechanism more if you'd like, but IMO it's not that important. The inspiration for it was the philosophical and economic answers to the question why does capitalism tend to cause progress? -- I wanted to replicate economic structures that I thought necessary for capitalism to work, like: opportunity cost, specialization and trade, comparative advantage, arbitrage, anti-statism (state-protected monopolies, etc), and market based price-finding.

---

re: futarchy; I don't think I'm convinced (yet?) that futarchy works, though there are economic/market effects going on which I think is probably good. The reason I'm not convinced that futarchy works is that I'm not convinced that prediction markets make accurate predictions; or, at least, they only make accurate predictions when we already know the answer. (nb: particularly I mean predictions about binary outcomes)

Since futarchy/amoveo is a diff topic to my OP, I might make a post on the subreddit about it. I feel like the original topic is wrapped up. Thanks for providing the extra discussion on futarchy here, tho.

[XertroV]

note/errata: I incorrectly referred to the coinshuffle paper as the coinjoin paper earlier.