Voter Collaboration - early publishing of votes/private keys

[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.

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.

miners could influence the outcome of the vote by not adding decryptions they don't like into the blockchain. Since the decryption is not hashed/encrypted, everyone knows what is being added.

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.

You are correct. It is also possible to write an incorrect vote to trick people, and then refuse to decrypt the vote later on.
Everyone has strong incentive to trick each other.

[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.

miners could influence the outcome of the vote by not adding decryptions they don't like into the blockchain. Since the decryption is not hashed/encrypted, everyone knows what is being added.

good point!
However, I think this typ of censorship is not that bad, since voters have a period to include votes in the blockchain.
So the power of a mining pool is limited. They can block certain votes - but it wouldn't have any effect as long as one honest miner finds a block during the "reveal phase".

With unencrypted votes/ not hashed votes it would be a hole different story - since the mining pool that would make the latest block could add votes/ vote changes in a selfish way.

[Troy]

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.

miners could influence the outcome of the vote by not adding decryptions they don't like into the blockchain. Since the decryption is not hashed/encrypted, everyone knows what is being added.

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.

You are correct. It is also possible to write an incorrect vote to trick people, and then refuse to decrypt the vote later on.
Everyone has strong incentive to trick each other.

I'm a bit late to the party here, but I can't help but think about koeppelmann's comment. Who says that the malicious collaborators are all independent entities that have no idea who each other are? All you need is a single malicious group, or single malicious person (with enough wallets), to acquire most of the VoteCoins. Do you think the market cap for VoteCoins would be so high that it would prohibit a single person or single group from accumulating a majority of the VoteCoins on the open market? It seems to be that it is a lot easier to launch a 51% attack on TruthCoin PMs by simply accumulating a majority stake in the VoteCoin market, than it would be to, say, launch a 51% attack on Bitcoin by accumulating 51% of the hashing power.

I just read through the whitepaper and associated documents yesterday. Really, really intrigued by this project. I keep seeing the voting system as the weakest piece though, which is the key that everything else relies on. In order for people to put trust into this decentralized system it has to be a practical impossibility that an incorrect outcome could ever be decided.

[psztorc]

Hi Troy,

I completely agree with you. In fact, extra security to prevent against the ">51% ownership attack" has been really the only change I have been making to the design since I first published the initial code nearly a year ago.

You may have noticed (if you read the latest whitepaper) that 51% is now actually not enough...I have something represented by the greek Phi (I think) which is responsible for the "Two Wave SVD" concept (or DoubleFactory() in the R code). This helps to extend the incentives present until 49% all the way up to Phi%. However, now someone with (1-Phi)% can delay Decision-Resolution. For this I have the Audit concept (a "Branch" of cash), and to that I've added a careful Miner Veto. These changes will be published in new slides (hopefully tomorrow, but who knows), and in Whitepaper 1.4, which I hope to publish before Wednesday evening (although I doubt I'll pull that off).

In general, I think the strategic principle of "time" is sound. It is harder to hide information as time passes, yet funds can be frozen in place. The net effect is always to make the attacker's life more inconvenient. Because the network has value, this inconvenience can be transformed into a disincentive.

And I am hoping to contrive Branching, such that it is rare to actually pull off, keeping all the Market Caps of each Branch very high.

[psztorc]

And, I don't think you are late to the party.

In fact I'd say the party hasn't even started yet.

[zack]

My version of truthcoin is a little different. Anyone can create a new branch by burning some cashcoin.
The branches are in competition with each other for customers. The branch jurors will do whatever they need to do to show how honest they are.
Whichever jury is best able to prove it's honesty, that jury will get the most customers and make the most profit.

It is possible to create a prediction market using decisions from multiple branches.

Not all types of votecoins will be on exchanges. Some juries might never transfer their votecoins after the initial allocation.

[koeppelmann]

@zack - but the voting mechanics/ coin redistribution/ SVD stuff, does work the way as Paul proposed it for every individual jury/branch, right? Even if it is only a single entity holding all votecoins of one branch?

[zack]

If only one person holds all the votecoins, then we cannot even compute SVD. the matrix is a vector.

A single person could have 3 accounts, and they could split the votecoins among them. Then that single person could have complete control on the outcome of the predictions they host.
Those predictions would be total scams.

It is a market where the buyers need to be aware of the danger.
But, honest juries will come up with many techniques to make themselves look most honest.