by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    AlexHerrmann(josojo)
    @josojo
    To be honest I thought about a lot of ways to get rid of the last_debit_window. It's bothering me.
    -> mimic tokens
    -> store all child branches to the parent branch to calculate is locally
    But in the end it does not seems so much more efficient. Especially since we can update with a RealityTokenNode easily and automatically to the newest branch, if the newest branch is not answering a new question, just creating a new branch.
    AlexHerrmann(josojo)
    @josojo

    I built a very first draft of the RealityTokenNode react app. It's quite fun, although I am quite bad at react.

    https://prnt.sc/ik497h

    Hoping that in such a way users can easily choose the "right branches" or "block of answers" and then the RealityTokenNode can serve the users choice to all the cool dapps, we could built with realityTokens.

    The very bad code can be found here:
    https://github.com/josojo/RealityTokenNode

    As a next step I will connect the RealityTokenNode to my testrpc and code the node logic for preselecting branches.

    Edmund Edgar
    @edmundedgar
    Sweet.
    So a key question is whether we're selecting bundles of facts or whitelists of arbitrators
    I'd been leading towards just selecting whitelists of arbitrators (which are contracts, so they may be centralized, they may be consortiums, they may be DAOs, whatever). I suspect that questions about the quality of their decisions will generally be driven by outrage - if you think a decision was wrong, you'll scream about it on social media - rather than people needing to check each individual question
    However, I guess you still need to somehow know which branches are forked based on which whitelists, and at what point they branched, for what reason
    Whatever mechanism we end up with needs to be resistant against people using spam etc to try to hide the information that might lead people to drop a bad branch
    AlexHerrmann(josojo)
    @josojo
    Oh yeah, we could see the realityToken as an arbitrator of the arbitrators. :) I also thought about having different escalation stages: 1.only doubling the bond a la realitycheck. 2. usual arbitrators 3. switching realities.
    Hm I have to think about it.
    AlexHerrmann(josojo)
    @josojo

    Hm, I was thinking quite a bit about bundles of facts vs bundle of arbitrators:

    bundle of facts:
    spam is prevented on the RealityTokenNode side by showing only facts and their answers which are following a specific rule set implemented in the RealityTokenNode. One of the rules would be that someone has to burn realityTokens to get his question included into the list of question, which should be answered by a new branch. This will limit the amount of facts, a user needs to decide about. Another rule would be that a new branch creator has to trade/exchange tokens from the new branch to the old branch, which will limit the amount of branches per window.

    bundle of arbitrators:
    each branch would maintain the a list of arbitrators. If a arbitrators decision is challenged for a specific question, then on a new branch would propose a new arbitrator/existing arbitrator as substitute for the challenged arbitrator. Also the answer of the new arbitrator would to the specific challenged question would be shown.
    Spam would be prevented also by a RealityTokenNode and it's predefined set of rules.

    is that how you would imagine the two different solutions? I am not sure whether I get the bundle of arbitrators correctly.

    Edmund Edgar
    @edmundedgar
    Yes, that's basically it. Switching an arbitrator could be because they got a particular question wrong, or because they self-reported a key compromise, or because they were caught taking a bribe, or whatever.
    AlexHerrmann(josojo)
    @josojo
    I thought again about the RealityToken distribution. I really like the idea of distributing tokens to people building dapps using RealityTokens and that the decision about who gets how much should be done via subjectivocray. But this process would take quite some time. In order to allow people to interact with the system from the start, we could allow a RealityToken lending, additionally. The idea is to issue realityTokens to a smartcontract, which will lend out the realityTokens against a Ether collateral. Then users get themselves tokens and would only have to return them after 1 year. This way we can bootstrap a ecosystem from day 1, but do not request users to make any investment, besides the capital costs.
    The main challenge for such a lending contract is to determine, on which branches the lender needs to return the realityTokens. Because the lender does not want to return realityTokens on branches, which are obviously fraudulent - and potentially only the attacker has lot's of realityTokens.
    In order to determine which branches are valid, I created a RealityMarket. Each time a new branch is created, also a big auction is created on a RealityMarket, in which the child realityTokens can be exchanged against parent realityTokens. From the prices in these auctions, we derive a decision function, on which branches are legitimate for the token lending. It was quite hard to find a good auction mechanism fitting these circumstances, but I came up with something.
    If you are curious, here is the code:
    https://github.com/josojo/realitycheck/tree/master/truffle/contracts
    ReailtyMarket, InitialLendingContract and the proxy contract might be of your interest.
    Edmund Edgar
    @edmundedgar
    This would work but I guess it would be simpler just to start with a dump of a bunch of tokens on the first day to be going on with
    I don't know what the economy will think should happen to tokens later on but I'd advocate the first chunk just going to a regular charity
    AlexHerrmann(josojo)
    @josojo
    But how would you dump/distribute them exactly?
    I really like the lending approach, since a viable RealityToken system will most probably have an active lending between ether and RealityTokens. Of course later one people might want to decided that RealityTokens is viable currency, but in the meantime, they will probably use it as a hedge against a possible fraudulent arbitrator in our system. In this short term scenario they will most likely do not want the whole exposure of the price volatility of ReailtyTokens and hence will just lend RealityTokens/ lend a hedge that an arbitrator does not report the truth.
    AlexHerrmann(josojo)
    @josojo

    @edmundedgar I tried to formalize a lending mechanism in the following document in the last paragraph. It is not perfect yet, and probably will never be, but it might be quite useful in practice.
    https://docs.google.com/document/d/10PW1jKpP5mWEQJqBOSjIjrkcYxSROwrI3XmsSGSFxCA/edit#

    The thing I am starting to release is that this pattern: creating a Token Curated List and use subjectivocracy for its governance system, as we do with realityTokens curating the lists of facts/truths, might be a very practical pattern that might be applied much more in the future. E.g. ens systems, list of correct arbitration, list of icos, which are securities, list of task that should be executed before allowing to interact with a dapp (think KYC verification) could all be such systems.
    Maybe we will first build dapps that are subjective to the TCLs, which the users are providing them and later dapps that are even subjective to governance/judicial laws logics the users are providing them.

    AlexHerrmann(josojo)
    @josojo

    HI @edmundedgar ,

    I decided that I want to build a event-tokenizer in my free time. It would be so cool, since it would allow so many use cases.

    But before I can start I would need to have the basic contracts of realitytoken/realtiycheck written. If we could agree on some basic contracts that build the basis for the ecosytem that would be great. I put a lot of effort to make a first proposal. The following code follows all our thoughts during the hike. If you could review that would be great:

    I made a pull request resembling all the most important basic contracts. They are only modified slightly in order to fit the arbitratorList model, instead of the factList model.
    realitykeys/subjectivocracy#3

    All these smartcontracts are also published here for easy inclusion in other projects:
    https://www.npmjs.com/package/@josojo/realitytoken-contracts

    With these smartcontracts I rebuild your realitycheck system. It works so great! Please let me know whether this implementation matches your ideas? I need to have the basics for this as well in order to build the event tokenizer, since I want the event tokenizer to ask the questions against realitycheck.
    https://github.com/josojo/realitycheck/blob/master/truffle/contracts/RealityCheck.sol

    The process on how the escalation is being done is illustrated by this test:
    https://github.com/josojo/realitycheck/blob/master/truffle/test/ExemplaryWorkFlows.js
    (All the tests are passing here)

    Once you reviewed the concepts I am willing to write more and more tests for the smart contracts.

    Edmund Edgar
    @edmundedgar
    Wow, had a quick glance and that's looking great, but I'll have a proper look through it tomorrow
    AlexHerrmann(josojo)
    @josojo
    :smile: I am curious on your thoughts.
    Edmund Edgar
    @edmundedgar
    Accepted the pr for now, need to fix up the tests - looks like I forgot to include a requirements.txt for the python and now they're not running from me on my laptop, will work that out and see what we need to do
    Also need to update the whitepaper to talk about using subjectivocracy to handle arbitrators whitelists, rather than directly against bundles of facts
    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
    Edmund Edgar
    @edmundedgar
    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.