Wager on Anything Using Bitcoin – Decentralized, Trustless Prediction Markets

Can you describe the usecase?

1) What adversarial analysis have you done to make sure that the reputation weighting mechanism can't be gamed, or the market making bot's funds emptied?

2) How do you handle miner censorship of vote revelations?

3) Why do you include floating point operations in the consensus code?

4) Have you considered separating the market-making aspect from the prediction market vote counting?

5) Have you considered implementing this proposal in an extended script directly, rather than monolithic opcodes?

Thank you, gojomo. We have talked to two of the authors of http://users.encs.concordia.ca/~clark/papers/2014_weis.pdf, and they were very helpful. Their proposed design differs from Paul Sztorc's in various key aspects. Scroll to the bottom of this page: http://www.truthcoin.info/faq/ for Paul Sztorc's comments on the paper to which you are linking above.

1). Good question. Paul Sztorc -- the inventor of the Truthcoin concept, on which Augur is based -- has been helping us a lot with game theoretic calculations. The Reputation concept's goal is to create a Schelling point on the consensus. You can construct a thought experiment, where you look at how the Reputation payoffs align with a perfect coordination game (with Schelling points). The result was that there is around a 90% chance that the Reputation mechanism creates a Schelling point. I don't have the details of this calculation, but I'm sure Paul and/or Jack (our project lead) could provide them if you're interested!

As for emptying the funds, we have the B parameter in LMSR vary according to volume. However, we're currently talking with an expert in automated market making (PhD @ CMU in CS w/ thesis in market makers) and he's recommending that we do not use LMSR (because new, advanced, market making algorithms have came out that don't allow issues like the one you mentioned come up).

2). I'm not exactly sure what you're asking here. We currently plan to encrypt votes using time lapse cryptography and then decrypt them via distributed key sharing.

3). SVD 0 and 1 work fine for binary outcomes, however when you include scalar predictions you have to fit the scalar values between 0 and 1 (because that's what svd operates on), hence floating point decimals. We're currently writing and implementation using fixed point, however, and that's probably what we'll end up using.

4). Yes we have, that was the simplest way to do it in a bitcoin transaction, however...

5) Absolutely, we're currently looking at Serpent contracts as a way to implement this (it looks like the biggest hurdle will be keeping SVD costs low, but so far it's progressing nicely)!