Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    AlexHerrmann(josojo)
    @josojo

    Yes kinda, each subchain introduces with its own process its own information. This information introduced by a subchain will only be available in the subchain, but still, later on the mainchain must decide which branch of a subchain will be the "truthful" branch.

    The big advantage of this approach is:
    Even if is there is a big controversy about a fact in another subchain I can still keep on transacting in my own subchain, without having to make decision. See the picture: Left chains can keep on transacting, while there is a controversy on the right most chain. People in subchain can simply wait and see how the decision finding develops and do not have to participate actively in the decision finding. Only eventually, when they want to withdraw to the mainchain.

    In your system, I would have to make a decision, on which chain I want make any transaction. This should improve usability a lot.

    Edmund Edgar
    @edmundedgar
    In your system, I would have to make a decision, on which chain I want make any transaction
    Well, you could just transact on both chains
    However, I guess the point is you may want to say, "send this tx on any chain where y is true"
    I think it would also be possible to make an intermediate contract that allowed you to say "approve these funds for transfer on any chain where x is true"
    Second, I think it would be very beneficial to allow many different process to find consensus about information ON CHAIN.
    AlexHerrmann(josojo)
    @josojo
    Yes, something like this would help the system and the usability, I think.
    Edmund Edgar
    @edmundedgar
    Consensus about information on-chain can be drawn from an inter-chain market (highest value = true) or any other DAO or whatever that chooses between branches. Do we have a better way to do this with subchains?
    Edmund Edgar
    @edmundedgar
    Hey @josojo do you want to do a call tomorrow or the day after and talk me through your ideas?
    AlexHerrmann(josojo)
    @josojo
    Yes I found it hard to engineer an Oracle-DAO for your system. There were two reasons:
    1. Escalations process engineer in smart contracts of a subchain can easily slash people behaving badly and they can also charge fees easily. That helps a lot. I think building this on your system might be possible as well, but it would be harder.
    2. Having one DAO for all information feeds is hard to engineer. But if you have several, there was no easy way to distinguish whether the DAO would have to for a specific question the competence to answer it. But if questions are asked on subchains, it is clear, which process should introduce the right information.
    Sure we can have a call tomorrow
    How about 7 CET? I should quite flexible
    Edmund Edgar
    @edmundedgar
    07:00 CET works great for me
    Edmund Edgar
    @edmundedgar
    So one thing I've been pondering on: We currently have a restriction that you can only create a branch for the current window. That potentially makes the timing of asking questions and settling on them a bit fiddly, especially if the window period is long (currently thinking 1 week, although the sample code is 24 hours)
    Would there be any downside to making it possible to create any branch for any window, as long as someone has already published the parent branch?
    ie I can go ahead and create a branch premised on "You will trust arbitrators x, y and z next week", and you can make a claim on that branch as soon as your data is published there
    Of course if you accept coins as of some future week, you don't know whether the branch you're accepting them on will later turn out to be bad, so you're taking a risk that they may be worthless, and you may prefer to wait until the end of that week, or later
    AlexHerrmann(josojo)
    @josojo

    For which use cases would this be interesting? Probably for all, where people do not want to wait 1 week for resolution and they can make the mentioned security compromise, right?

    Do you think something like this would be possible?
    Assume our dapp wants to know the weather in Tokyo on day 5 in week X. Usually we would ask the question: what will be the weather on day 5 in week X and would get an answer in week X+1. Instead, we could also ask: Where will abitrator z publish the weather feed for day 5 in week X. THe answer will be a smartcontract address for a smart contract, where only the arbitrator has access and can be included in week X. If the dapp asking for the weather checks then the smart contract on the address published for the answer and allows a withdraw on window of week X after the arbitrator put in some answer into the smart contract, we have the solution to your problem.

    Is that right? I am not sure whether I understood the challenge correctly. Maybe you were also looking for a less complicated solution.

    AlexHerrmann(josojo)
    @josojo

    HI,
    Finally I have found some time to code a first draft of the realityCheck with the arbitrator RealityCoin.

    It is not yet ready. But at least it would compile if there wouldn't be the restriction of the stack size. I will fix it when I find time for it.
    https://github.com/josojo/realitycheck/tree/master/truffle/contracts

    Idea for Implementation:
    Instead of staking Ether in the RealityCheck, we do stake RealityCoins from a specific branch. In almost all cases, the bond doubling will find an answer to a question. But in case there is a disagreement between two bonders with a lot of stake involved, they can ask the RealityToken to create a answer by paying some fee in RealityTokens. Then the RealityToken will include an answer to the specific question in a next branch. Then this submitted answer will be used to resolve the conflict of the fighting bonders. The trick is that on separate branches different answers can be available and hence the withdraw of claimWinnings will reward different people on different branches.

    I know Edmund developed this concept mostly for information arbitration. But I am very convinced that people will find the concept of arbitration with subjectivity very useful in all kind of context. It might become the fairest court of the internet.

    Basically I only modified the RealityCheck contract and most of the modifications were quite straight forward.
    The only tricky modification I needed to make was the following function:

        // @dev: this function checks whether a branch is eligible for a withdraw. 
        // if a withdraw was already made on a newer childbranch of branchForWithdraw, it will return false
        // if there is a closer parentbranch that the branchFromPreviousWithdraw we throw as well
        function eligibleBranchForWithdraw(bytes32 branchForWithdraw, bytes32 branchFromPreviousWithdraw, bytes32 branchFromQuestion, bytes32 [] alreadyUsedBranches)
        public view returns(bool isEligible)
        {
            for(uint i=0;i < alreadyUsedBranches.length;i++) {
                if(realityToken.isBranchInBetweenBranches(branchForWithdraw, branchFromQuestion, alreadyUsedBranches[i]))
                    return false;
                if(realityToken.isBranchInBetweenBranches(alreadyUsedBranches[i], branchFromPreviousWithdraw, branchForWithdraw))
                    return false;   
            }
        }

    which is called in the claimWinnings function.

    @edmundedgar How is it going? have there been any new insights about the RealityToken concept? I am still super excited about this project and I want to be a helping hand for this project in my free time for sure. From March on I will have more free time than before.

    Edmund Edgar
    @edmundedgar
    Doing great, just got the audit of the RealityCheck contract done, still waiting for the report but they didn't find any serious bugs so it should be lie on mainnet pretty soon.
    Next step is
    1) Sign up some other arbitrators
    2) Get my head back into the subjectivocracy part
    AlexHerrmann(josojo)
    @josojo
    Sounds great! It's so exciting to go live with a dapp after one worked so hard and long on these little babies!
    AlexHerrmann(josojo)
    @josojo

    Yeah, the realityToken has done it's first arbitration for realitycheck on my local testrpc! Exciting :smile:

    Who is interested, take a look:
    https://github.com/josojo/realitycheck/tree/master/truffle
    https://github.com/josojo/realitycheck/blob/master/truffle/test/ExemplaryWorkFlows.js
    But of course it's far from ready.

    I implemented the following:
    -RealityCheck.sol, which is able to take RealityTokens as collateral tokens
    --every information feed request with RealityTokens as arbitrator costs some RealityTokens fee
    -- every arbitrationrequest for RealityTokens burns more RealityTokens in the realityCheck contract.
    -RealityToken, the first opinionated blockchain
    --Initial Token distribution and especially ongoing token distribution can be governed by subjectivocracy
    --Critical parameter of the RealityTokens(e.g. arbitrationrequest costs, supported Dapps, etc) can be governed by subjectivocracy as well
    --Creating a new branch is no longer free: The branch creator will lose some funds in the parent_branch, but gets more funds in his proposed branch
    (These design decision were mostly driven by the urge to limit the creation of new branches. New branches should only be added to the system, if there is already a consensus in a small subset of the community to support a particular branch. This will enhance the user experience of the coin a lot, in my humble opinion)
    -TODO: RealityTokenNode, a client side web application that supports the user to pick the right branch
    -- Besides giving the user the opportunity to choose the right branch, the RealityTokenNode will also have logic implemented on which branches a users should be able to choose from:
    --- if there are several branches with the same answers, the RealityTokenNode will calculate with a metric which one should be picked
    --- Only branches will be accepted which do inflate tokens by predetermined forumla - every half a year some tokens are distributed to projects helping the ecosystem
    --- Only branches will be accepted, which do answer questions for which enough realityTokens were burnt.
    --- ...

    We never talked about a RealityTokenNode software. But I am convinced that we need something like in order to have cheapest and most efficient opinionated blockchain on the ethereum chain.

    Edmund Edgar
    @edmundedgar
    wow, just trying to get my head around this
    Edmund Edgar
    @edmundedgar
    On the part where we're making a cost to create a branch, would this work kept out of the contract but put in the social + UI level, eg make a social rule that "if you expect your branch to be taken seriously, you should offer x tokens from the parent branch for sale in exchange for tokens on your child branch"
    The advantage of doing it this way is
    1) less code in the core contracts
    2) easier to upgrade the mechanism (since it's basically social)
    So in the UI, whatever DApp was showing you candidate branches wouldn't even bother showing you a branch unless it could look at a token auction contract and say, "I can see that someone has offered to buy tokens on the branch you're making at a cost of > x% of the price of coins on the parent branch"
    Edmund Edgar
    @edmundedgar
    Or is the goal to restrict the number of possible branches to make it possible to traverse all branches from both directions, so we can do something smarter than the last_debit_window restriction?
    AlexHerrmann(josojo)
    @josojo

    The concept of selecting branches in the social+UI level is quite powerful. I was not really not aware two weeks ago.

    Nevertheless I decided for the hardcoded token burning mechansim on the parent branch for creating a new branch. The reasoning is that new branches on new windows, which are unnecessary, can be very inconvenient for users while using the Dapps.
    Here is an example: Suppose on realitycheck there was a escalation quite large and the first claimingWinnings was not able to process all history items on window n. If someone creates a new fake unrelated branch and does a withdraw from realitycheck on window n+1 with this branch, then the continuing of the first claimingWinnings can not be done, unless someone creates also a branch on window n+1. This might be hurdle. This kind of enforces users to create more branch than is really needed. I hope that with the current implementation a new branch does not happen more often than really needed.

    While writing this reasoning down, I see the weak point: Once there is a non-accepted branch with realityTokens kind of worthless, someone can disrupt the system anyways by burning the worthless realityTokens and thereby creating a new branch on newest window.

    I am getting more and more in favor of the social+UI solution.

    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?