Hm, here is what is currently implemented:
It feels like it would be nearly the same.
How would your insurance agreement be settle, if both arbitrators X and Y are in the whitelist of the realitytoken, but if they produce different answers?
How would your insurance agreement be settle, if both arbitrators X and Y are in the whitelist of the realitytoken, but if they produce different answers?
That would be up to the contract but the obvious way would be to accept the first answer it receives. Filling out the insurance contract a bit more:
- Gets funds from Alice and Bob on branch A along with the question content hash representing "rain on Tokyo on July 1st", and assigns its own ID to the Alice+Bob agreement (either numerical or a hash)
- Stores those funds in its sub-account with its ID
- Alice and Bob can come back later and claim on any branch that they like, by sending the insurance contract the question ID of a question with the appropriate content hash ("rain on Tokyo on July 1st") and an arbitrator that's on the whitelist on that branch, which is favourable to their outcome
- Given a valid claim, the insurance contract transfers the funds on the branch they specified to the claimer.
- Once someone has claimed the funds on a particular branch (or its descendants), there will no longer be any funds to claim, so if you get a valid response contradicting a previous claim, but both are legal, there will be no funds left to claim
I see. The link between arbitrators and their fact is technically even a bit more separated. But in the end arbitrators are always judged by their facts. So it feels like the link will always be there.
It seems like in your solution the insurance contract is not bounded to a specific arbitrator policy. I mean different arbitrator would report facts differently depending on their policy. E.g. their policy could define how they deal with assassination markets or how they report prices in case of a fork. Hence, defining a arbitration policy in the insurance contract would make sense. It could be done directly by writing it into the insurance policy or by defining an arbitrator.
Hm I need to think a little bit more about the pros and cons. In your opinion, what is the major benefit of your proposed separation of arbitrators and facts?
Hm, one point of the vision of realitytoken is that it is the system/currency with the best arbitrators. They can be arbitrators for facts(realitycheck), but also for juridical decision(s.th. like kleos.) and maybe internal government decision( tokendistribution). So in fact the decision will be stored in many dapps anyway(realitycheck, kleos, etc.) I do not see this distributed storage of facts as a disadvantage.
Also I feel like the linking between the decision quality(facts) and the arbitrator list needs to be strong, in order to make the system work smoothly.
(Additionally, in your example, when arbitrator Y and X are both in the realitytoken arbitrators list, the dapps need to handle additional complexity on how to resolve these cases. I do not think that only the first realitytoken claimer should get funds. This additional complexity does not feels to be right)
My current implementation is not storing the data twice. If there is no escalation about the facts and no arbitrator is being paid, the facts are stored solely in realitycheck. Once a arbitrator is paid, the data is only stored in arbitratorData contract and read it int realitycheck by:
https://github.com/josojo/realitycheck/blob/master/truffle/contracts/RealityCheck.sol#L465
(The answer is received by looking up the arbitrator responsible for the current branch, and then get the answer from this particular arbitrator out of his arbitratorData contract. Everything is secured by a timestamp, so that if a arbitrator publishes anything after he is no longer an arbitrator on the arbitrator list of the branch, these data will not be recognized as given answeres)
Yes, I agree the linking is not a problem in neither of the designs. But since the linking always exists, we can, but we do not have to, separate it from a technical perspective.
If one does not use a wrapper for the arbitrator, this has one additional significant disadvantage:
Let's look at your example again:
- Weather insurance contract wants to know the weather as of day 10
- You make your insurance agreement on branch A of reality token on day 1
- Somebody makes a Reality Check question backstopped by arbitrator X, maybe someone else makes a different question backstopped by arbitrator Y
- On day 10, the answer is reported by the Reality Check Arb X question and the Reality Check Arb Y question. For these purposes it doesn't matter whether it was reported by somebody posting the highest bond, or whether someone asked the selected arbitrator to settle it
- On day 10, there is a branch A-A with arbitrator X, and a different branch A-B with arbitrator Y
- You can claim the funds from the weather contract on branch A-A, and also on branch A-B. If arbitrators X and Y gave different responses, maybe different parties will be claiming the funds on those different branches
If the arbitrator X was a good arbitrator over many years, but suddenly turns malicious between day 1 and 10, then the all the people bet on his correct answer in realitycheck will loose their money. RealityToken would only ensure, that the people bet on the weather contract get the right answer. But people betting in realitycheck on arbitrator X would loose their money, right? (They transfer money on branch A, and not matter whether branch A-A or branch A-B is valid, they will not regain access to these transfered realityTokens )
In my wrapper approach, even the bets on realitycheck will be secured by the realitytoken approach.