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.
-> 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.
I built a very first draft of the RealityTokenNode react app. It's quite fun, although I am quite bad at react.
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.
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.
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.
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.
@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.
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.
- 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
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?
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.