Messages

["Voters use { bribe magnitude, VTC market cap } to compute optimal split e*]

It's slightly disturbing to me that you "ran the numbers splitting my votes into 2%" and then reached some conclusion. The magnitude of 2, in range(0,50) was just an example (the split magnitude depends on the bribe magnitude).

To restate my position yet again, in yet another way, consider this timeline: "Bribe" -> "Voters use { bribe magnitude, VTC market cap } to compute optimal split e* ( which will always be between .000 and .500, and in practice might be between .001 and .030 )" -> "all Voters split their VTC holdings by e*" -> "bribe fails (and pays out big), resolution succeeds".

Did your 100%-lie player lose Votecoins? Did you calculate the implied economic cost of that loss (as, perhaps, percentage of the market cap)? 

As to the collusion...it is discussed in the FAQ as well as elsewhere in the forum, in addition to being addressed in, -gasp-, Whitepaper 1.0 which was published over a year ago.

For example: http://forum.truthcoin.info/index.php/topic,127.0.html

The Augur version of Truthcoin has no chance of success if it is going to be 12 months behind any literate competitor...12 months is an eternity in this space.

If everyone lies, they get the biggest payout, that's how the p+epsilon attack works...

Accumulating 51% is extremely difficult as it would push the price up enormously high.

Your collusion solution solves collusion at the expense of making a highly convoluted process most users won't understand: "you mean my pubkey is my private key? And I have to make a new key after I vote.. what?". 

With Zack's proposed modification we can eliminate the use of symmetric key encryption, however you have not proposed this idea anywhere.  Sure, I can encrypt the votes with symmetric encryption, but now I can't send votes easily to other users because my public key is my private key.  This solution is quite convoluted and requires assigning your votes to a new key after consensus, making things further computationally expensive as well (yet another massive set of data to keep track of). (and having one's vote encrypting key doesn't even allow you to take their votes because if it did, anyone could steal anyone's votes at any time due to the nature of blockchains & symmetric crypto).

We're not twelve months behind, we're focusing on improvements to a reporting design that will currently make no sense to the vast majority of users.

Hey, (from the Augur project here) --- I used to think this attack was an issue (and SMPC *is* in our roadmap in the long run due to that reason, if it'll stay there depends on computational costs, etc.).  I too don't get the splitting vote solution - I ran the numbers splitting my votes into 2% on the failing lie and 98% truth and it's still more profitable to vote 100% lie. 

However, on "Salvaging Schelling Schemes" in Vitalik's blog post he brings up a good point (I think Paul brought this up a few times too): "Hence, in order to overcome such a mechanism, one would need to be able to prove that one is capable of pulling off a 51% attack, and perhaps we may simply be comfortable with assuming that attackers of that size do not exist." 

The reasons klosure brought up are very similar to my thinking re 51% attacks on reputation; it's the same way I answer it when people ask me about "well what if i bought up 51% of rep?"  If you need to prove you're capable of pulling off a 51% attack to execute a p+epsilon attack, you may as well just execute a regular old 51% attack, which as klosure pointed out is very difficult for one actor (if not nigh impossible).

The type of 51% attack I am concerned about regarding this project is if people collude for voting on outcomes.  The only way you can really do this is if you can prove to other people how you voted before the outcome is resolved.  One way to prevent this is to make people's reputation itself be a bond (and if someone can prove you leaked how you voted they get that reputation - got this idea from Zack).  Even if there wasn't a system like Zack proposed, there's still no way to know if you will change your vote at the last minute before consensus is calculated. 

Hey! 

Did you try installing cdecimal with sudo pip install m3-cdecimal?

Also, screenshots are available at www.augur.net