The ultimate oracle

A solution for oracles will most likely be that an default (centralized) oracle can set an outcome first but there will be an objection period. If someone has an objection (and makes a deposit) another more reliable (and more costly) service should be triggered. If this option is given and the "last resort" oracle is widely believed to be 100% uncheatable than it might get never user.

So to have such an oracle would be extremely valuable.

So lets think about the "ultimate oracle" - the most secure one that can be made. For the security it is important to see what people who determine the outcome have at steak. In the case of Augur it will be the REP tokens, in the case of a human Twitter oracle it will be its personal reputation (maybe there is an real world value bigger than what is measurable on the blockchain but if we would purely look at the blockchain it would be the future income from this reputation - or other benefits that comes along with good reputation)

The ultimate oracle would want to make the amount as big as possible - so a radical idea would be: lets put potentially all Ether at stake. It could work super simple: if the ultimate oracle is triggered (only with a decent fee - payed by a) the first person that did the initial wrong settlement and b) a person who challenges the outcome) ALL ETHER HOLDER can "vote" by putting Ether on the outcome they think is the correct winner/answer.
So lets say we have a future dispute whether or not Trump was elected in 2016 - the first (wrong?) settlement said "yes" and is backed by 100ETH and than a objection fee is payed of 1000EHT on the right answer "no".

Now anyone could send money to "yes" or "no". The process stops if after lets say 48h "no" is still in the lead (more Ether is send to "no" in total. As soon as "yes" gets in the lead the process will continue for at least another 48h. If the frontrunner is not changed for 48h the result is set.

Why should this work? So in principal this is an symmetric game. What breaks the symmetric is that a) the truth is the natural point to coordinate on and more importantly b) the people betting on the truth can make a credible thread of forking Ethereum if they loose.
Because if it really gets big (and it could escalate quickly) the value of Ether in general is at stake. Who would want a system where just 30% (e.g.) of the total value of the currency was redistributed from honest voters to an evil alliance. In this extrem unlikely case the 30% would most likely just fork Ethereum from a state before this "disaster". I expect that to never happen because it will be way easier to coordinate on the truth and just to collect the "100ETH" the person gave as an security deposit initially.

Would it be possible to hunt for low liquidity markets and orchestrate small takeovers (say, use a 20ETH objection fee to override a 5ETH maket decision, if it doesn't work give up)?
The maker or oracle could invite everyone to vote, but it might be too resource consuming and if it fails (say, they attract only 85ETH in correct votes, and the attacker pays in 86ETH, losses might be even more significant.
For big & visible markets I agree it would be risky to do this, but for small if attacks could be automated based on data analysis (e.g. look for market maker addresses that have a history of low liquidity such as small markets with few participants) maybe they could be lucrative.

In our current implementation you would need to pay a significant deposit to trigger the "ultimate oracle". The deposit alone will attract enough people to pay attention to the market.

    /* ultimate oracle */
function voteForOracle(uint event_description_hash, uint16 outcome) {
    if(UltimateResults[event_description_hash] > 0 || ClosingAtBlock[event_description_hash] > block.number) {
        throw;
    }
    Shareholders[msg.sender][event_description_hash][outcome] += msg.value;
    TotalVoteAmounts[event_description_hash][outcome] += msg.value;
    TotalEventVolume[event_description_hash] += msg.value;
    if(TotalVoteAmounts[event_description_hash][FrontRunner[event_description_hash]] < TotalVoteAmounts[event_description_hash][outcome]) {
        ClosingAtBlock[event_description_hash] = block.number + DAILY_BLOCK_COUNT;
        FrontRunner[event_description_hash] = outcome;
    }
}

function setUltimateOracle(uint event_description_hash) {
    if(ClosingAtBlock[event_description_hash] < block.number) {
        UltimateResults[event_description_hash] = FrontRunner[event_description_hash];
    }
}

function challengeOracle(uint event_description_hash, address oracle_address, uint16 outcome) {
    if(!IsOracleChallenged[event_description_hash][oracle_address]) {
        IsOracleChallenged[event_description_hash][oracle_address] = true;
        FrontRunner[event_description_hash] = outcome;
        ClosingAtBlock[event_description_hash] = block.number + DAILY_BLOCK_COUNT;
        Shareholders[msg.sender][event_description_hash][outcome] += msg.value;
        TotalVoteAmounts[event_description_hash][outcome] += msg.value;
        TotalEventVolume[event_description_hash] += msg.value;
    }
}

I'd been thinking about something like this, too - I think it has a lot to recommend it. Basically you have the main meta-incentive of Augur without all the slowness and complexity and weird game-theoretic failure modes.

My main concern would be whether the Ultimate Oracle has a workable business model - like with Augur, if the value of shares (or in their case Rep) is too low it won't be trustworthy, which in turn means it's worth less, so it has the potential to go into a death spiral. You could partly mitigate this by taking another leaf out of Augur's book and denominating transactions in Ultimate Oracle stock, so if the value of the Ultimate Oracle (and thus the cost of attacking it) drops, so does the benefit of attacking it.

For smaller markets, you might be better if the Ultimate Oracle acted more like a meta-oracle, and just gave judgements on which other oracles were trustworthy at any given time. You could think of the oracles as certificate authorities (I sometimes describe Reality Keys as a Certificate Authority for Facts) and the Ultimate Oracle controlling a list of CAs and a revocation list. This has the effect of pooling the cost of a challenge among all the contracts that are using it. Otherwise lower-level oracles can still make money by lying, as long as the contracts their lies affect are worth less than the cost of a challenge. Or you could even just skip the challenge fee altogether and just have shareholders keep an eye on things to protect the value of their investment.

Oh - I don't think the ultimate oracle will be used at all - it is only the "credible thread" of it that will prevent regular oracles from lying. So - yes - I agree if we would use some tokens for the ultimate oracle those would struggle to have value. So we thought too just use Ether. Basically everyone with Ether is allowed to vote. Please note also that payouts from the prediction market are not done immediately after an oracle publishes an result. Only after a short dispute period where everyone (if they pay the security deposit) can trigger the ultimate oracle.

Secure Multi-Party Computation is how we can make the ultimate oracle. https://blog.ethereum.org/2014/12/26/secret-sharing-daos-crypto-2-0/

Even if the amount of validator-money at stake is significantly less than the amount of gambling-money, it still functions correctly.

The entire SMPC process, with the SVD algorithm from truthcoin can be written as lots of little off-chain rules. If a participant in the off-chain protocol breaks one of the rules, then it becomes possible for someone else to make an on-chain transaction that punishes the bad validator.

The off-chain state that validators in the oracle have under consensus is a merkle tree. So you can use the merkle root to make concise proofs to show who can be punished.

This is how oracles will work in the blockchain prediction market I am building.

@zack:

So the argument is that the participant (the votecoin-holders) can not coordinate because of SMPC?
But what about an additional contract that will pay a bounty to all votecoin holders if a specific result is reached? Or is the argument that the votecoin holders are unknown and therefore no one can "bribe" them?

The SMPC does make it more difficult for votecoin-holders to coordinate, but more importantly, it makes it impossible to bribe them.

Or is the argument that the votecoin holders are unknown and therefore no one can "bribe" them?

No that is not the argument. The list of votecoin holders is publicly known.

what about an additional contract that will pay a bounty to all votecoin holders if a specific result is reached?

Even if such a contract is made, the optimal strategy for a votecoin holder does not change. An incentives chart:

oracle outcome | truth | lie
you lie | lose votecoins | get judging fees and gain bribe
you true | get judging fees | lose votecoins and gain bribe

Each voter has control up-down, and no control left-right.
Consider what it looks like if a votecoin holder is gambling on his own bet:

oracle outcome | truth | lie
you lie | lose votecoins and lose bet | get judging fees and win bet
you true | get judging fees and lose bet | lose votecoins and win bet

Notice that it is the same thing as the bribe again.
If the market is popular enough, then votecoin-holders can create insurance for themselves this way to insure themselves against the randomness of bribes, resulting in incentives like this:

oracle outcome | truth | lie
you lie | lose votecoins and win 1/2 bribe | get judging fees and win 1/2 bribe
you true | get judging fees and win 1/2 bribe | lose votecoins and win 1/2 bribe