Crazy bug, and my potential solution.

[zack]

Voter collusion is when over 51% of people who hold a particular type of votecoin work together to make a prediction's outcome contradict reality. For example: if Obama won the election, but the PM paid money to people who bet on Romney instead of paying to people who bet on Obama.

In order to collude, voters need to prove to each other how they will vote. When voters give an encrypted vote, they could privately decrypt it for the other voters. By privately decrypting, the voters can prove to each other how they voted, and this allows them to collude.

In order to stop this type of collusion, we create a punishment transaction. If I can prove how someone else is about to vote, then I can use the punishment transaction to steal all their votecoins.

The problem with the punishment transaction is that it has the exact same input data as the reveal transaction. Miners could choose to censor reveal transactions, and use the data to write punishment transactions. The miners would quickly steal all the votecoins.

To fix this problem, I added a new sequential step, so that everyone has to admit that they are unaware of cheaters. Once you have admitted that you are unaware of cheaters, you cannot change your mind, even if the block containing that transaction gets re-made.

Phase I
All voters can encrypted vote. They can replace their vote as often as they want.
Phase II
Cheaters are people who pre-emptively reveal how they voted.
All voters sign a single transaction listing all the cheaters they can prove had cheated.
If the voter fails to sign such a transaction, or a voter signs 2 contradictory transactions of this type, then they lose their votecoins and any people they wrongfully accused are un-punished.
If someone is caught for cheating, then their votecoins are transferred to the person that turned them in (but it takes a long time for that money to become spendable so that the wrongfully accused can be un-punished)
Phase III
voters reveal how they voted
Phase IV
if enough people have voted, then SVD is computed, otherwise we go back to Phase I

New transaction types:
1) turning in 0 or more cheaters who pre-emptively revealed how they voted. <---mandatory, can only be broadcast in phase II
2) punishing voters who failed to use (1) correctly.  <---- can be broadcast at any time.

[koeppelmann]

This solution seems valid to me but to me this solution: http://forum.truthcoin.info/index.php/topic,128.msg527.html#msg527

It achieves the same goals and this additional phase is not needed. The only difference is that the penalty is a little bit less strong. In my solution a voter who reveals their votes early only looses control over them in this single vote.

[zack]

Koeppelmann's method does not work, but I appreciate the effort.
There is no incentive to report cheaters.
If someone prematurely revealed their vote to you, why would you go to the trouble of writing a transaction to report their attempt to collude?
You have to pay a fee on the transaction to report them.
Even if you did turn them in, they would know exactly who did it. They would stop attempting to collude with you, and would focus their energy on the other voters instead.

It would be very easy to commit collusion.

[koeppelmann]

There is no incentive to report cheaters.

There is a incentive. You can either change the vote to exactly what you are voting on to make it to the majority or if you are very confident that you vote together with the majority you can change the votes to the exact opposite. This would make the colluder loose votecoins and you would profit (at least a little bit, since coins are distributed aver all how profit from RBCD

Even if you did turn them in, they would know exactly who did it. They would stop attempting to collude with you, and would focus their energy on the other voters instead.

This is not different from your solution. Once a attempt failed the colluder get no 2nd chance since he lost control over his votes. The difference is - that he looses all his votecoins in your solution and in my only what you loose if you vote the complete opposite to the average vote. (I don't no details about RBCD - but I could imagine that such a vote lets you loose near to 100% of the coins?)


However - you convinced me, that your solution has a higher incentive to "break a colluding alliance".
 

[psztorc]

I had imagined that 'StealFromLoudVoters(TargetReveal, VotersNewPublicKey, TheifNewPublicKey)' would also be submitted in the same manner as the Ballots (hash-reveal style, and at the same time(s)). I apologize for not clarifying this, but I felt it was obvious (after all: pre-hash, the sealed Vote has not been cast, and so VotersNewPublicKey does not exist, and, post-reveal, the VotersNewPublicKey is known to everyone).

So it is false that "punishment transaction...has the exact same input data as the reveal transaction" (it doesn't contain the votes, for example) and it is also impossible to for "Miners...to write punishment transactions" (they are too late by the time they see them).

Also, in your scheme, if a miner can and would censor "reveal" transactions, why wouldn't he also censor the tx of Phase II?

I explained in January how we might prevent Miners from censoring votes, should the need arise (it is still in there, page 15 of v1.3). I still don't think the need ever will arise, because the attacking-miners need to guarantee in advance that they can mine ~1000 blocks in a row (or at least orphan target blocks during that period), all to guarantee the destruction of the value of one or more Branches. If you were that powerful, I would imagine that you would try to double-spend CashCoin long before you tried anything like this. If you think it is a problem please both (a) explain why, and (b) read p15 before writing any further.

An aside: If changes need to be made (since February, I have only made one to increase functionality and two to increase security) it would be better to make them via subtraction (ie, removing unwanted things) or in a way that doesn't change what is knowable. This is because "adding" adds more dimensions to the players' information sets (ie what is knowable). Too many dimensions and the strategy becomes impossible to understand, which essentially guarantees failure. Better to give up entirely than over-complexify.

[zack]

aha!
Thank you Paul, this simplifies things greatly.

Phase I
encrypted vote
catch cheaters
Phase II
reveal vote
Phase III
SVD consensus

I cannot agree with you more about the danger of over-complexity. We don't want to end up like Ethereum or OS/360

[zack]

I updated the code. this bug is solved. https://github.com/zack-bitcoin/Truthcoin-POW