Just by reading this thread it makes me never want to gamble on sports without a judge. If I lost and then found out that I could either get 10% of my original bet back or screw over the guy who beat me... I might just screw him over because I'm pissed I lost and misery loves company. I mean talk about a lot of risk in getting a payout... a lot more risk than trusting a judge to make the call. Couldn't we have delegates providing feeds of certain events that end up dictating the winner and loser and dispersing the payout?
I agree. I think of it like BitAssets before the feed. We hoped the system would work without any price feed information put into the blockchain, but ultimately we had a plan to add it if necessary. I think we need a plan to add a judging mechanism for the prediction market to settle the bets. If it turns out we don't actually need it for the winners to nearly always get the vast majority (say >99%) of their winnings in a reasonable time, then great. Otherwise we have the judging mechanism to fall back on.
But I don't want to add this task to the already over-burdened delegates (plus it may have legal consequences). Let's just do it in a way similar to how Truthcoin does it. We would have special UIAs for each "Branch of VoteCoins" (to use Truthcoin terminology). When a user is setting up this prediction market BitAsset, they not only need to set the description, but also choose the Vote-UIA that gets to decide on the outcome, as well as the percentage fee (perhaps with min/max limits per trade) to charge on each trade in the market in order to collect a sizeable pool of BitUSD to incentivize the Vote-UIA holders. For the BitAsset market to become active, some percentage of that Vote-UIA need to agree to judge the outcome of that prediction market (which then becomes a liability for those Vote-UIA holders). The Vote-UIA holders than include their decision on that PM (which by default would be unknown) in future voting periods until the outcome has been resolved and forced liquidation of BitAssets with collateral (if the longs are the winner) or unlocking of collateral for free (if the shorts are the winner) occurs. If a majority of Vote-UIA do not vote unknown on the decision of a PM, that column will be included in the vote matrix for the voting period. The blockchain does the SVD of the vote matrix in each voting period and the reputation based coin redistribution of the Vote-UIA. The BitUSD fees collected in the pool can be used as automated buy pressure in the BitUSD/Vote-UIA market, providing the incentive for Vote-UIA holders to do these tasks.
Also, I have ideas on how to do the SVD in a smart way. There could be some time between voting periods for allowing the SVD result to be computed. The delegates would do the computation in parallel (it shouldn't take much time if we make the number of rows in the vote matrix reasonable by having a moderate transaction fee for each ballot submission by the Vote-UIA holders),
then once they have the result they would submit it to the blockchain (and the majority of the delegates would have to sign off on the result, likely by just adding their blocks on to the blockchain). The outcome (RBCR) would not immediately occur after submission of the result. There would be a small delay (anywhere from 30 minutes to 24 hours) which would allow the Vote-UIA holders to submit a claim that the SVD result is false. As the percentage of Vote-UIA claiming false results increases the delay increases from 30 minutes up to 24 hours. If within that 24 hour delay at least 75% of the Vote-UIA has claimed the result is false, then future voting periods for that Vote-UIA are put on hold until this issue is resolved. When a SVD result is called into dispute by a quorum of at least 75% of the Vote-UIA, a fraction of everyone's Vote-UIA is temporarily frozen. If the PM BitAsset longs and shorts for PMs that use that Vote-UIA as the judge are able to reach some consensus (details of the requirements for consensus TBD) that either the SVD result was true or was false, then something happens. If they reach a consensus that it was false, the Vote-UIA are unfrozen and furthermore some amount of BTS is printed (or alternatively taken from the delegates registration fee if we are operating under a model in which retired delegates could withdraw their registration fee after two weeks, which really makes the registration fee more of a security deposit) and used to pay out dividends to the Vote-UIA holders to reward them for catching the delegates. If they reach a consensus that it was true, then the Vote-UIA holders are punished for crying wolf by seizing their frozen Vote-UIA and gradually (to give time for arbitrage with other Vote-UIA markets and for interested parties to place their Vote-UIA buy bids) dumping it on the Vote-UIA/BTS market and destroying the received BTS as the dividend to BTS stakeholders. Actually, there is no need for any of that. If the delegates produce incorrect changes in the database because of a false SVD result than they are on an incorrect fork which the full clients can detect (just like with any other blockchain action). I guess if they submit a hash of the result into the blockchain after the delay it could allow the full clients to immediately know whether the delegates lied / are on a wrong fork. The delay is still important in my opinion because it gives the delegates and full clients a reasonable amount of time to do the SVD calculation in parallel without slowing down block production.
Haven't thought through all of the details of above carefully, but I think that should more or less do it. Each trader can judge whether they want to use the PM based on the credibility of the Vote-UIA set to judge it. Regardless of the initial distribution (assuming it is not too centralized) over time the RBCR should evolve the distribution into one that should be more trusted to make honest decisions. And PM participants can also judge the history of that group's decisions.
Edit: And of course since this is a lot of work, all of this is concerning possible post-1.0 features. We obviously shouldn't consider this stuff pre-1.0 when we have so many more important things to get done.