|
|
|
|
|
by maaku
4235 days ago
|
|
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? |
|
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)!