Voter Collaboration - early publishing of votes/private keys

[koeppelmann]

I question your assumption that it is not possible for voters to make provable public what they have voted for without loosing control of the coins.

You argue that users encrypt their votes and release the private key only when all votes are placed - since otherwise someone else could control the vote (the TRU?)

However, as far as I understood the timeframe for placing a vote is in the range of days while the timeframe for a block creation is more like 10 minutes (??). Now - when my vote is in the blockchain (together with a (not encrypted) transaction to a different address, right?) what prevents me from publishing the private key?

[zack]

The version of truthcoin that I wrote avoids this step. I never reveal the private keys at all, and it is for exactly the reason you suggest.
Instead, the private key is used to sign the transaction.

https://github.com/zack-bitcoin/Truthcoin-POW

[psztorc]

If you did, someone could publish an 'update' changing your vote (to either something nonsensical, so that you would lose in RBCR, or to the realistic Ballot) and at the same time steal your "VoteCoins".

Voters encrypt, sign, and broadcast a Ballot which contains their Votes and a new public key (for which they have the corresponding private key). Critically, Voters have the option to change their Ballot at any time and for any reason during this period (for example, to update the new public key). Only the latest included Ballot stands.

The transaction is encrypted.

[psztorc]

https://github.com/psztorc/Truthcoin/tree/master/docs#do-strategic-decisions-change-if-one-node-started-publishing-potentially-biased-votes-immediately-upon-noticing-them-one-could-publish-10-attack-votes-and-the-11th--user-would-be-tempted-to-conform-leading-to-a-cascading-failure

[psztorc]

The version of truthcoin that I wrote avoids this step. I never reveal the private keys at all, and it is for exactly the reason you suggest.
Instead, the private key is used to sign the transaction.

https://github.com/zack-bitcoin/Truthcoin-POW

Can you be more specific about what you omitted?

[zack]

unspent transactions are not encrypted. They are publicly visible. The blockchain doesn't know about them yet.
If there was a private key in an unspent transaction, then anyone who read it would be able to generate more valid unspent transactions for the same ID. It is ID-theft.
I had forgotten that you do every transaction in 2 steps.
Yes, you can reveal private keys this way, and it is secure.
I don't like it though, so I didn't do it that way.

Users in my system are identified by addresses which are generated from their public key.
With your method, I would have to allow users to purchase custom names for identification?

[zack]

Bitcoin requires 120 blocks before new money is spendable.
Otherwise forks would delete money sometimes.

How many blocks between when you encrypt a transaction, and when you reveal it?

Whenever there is a big fork, everyone who revealed private keys would be vulnerable to theft

[koeppelmann]

I am not sure if it is true for all possible implementations of encrypting messages, but I think in general it is possible to prove to others the content of an encrypted message without revealing the key?  - https://en.wikipedia.org/wiki/Zero-knowledge_proofs

[psztorc]

From reading in my spare time, I gathered that for symmetric key encryption it is probably not possible to show someone [1] an unencrypted message, [2] an encrypted message, [3] some proof that #2 really is the encrypted form of #1, without revealing [4] the encryption secret.

I'm excited for real cryptographers to look at this schedule, because I'm highly confident that it will be substantially changed for the better. We may not even need to send votes in two waves at all, or wait for a long time, or expose private keys. There is probably a fancier cryptography way to do all of this which, in the planning stages, we can easily implement.

[zack]

real cryptographers

So what do you think I am?

fancier cryptography

the only crypto used for projects like this is public key crypto (for creating signatures, and verifying signatures), and hash algorithms.
It is possible to build a cryptocurrency from only hash algorithms, but it is a little less efficient, and the code is a little messier.

You instead use encryption and decryption. Those tools are totally avoided for a project like this.
I cannot see any reason for them to exist, and my implementation does not use them at all.

Truthcoin as I built it does not need to send votes in two waves, or wait a long time, or expose private keys.

[koeppelmann]

I not sure wether the vote encryption is substantial at all.

Of course: your argument that it is needed is that it should make collusion/ coordination on something else but the truth more difficult.

However - I suspect people (or at least some major coin holders) to publish feeds with their ballot since it is in their interest that lots of others vote "close" to them so they profit from RBCR. OK - you might argue they profit from some outliers even more but I think first it is more important to be close to the vector that results in the SVD.

Thus said people some people will publish votes anyway and it is reasonable to trust them (if they have some reputation) So - would not encrypting the votes would really make a difference? Remember: votes are not binding!! You always can change them - so - from a game theory point of view - the difference between a (not binding) visible vote in the blockchain - vs a encrypted vote + a feed of it is not that big as all (or maybe there is no difference at all). Since if people want to trick on other they can - in option 1: publish something different in the external source/ in option 2: change their votes in the last second.

Of course - at lot of people will - because of laziness not provide a feed of their votes - but the pure nash equilibrium should be the same for both versions?
(And I guess a equilibrium strategy might be: always publish all your votes but with 3%-5% intentional errors)

[zack]

Actually, all the voters have an incentive to lie to each other, and trick each other to vote incorrectly.
It is the only incentive structure that is safe from collusion.

Each block has a finite capacity for votes. If everyone changes votes at the last second, then a lot of transactions wouldn't get included.
It would be a very risky game to play, you could end up voting the wrong way. Also, each transaction has a fee...
People who live in remote locations with poor connection wouldn't be able to broadcast a vote at the last minute. There is too much delay.

My current implementation has a 20-block cycle.
The first 10 blocks are when voters share the hash of their vote.
The next 5 blocks are when voters reveal the vote, and it has to match the hash they shared earlier.
The last 5 blocks are when it is possible to do single-value-decomposition to determine the consensus outcomes of each decision.

My way of doing "encrypted" votes doesn't involve encryption. It is more like

[koeppelmann]

one other thing I forgot is: miner censorship of votes.

So forget about publicly visible votes.

Actually, all the voters have an incentive to lie to each other, and trick each other to vote incorrectly.

I am not 100% sure to me if this is true. I think the first it is important for voters that a decent number of votes is very similar to them. So why not publish the own true votes. Lets say 60-70% copy the votes and all other does it for themselves every one in the 70% would profit. And since it is a "repeated game" there is no real incentive to lie to your "70% crowd". Only as soon as 100% of the voters follow you, you would stop profiting from RBCR.

The first 10 blocks are when voters share the hash of their vote.

So in your implementation voters could reveal their vote without loosing control over it, right?

[zack]

one other thing I forgot is: miner censorship of votes.

So forget about publicly visible votes.

How does encrypting the votes help with miner censorship?
Miners could censor the decryption steps that they dislike just as easily as they could censor the encrypted-vote steps.

So in your implementation voters could reveal their vote without loosing control over it, right?

I don't understand the question...
In my implementation, you never have to reveal your private key.

[koeppelmann]

one other thing I forgot is: miner censorship of votes.

So forget about publicly visible votes.

How does encrypting the votes help with miner censorship?
Miners could censor the decryption steps that they dislike just as easily as they could censor the encrypted-vote steps.

If votes would be not encrypted (or hashed) miners could influence the outcome of the vote by not adding votes they don't like into the blocks/blockchain. Since votes are hashed/ encrypted they don't know what they are adding.

So in your implementation voters could reveal their vote without loosing control over it, right?

I don't understand the question...
In my implementation, you never have to reveal your private key.

The assumption in Pauls paper is that voters can not reveal their vote early to others without loosing control over their vote /(publishing a private key). I guess in your implementation that does not hold true since voters CAN PUBLISH THE VOTE ON AN EXTERNAL SOURCE before the official vote reveal phase.

However - as mentioned earlier - since they still could change their vote in the last minute I think the assumption from the paper that trustless collusion is not possible still holdes true.