Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Edmund Edgar
    @edmundedgar
    I was in two minds about how tightly to bind this to Reality Check, but I guess if what we branch on is "trusted contracts", it could still be used for contracts that aren't Reality Check arbitrators, if that seems like a useful thing to do in the future
    just looking at this again, ArbitratorData implies that the subjectivocracy system is ruling on specific facts, what do you think about making it just be an arbitrator whitelist?
    AlexHerrmann(josojo)
    @josojo
    Yes I have not yet touched the tests. Frist O wanted to know whether the setup makes sense.
    Yes we can use other realitytoken and their arbitration system for any application, not just realtiycheck. But maybe arbitrators would need to publish which dapp they want to support.
    Edmund Edgar
    @edmundedgar
    So if that's right then we don't exactly need a data contract; Or we do, but the only data it holds is the arbitrator whitelist
    AlexHerrmann(josojo)
    @josojo
    Technically realitytoken decide only on the whitelist. But you are right, implicit they are deciding about the data published in arbitratordata. How can you make it differently? You always have a link to the facts, don't you?
    AlexHerrmann(josojo)
    @josojo
    I think the arbitrators needs to publish the decisions somewhere. This can be done on the dapp directly or in an contract arbitratordata. But it feels like the link is always there.
    Edmund Edgar
    @edmundedgar
    I don't think the reality token needs to directly know about facts
    So I'm thinking:
    Edmund Edgar
    @edmundedgar
    • 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
    So the facts all came from Reality Check, and people needed to ask the Reality Token about was which arbitrators were on the whitelist, so that they knew which facts should be believed
    AlexHerrmann(josojo)
    @josojo

    Hm, here is what is currently implemented:

    • 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 n in the arbitratorlist
      • On day 10, the answer is reported by the Reality Check Arb X question. For these purposes it doesn't matter whether it was reported by somebody posting the highest bond, or whether someone asked the selected n-th arbitrator to settle it
      • On day 10, there is a branch A-A with arbitrator X
      • On day 10, someone was not okay with the answer generated by realitycheck, a new branch is created with the n-th arbitrator being Y, called branch A-B
      • 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

    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?

    Edmund Edgar
    @edmundedgar
    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
    AlexHerrmann(josojo)
    @josojo

    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?

    Edmund Edgar
    @edmundedgar
    Well, the benefit is that it seems simpler, I mean, why put facts in 2 places?
    I guess the downside is that we can't actually control what people base their branches on, so they might end up having them report directly on facts anyhow...
    AlexHerrmann(josojo)
    @josojo

    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)

    Edmund Edgar
    @edmundedgar
    In the case where the reality token handles the data, what's the process by which it resolves conflicting claims about the same fact?
    Edmund Edgar
    @edmundedgar
    oh, I get it, it's my original design where all the facts are published to a branch
    If we're publishing the same facts to kleros/realitycheck and reality token too, I guess that means a lot of duplication
    ie same stuff in storage twice
    Edmund Edgar
    @edmundedgar
    I don't think there's a problem in the social layer with linking the facts with the arbitrator, people who think the arbitrator was wrong will be very keen to share that information, and it's also easy to prove that an arbitrator is responsible for a particular decision
    If the decision ia happening in realitycheck or kleros then you probably need to look at that application to understand the context for the decision anyhow
    AlexHerrmann(josojo)
    @josojo

    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.

    Edmund Edgar
    @edmundedgar
    OK, got it. I was thinking a branch would have multiple arbitrators on the whitelist, rather than just representing one arbitrator. That means a branch could still have contradictory data for the same fact (by content hash)
    AlexHerrmann(josojo)
    @josojo
    No, a branch can have several arbitrators. A question on realitycheck is asked against the "arbitrator 'nr n' on the realityToken arbitrator list". And then only one the 'nr n' arbitrator can arbitrate. But in another fork, the arbitrator 'nr n' could be exchanged.
    If the same question is asked against several arbitrators, the content hash can have several answers. Yes. But since in realitycheck there is this unique link between question and arbitrator, it should be all good.
    Edmund Edgar
    @edmundedgar
    So there are 2 different ways a contract can use realitycheck: It can either tie to a particular question ID, which implies a particular arbitrator, or it can tie to the content hash, which can be asked multiple times with different arbitrators. But with subjectivocracy, you need to be able to get an answer on any given branch, and you can't guarantee that the branch has the arbitrator you chose whitelisted, so you instead use the content hash, then a minimum bond and timeout. This is what getFinalAnswerIfMatches() is for.
    AlexHerrmann(josojo)
    @josojo
    Need to read getFinalAnswerIfMatches again. But in my implementation, there is a guarantee that the arbitrator nr n will be there. You don't know who will have the nth place on the arbitrator list, but you know that there will be one.
    it could also happen that a arbitrator is delisted without a substitution, but then that would correspond to the same event as the arbitrator corresponds "invalid".
    In the normal case, arbitrator would just be replaced with another arbitrator. Someone who would give the right answer to the question.
    Edmund Edgar
    @edmundedgar
    Hang on, so what are you actually setting as the arbitrator to realitycheck? Not the actual arbitrator but a wrapper contract for it?
    AlexHerrmann(josojo)
    @josojo
    yes, a number on the arbitratorlist
    it's no longer an "address', but a number in the list
    My assumption is that arbitrators stay in the list and keep their listing nr on the arbitrator list, until they make some bad decision. So, if a question is asked against a nr in the list, you will get the answer of this specific arbitrator, unless he reported something bad while your question was open.
    That means your question will only not be arbitrated by the "predefined" arbitrator, if the arbitrator had a reputation lost anyways.
    AlexHerrmann(josojo)
    @josojo
    I mean the arbitrator wrapper mechanism has advanatages and disadvantages. Disadvantages: wrapper could change the arbitrator and you question could be answered by someone else. Advantage: If the original arbitrator can no longer arbitrate (maybe be has a lawsuit or lost his private keys, still another arbitrator could be elected to arbitrate the bets made for a specific questionID.
    Edmund Edgar
    @edmundedgar
    Right, so I'm actually envisaging arbitrator contracts representing multiple parties, eg 3 companies, any 2 can settle, after a timeout any 1 can settle etc. And depending on the contract there may be a provsion for 2 arbitrators to replace the key of the third. But the thinking is that the user knows in advance who they are, or what their rules are.
    AlexHerrmann(josojo)
    @josojo

    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.

    Edmund Edgar
    @edmundedgar
    Yes, that's correct, my realitytoken requires participants to trust the arbitrator, whereas in theory the subjectivocracy approach could avoid the need to do that. But I think this is practical in that not everyone is going to want to go for the subjectivocracy approach, and it's probably harder to convince arbitrators to do this if they're getting paid in this very experimental token.
    For people who are convinced the subjectivocracy will work, I guess it should be fairly straightforward to make a way to insure against an arbitrator going bad
    AlexHerrmann(josojo)
    @josojo
    the arbitration fee could still be paid in a normal currency. Only the bets should be in realityTokens. The great thing about realityToken is that not the bbc or thomas reuter needs to be arbitrators, but people could even trust me with this approach. So convincing crypto geeks to become arbitrators should not be hard.
    Insurance has the disadvantages that it always costs some money.
    :) these fundamental decision are soo hard to make. Everything has advantages and disadvantages
    Edmund Edgar
    @edmundedgar
    yup
    maybe worth coding them both up including our sample weather insurance contract or whatever and seeing what they both look like
    AlexHerrmann(josojo)
    @josojo
    Yes, this would help to think things through
    You made already some example. Do you have the wheather insurance contract as an example as well?
    Edmund Edgar
    @edmundedgar
    no, I can't remember what my example was
    AlexHerrmann(josojo)
    @josojo
    k