[PM] Reserve OutsiderBond for report, when the oracle fails to report

[Chralt98]

Fixes #868. Fixes #698.

[Chralt98]

Waiting for #892 to use the approach for tracking bonds.

[maltekliemann]

Yeah, nice. Couple o' nitpicks, but nothing really problematic.

[maltekliemann]

I see one scenario which bothers me. What if the market was misconfigured and the market ends too soon so that there's no outcome to report. The oracle solves this problem by not reporting (seems like the best course of action available to the oracle). Then some outsider ignorantly reports something, a dispute ensues and in the end, both are slashed. Seems unfair to the oracle, which always acted with good intent.

What I'm getting at is that this setup is incentivizing the oracle in this situation to report a random outcome in the hope of guessing the correct outcome so that it doesn't get slashed. Even worse, if the oracle is smart, it will probably "guess" the outcome with the highest prediction.

I don't think that there's anything we can do about this here. The problem is, of course, that we don't have a good method of handling markets that resolve too early. What's annoying about this particular situation is that even if our dispute system has a means of delaying the resolution of a market, we still need to trigger a dispute in order to delay the market. But the dispute can only be triggered if someone has reported.

So the request to delay would actually have to come before an outsider can report. Which brings me back to my original suggestion in ZIP-0: "Immediately initiate dispute if the oracle fails to submit a report [in time]" (https://hackmd.io/i326HLsNQTWG8NcIriTwdw#Immediately-initiate-dispute-if-the-oracle-fails-to-submit-a-report).

[Chralt98]

I see your point. T

What if the market was misconfigured and the market ends too soon so that there's no outcome to report. The oracle solves this problem by not reporting.

The implementation before this PR had this problem too. The oracle had oracle_duration time to wait until an outsider could ignorantly report an outcome.

Seems unfair to the oracle, which always acted with good intent.

So the main problem is how to recognise that a market ended too soon. If we could find a solution for this, we could extend the oracle duration.

What I'm getting at is that this setup is incentivizing the oracle in this situation to report a random outcome in the hope of guessing the correct outcome so that it doesn't get slashed.

I see. Yeah, we should better find a way of making the oracle duration more flexible as described above.

What's annoying about this particular situation is that even if our dispute system has a means of delaying the resolution of a market, we still need to trigger a dispute in order to delay the market. But the dispute can only be triggered if someone has reported.

Exactly! We should find a way to delay the market beforehand. So that we have both worlds: Allow a delay by the MDM and by some force which knows when a market couldn't have a final outcome at this time.

Ok, let me brainstorm: your approach (initiate a dispute) suits it well I think. But how to determine whether an oracle forgot to submit a report and an oracle which by purpose did not report because the final outcome was not present?

So we need to either unreserve or slash the oracle bond based on that. When we say: always unreserve the OracleBond when the oracle did not report in time, then the oracle does not get slashed even in the case that the final outcome was present and the oracle just forgot to submit it or worse: by intention.

Another approach: Just let the oracle delay the oracle duration itself. If the advisory committee disagrees on the delay, then the oracle bond gets slashed.

[maltekliemann]

But how to determine whether an oracle forgot to submit a report and an oracle which by purpose did not report because the final outcome was not present?

I think this boils down to whether or not the dispute was justified. In other words:

• If the report period ends, the oracle didn't report and the MDM decides that the report needs to be delayed, then the oracle acted correctly and is not punished.
• If the report period ends, the oracle didn't report and the MDM decides that the market should resolve to outcome A, then the oracle is punished.

But this results in problems if the outcome becomes known between the end of the report period and the end of the dispute. I'm okay with the oracle getting punished in this situations. There are always going to be loopholes and people thinking they've been treated unfairly.

Another option would be to let the MDM decide whether or not to punish the oracle.

Just let the oracle delay the oracle duration itself. If the advisory committee disagrees on the delay, then the oracle bond gets slashed.

That's kind of like raising a dispute with authorized as MDM, right? For advised markets, this would be perfectly fine. In that case, it's the AC's fault that the market wasn't correctly configured. For permissionless markets, this puts too much power in the AC's hands. In this case, I would really prefer a dispute.

I think this warrants it's own ZIP. It definitely doesn't belong into this PR.

[Chralt98]

and the MDM decides that the report needs to be delayed

How would you let the MDM decide whether a report needs to be delayed? In case of authorized it's clear, that the advisory committee could call a new extrinsic which determines that. We need to properly define new requirements here for authorized and court. How does the delay agreement look like in detail. Who decides how, that a report delay is justified. It feels pretty general especially in the case of court that the MDM just decides. Who, how, when, what?

Yeah, I agree, it seems like a whole own ZIP.

[Chralt98]

One thing to keep in mind with this is that the oracle should propose an outcome. Otherwise I could as market creator just set the oracle duration to the minimum and just wait with my oracle outcome submit until the oracle duration is over to eventually get my bond back. Market creators are then incentivised to set the periods incorrectly so that it's justified that the market ended too soon.

[Chralt98]

#956

[maltekliemann]

Just realized that you should also document the new functions.

[maltekliemann]

About the outsider bond. Anything >= 2 * OracleBond::get() should be fine to prevent dumb guessing, but the question is if it should be even higher. Disputes currently cost ten times of the oracle bond.

[Chralt98]

Just realized that you should also document the new functions.

I only see the macro function "impl_is_bond_pending" which comes to my mind. Which functions do you exactly mean? 3d5543e

[maltekliemann]

I'm concerned about the use of the question mark operator here. I know you didn't start this, but I'm just making an observation. I think we're not handling failure to resolve very well. Right now, if any of these question mark operators actually cause an error, the market fails to resolve and becomes a zombie market, right? This essentially means that every application of the question mark operator here is not a runtime error, but a logic error. If any of these trigger, we've made a mistake. Seems scary.

We may or may not have some markets with outsider reports but without outsider bonds. This is fine because slash_outsider_bond is only called if it is actually pending (we'll log a warning, but that can be disregarded).

Not really sure what I'm getting at here, just pointing this out. 🤷‍♂️

[Chralt98]

I see your point. This is essentially also my concern about resolutions. There are many places inside on_resolution where the code potentially could throw an error. That's why we used the approach of is_outsider_bond_pending here and are logging the warning. Whenever we add some error case to slash_outsider_bond it is not covered by is_outsider_bond_pending anymore. But with the current solution there is no way slash_outsider_bond could fail, because the assumptions are ensured in the if statement above.

This is covered by the mentioned if statement and the market existence is covered by the resolution_manager here.