The ultimate oracle

mkoeppelmann 2015-10-15 20:13:29 UTC #1

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.

agnostic 2015-10-16 06:19:10 UTC #2

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.

mkoeppelmann 2015-10-22 07:38:13 UTC #3

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;
    }
}

edmundedgar 2015-10-23 00:52:49 UTC #4

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.

mkoeppelmann 2015-10-23 04:01:20 UTC #5

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.

zack 2015-10-30 20:41:44 UTC #6

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.

mkoeppelmann 2015-11-01 23:39:32 UTC #7

@zack:

zack:

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.

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?

zack 2015-11-02 16:23:13 UTC #8

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:

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:

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:

zack 2016-07-17 18:31:13 UTC #9

SMPC is an unnecessary complication.
Vitalik Buterin proved that P+epsilon attacks aren't an issue.
Any contract that implements a P+epsilon attack has a counter-contract that stops the attack and steals the money from the first contract.

mkoeppelmann 2016-07-18 16:40:48 UTC #10

@zack - so you assume the ultimate oracle is working as it is planned now?

zack 2016-07-24 00:39:54 UTC #12

github.com

BumblebeeBat/FlyingFox/blob/master/docs/colored_lightning.md

Colored lightning means having different colors of lightning channel networks on the same blockchain.
So if you start with coins, you can convert some of them to red coins. coins can be sent through channels, and red coins can be sent through red channels. Then later you can convert the red coins back into regular coins.

So if you want a dapp that involves 2 colors of coins, then people will need to have at least one of each color of channel.

Colored Lightning allow us to move a greater variety of computation off-chain into the state-channels. Specifically, it lets us move prediction market judgement off-chain.

It is also a lot more affordable than the existing on-chain mechanisms, [as explained here](cheaper_alternative_to_reputation_truthcoin.md)

Colored channels solves a problem inherent to channels. If there are >2 nodes in a channel network dapp, it isn't possible to enforce that money gets deleted in a channel you don't control. So in a simple example, if Bob, Charlie, and Alice had channels in a triangle, Bob couldn't be sure that Alice and Charlie are actually deleting money in their channel.
Alice and Charlie might be splitting the money they are supposed to delete, and keeping it.

This is an important problem for oracles. If the participants in an oracle should do a 51% attack and steal the gamblers' money, we need a way to make sure the reputation from the reporters becomes worthless.
If the reporters use a single color of channels to be the rep, then the validators can censor the tx that converts the colored coins back to regular coins, which makes the reputation worthless.

In this way, we can be sure that money gets deleted. So it is possible to make cryptoeconomically secure oracles in the lightning network.

I still think reputation/votecoins is a very expensive mistake.
We need the security deposit that protects the markets to change size based on the size of the markets.

zack 2016-07-27 04:50:44 UTC #13

I realized a limitation on how fast oracles can judge over a volume of bets.

github.com

BumblebeeBat/FlyingFox/blob/master/docs/oracle_finality.md

blockchain consensus mechanisms have an idea of finality. That is how many blocks deep into history a block has to get until we are certain that it is in our history, and wont disappear in a fork. It is also the amount of time that validators need to leave their money locked up.

Oracles also have an idea of finality. It is the amount of time that reporter's safety deposit needs to be locked up after a judgement.

The minimum rate of cost of operating an oracle is (the sum of all the money judged over during the last finality period) * (the interest rate)

If we use the blockchain validators for part of the oracle consensus mechansim, then the oracle finality period needs to be long enough in the future so that the blockchain validators can realize the scandal of a lying oracle and react to it.

The maximum amount of judging that can happen in one oracle-finality period is 1/3rd as much as the amount of money that reporters have locked up.

In the case of Flying Fox, the oracle-finality period will be decided by the validators. I am planning to start it off at 48-hours.

If we could get 12% of the money on the blockchain participating in the oracle, then that means we could judge over about 2% of the money every day.

If a massive bet went through that used 60% of the money on the blockchain, it would take 30 days to be completely judged over.

zack 2016-09-14 19:52:43 UTC #14

I think that you don't even have to put the Ethers at stake. Taking a weighted vote is enough.

mkoeppelmann 2016-09-14 20:29:11 UTC #15

I think the incentives to participate in the vote are too small to have voting as a reliable mechanism.

zack 2016-09-14 21:01:56 UTC #16

One person reports the result, and gives a big safety deposit.
The ultimate oracle only happens if the reporter lied.
If the reporter lied, then his safety deposit is deleted.