Messages

With your method, if there was a fork in the blockchain, the miner who made the longer branch would be able to control all the votecoins from everyone who voted on the shorter branch. That single miner would likely have over 51% of votecoins, and he would cheat.

No - all he could do is to change the votes for a single ballot. And he even can not do this because it could be separated by time. Lets say hashed votes could be submitted until 01.01.2015. Then the revealing phase starts at 03.01.2015. If the miner not gets the "vn" values / revealed votes all he could do is change votes in a blockchain older than 24h and try to overtake a blockchain that is more then 24h ahead - he could only do it if he head way more then 51% hashrate and even then he did not control any votecoins for the next ballot (because he can not sign new votes). Thus this blockchain would only have votes from the votecoins the attacker controlls.

With your method, if there was a fork in the blockchain, the miner who made the longer branch would be able to control all the votecoins from everyone who voted on the shorter branch. That single miner would likely have over 51% of votecoins, and he would cheat.

There should be a punishment for revealing your hash ahead of time.
Revealing you hash ahead of time makes it easy to collude. So we need a punishment for people who do it.
That is why I remove all the votecoins from people who reveal their hash ahead of time.

Losing control over this vote on this specific ballot is enough punishment to avoid collusion.

[encrypted hashed]

The important part now is, that no the vote can be changed just by providing the votes + random string that lead to the hash value.

I was not aware that this part is part of your solution.

Lets say Bob is a votecoin holder, and he votes on the outcome of a PM. His vote is still encrypted hashed .
Alice wants to learn proof of how Bob voted, so that she can create a punishment transaction and steal all his money.

This punishment transaction has the same information in it that is revealed when in Bob's reveal transaction.

If Alice was a mining pool operator, she could ignore Bob's reveal transaction, and use it's contents to produce a punishment transaction and steal from Bob.

I don't get the problem. All Bob has to reveal is his "vote+nonce"=vn that has created the hash he submitted earlier. If someone get access (before the voting period is over)to this "vn" he could change the vote (but not transfer votecoin). If he submits "vn" after the voting period (as he should) nobody gets access with "vn" to anything.

After all votes are revealed the RBCD (reputation based coin distribution) is done that assigns to all votecoin addresses a new value.

I don't understand where Alice (as a miner) could cheat in this process?

I am very emotionally distressed.
The new patch does not fix the bug. Neither of our methods are secure at all.
I think I am about to produce a proof that a secure prediction market on a blockchain is impossible.

I am sure - there are solutions for all these problems and I appreciate your work.

I thought about the problem and I think I have a simple and good solution.

The first vote of a voting period is done by signing a hash of the vote and submitting it into the blockchain.

1. You take your votes (Ballot) and add a random string
2. take a hash value
3. sign this value with your private key
4. submit it to the blockchain

The important part now is, that no the vote can be changed just by providing the votes + random string that lead to the hash value.

This solution would achieve the mail goal:
- voter would loose control over their vote if they reveal it early
and in addition no private key publication what be needed.

What do you think?

I like the idea of a snapshot of the Bitcoin distribution for the initial cash-coin distribution.
However, I would make a opt in process necessary afterwards. So the snapshot is done and afterwards every user has like 6 month to claim its cash coins. First, this would have a great marketing effect to get user to download and try out the client. And second, after the 6 month the uncertainty about how much cash-coins are in circulation is much smaller.

I think trade size is a function f1(b or k) and trade number is a function f2(interest in the event (i) + #of new information (since every new information should cause a trade))

All I am saying now is that for a reasonable assumption of f1 the result of f2(i+#) must be > 1000 to cover k from the fees independent of b.

This is because larger trades of two parties against each other can only be done this LOTS of small alternating trades. Maybe this can he hidden behind a user interface - but maybe the trading rules of truthcoin should change to allow large trades.

Well - a smaller k does not change too much since the trades gets smaller as well.

If I take your excel file (minimal example/ Hillary) and set b to 3 the capital required k is 2,07. Again - a trade that alters the % by 3% costs 10% of k. Assuming a 1% fee - that is still 1000 trades required just to reach k.

Thanks - I think this is helpful to have the option to play around with some values.

I noticed a bug: when I bought some shares (2000 on every event) the "change prob. to" is not working - see screenshot attached.
EDIT: hm, guess the attachment did not work. However - it should be easy to reproduce.


And I noticed one more thing: As a event author it will be VERY HARD to get your initial investment back.

Lets have a look at this example: the initial capital required is $415.88.
No lets make assumption how trading could look like. First lets assume that the "real prob." is indeed 25% for each team. However - people might have different opinions about the teams - but I think a realistic assumption would be, that people don't want to move the price more than 3%.

In this example this would be: buying 46 shares or spending $12.23. If the fee would be 1% (that is what we take at fairlay on average) the profit would be $0,12. To cover the initial investment of $415.88 3465 trades are needed.

Note that fees for event creation or fees for the votecoin holders are not even in this calculation. Of course the event creator only pays the full amount of the initial funding if one price converges to 1 and that event actually happens. But this should happen all the time the way truthcoin is designed.


Note that even if four parties are willing to predict large amounts at a price up to 0.28 on there team they can only do so by placing around small orders. And every one has an incentive to place a order as small as possible to not pay a higher price then necessary.

I think it would be necessary to place classical buy/sell orders in the truthcoin blockchain that either get active as soon as the market maker price goes below them or that could be matched by other orders directly.

Interesting observation!

What about starting an PM on the release date of truthcoin?

I would personally start "funding" it with a 0.5BTC prediction against it. Maybe 3 markets - in 3 month - in 6 month - in 9 month?

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.

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.

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?

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)

Actually I need to apologize for the part about truthcoin.

I had a very vague idea of truthcoin at this point in time and thus I could not really answer any question or phrase the project in a accurate way. I promise I will present truthcoin way better if I should talk about it another time.

More practically, I would be happy to join you for your next presentation, or as part of a "prediction market panel" or something.

That would be very nice! I do not know yet about a concrete opportunity but you would be more then welcome to join a session of the New York Bitcoin developer meetup to give a talk about truthcoin: http://www.meetup.com/BitDevsNYC/ It is every two weeks on Tuesdays.

As far as I understood: the valid blockchain is the blockchain where the most POW AND the most votes are put in.

from the paper: there is the timeline
5) Market Matures – votes are encrypted in the blockchain
6) Votes Decrypted – private keys are revealed

What an miner attacker with 51% could do: after the private keys are revealed: build up a new blockchain. Start in the latest block of phase 5) update all votes with the revealed private keys, (change votes to whatever he want - but more important transfer votecoins to own addresses)
Now he can build up a higher blockchain since it could have ALL VOTES and MORE HASHRATE

Did I overlook something?