Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    AlexHerrmann(josojo)
    @josojo
    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
    AlexHerrmann(josojo)
    @josojo

    Over night I prepared a first look/draft of tokenized-events for the realitytoken eco system. It's super basic, but still I put some thought into it.
    https://preview.webflow.com/preview/alexander-herrmanns-first-project?preview=a3fa69b7a21677865395fe37a2eff727

    Contracts are also nearly finished.
    I hope that this enables everyone to quickly create long and short bets on any event. The long and short tokens could then be traded on exchanges like instex (it's like idex, but for arbitrary tokens.) This would have a much much better performance than any trading experience augur is offering their clients.

    Edmund Edgar
    @edmundedgar
    sweet, I'll take a proper look tomorrow
    AlexHerrmann(josojo)
    @josojo
    yeah, it's nothing special. It just gives me some imagination how it could look like/ work out
    Edmund Edgar
    @edmundedgar
    ah, it's gone...
    AlexHerrmann(josojo)
    @josojo
    https://preview.webflow.com/preview/alexander-herrmanns-first-project?preview=84e082a41b80d467190387e4e0cb16ea
    no idea why the link changed
    Edmund Edgar
    @edmundedgar
    I think I worked out how you could do a nice utxo system with this
    you could lock up some reality tokens from a particular branch in a different contract, which then starts making transactions looking like this:
    tx
    [
    -> input
    -> current_window
    -> arbitrator
    -> amount
    ]
    [
    -> output
    -> amount
    ]
    You could then validate a chain of utxos on any given future branch by making sure that each one has the full valid chain up to where you started, and that the arbitrator for that chain was on the whitelist at the right point
    If I've got this right, the chain should be unaffected by reorgs, unless the arbitrator that one of the utxos relied on had been removed by the reorg
    If you're using a utxo chain where all the arbitrators are valid, it wouldn't matter that there had been some reorg involving other arbitrators being added or removed
    Edmund Edgar
    @edmundedgar
    If I've got this right we could add this as a separate contract with no changes to our current reality token design
    probably a nice fit with plasma utxo chains, but I don't understand that stuff well enough to say
    AlexHerrmann(josojo)
    @josojo

    Ah, this solves the replication system within forward looking systems.
    In general I do not like utxo models, as you can not easily build smart contracts on them. Referring to some number stored in the realitytoken contract is so much easier than referencing to many utxos and splitting them.

    But the idea is good. Currently we are storing balance_changes(address=>amount), maybe we can store them differently balacne_changes(address=> arbitrator=>amount)
    ... hm just thinking out loud

    Edmund Edgar
    @edmundedgar
    whoa, maybe you're right
    AlexHerrmann(josojo)
    @josojo
    although this would make the amount_lookup costs higher
    if we want to know the amount stored on a person account, if we have more than 1 arbitrator
    Edmund Edgar
    @edmundedgar
    ah, yes, and also it breaks the layering, ie it builds in assumptions about how you settled your bet using a particular arbitrator
    (my utxo suggestion also does this, but I imagine it as a parallel system so the original one is still there)
    AlexHerrmann(josojo)
    @josojo
    I see
    AlexHerrmann(josojo)
    @josojo
    @edmundedgar Hey, could you please upload the code from London to github somewhere?Thank you
    Edmund Edgar
    @edmundedgar
    Yup, gimme a minute
    Edmund Edgar
    @edmundedgar
    OK, I think most of it's here: https://github.com/edmundedgar/tokenized-events/tree/london-tinkering/contracts
    btw I followed your example on structuring the realitio repo, now has an npm package called realitio-contracts etc https://github.com/realitio
    I've been cleaning up the token contract so it compiles etc, will also put it there with some examples reading the realitio code from the npm repo like you do with gnosis-contracts
    AlexHerrmann(josojo)
    @josojo
    great! thank you
    AlexHerrmann(josojo)
    @josojo

    @edmundedgar
    I am currently reading the book, the intelligent investor from graham, a very old classic. He keeps on pointing out that investing in assets such as gold is not so favorable, because gold is just a collectible and is not "working for you", as stocks do.
    Bitcoin and other cryptocurrencies are in some manner also just a collectible. The thought, which is kinda stuck in my head, is that actually, we do not need any cryptocurrency to keep a decentralized worldcomputer running.
    We could also create a decentralized index fond (DIF100) on ethereum, which would hold the top 100 most valuable ico's ( like the Nasdaque 100). This DIF100 could be a smart contract that holds these top 100 ico coins and issues DIF100-tokens representing an owernship in all the top 100 tokens.
    Now, these DIF100-tokens could be used for staking and for paying fees on the blockchain. And suddenly there is no longer any need for any cryptocurrencies.
    I think this is very valuable idea, as index fonds are just the better investment compared to a cryptocurrency, a collectible.

    Why do I write this to you? Because it also applies to the realitytoken concept. We could also create an index fund of companies, which profit from some oracle businesses. All these companies could issue some kind of token, which support the fork-economics protocol. I.e. they are easily forkable on the blockchain using subjectivocracy. These companies could be bundled in a decentralized forkable index fond (DFIF100). The tokens of the DFIF100 could then be used instead of realitytokens. This would give users of the eco system a much better protection, as DFIF100 would be a better investment as realitytokens.

    Edmund Edgar
    @edmundedgar
    wow, yes, I assumed every transaction using the subjectivocracy system would have to use the subjectivocracy token, but you're right, anybody could issue their token on a subjectivocracy system...
    You know how we made a separate tree to keep track of data on behalf of contracts? Maybe there's a generic design where you have an extra parameter expressing your token - basically just add a layer to a mapping. Then another contract could issue a token, and it would automatically work like our subjectivocracy token
    AlexHerrmann(josojo)
    @josojo
    Yeah, exactly. I will investigate on this before I start finishing some tests for our setup
    AlexHerrmann(josojo)
    @josojo

    Okay, I came up with a new reality concept based on forkonomics. I think it is better than a pure RealityToken concept, as it is not only currency , but also an indexfund generating static value.

    I imagine it in the following steps:

    1. Create the RealityToken, as discussed in London.
    2. Distribute RealityTokens to projects building on the platform, as dicsused
    3. Start an RealityFund: The RealityFund will be made of tokens supporting the ForkonomicToken protocoll. The forkonomicToken protocoll is basically that tokens are forkable each week, as it is implemented for the RealityToken.
      3.1 Add RealityTokens to the fund and make RealityFundtoken as the standard collateral token for the ecosystem.

    After the ecosystem has grown ( maybe in 2 years):

    1. Allow other tokens, which support the ForkonomicToken protocoll , to be added to the RealityFund. Hopefully, there will be tokens/companies issuing tokens, which will generate a steady income and use this income to make their token appreciating in value.
    2. RealityToken should become deflationary as well. Arbitrators might be required by a social contract to use x% of their winnings to burn RealityTokens

    After some more years:

    1. The RealityFund will hopefully support a variety of different ForkonomicTokens, spreading the risks of valuations out to many companies. Only a fraction of this fund is made up by the initial RealityTokens. This should give the RealityFund token a kind of stable value. Hence, it is a great collateral token to use the build ecosystems of dapps around this oracle system.
    AlexHerrmann(josojo)
    @josojo
    I know that it might be legally very challenging to build a fund of forkable tokens. AML, KYC etc, that will be all very hard. But that is why we are starting with a simple currency/utilty token: RealityToken. Then maybe at some point later, we will be able to advance the system with ForkonomicTokens issued by companies.

    I cleaned the code from London and put it into a form, such that it supports a RealityFund. You can take a look over here:
    https://github.com/josojo/subjectivocracy/tree/realityFund/contracts

    Basically the RealityFund token is used to decide about the arbitrators, create new RealityBranches etc. And each ForkonomicToken, one of them is RealityToken, uses the branch structure of the RealityFund to handle it's own balances.

    Edmund Edgar
    @edmundedgar
    This looks really interesting, I'll look through it tomorrow
    AlexHerrmann(josojo)
    @josojo

    Cool, please don't look to close, as there are still small bugs in the code.

    I am rewriting the plan, due to all these language mistakes:

    1. Create the RealityToken, as discussed in London.
    2. Distribute RealityTokens to projects building on the platform, as discussed
    3. Start a RealityFund: The RealityFund will be made of tokens supporting the ForkonomicToken protocol. The forkonomicToken protocol enforces tokens to support a weekly branching process. All branches created in the RealityFund are required to be supported by the ForkonomicTokens as well.
      3.1 Add RealityTokens to the RealityFund and make RealityFund-Token the standard collateral token for the ecosystem.

    After the ecosystem has grown ( maybe in 2 years):

    1. Allow other tokens, which support the ForkonomicToken protocol to be added to the RealityFund. Hopefully, there will be tokens/companies issuing tokens, which will generate a steady revenue stream. Tokens with a proper revenue stream, good business proposition should make it more attractive to people holding/using RealityFund-Tokens.
    2. RealityToken should become deflationary as well. Arbitrators might be required by a social contract to use x% of their winnings to burn RealityTokens

    After some more years:

    The RealityFund will hopefully support a variety of different ForkonomicTokens, spreading the risks of valuations out to many companies. Only a fraction of this fund is made up by the initial RealityTokens. This should give the RealityFund token a "predictable" value backed by real company shares. Hence, it is would be a great collateral token to use in this new oracle ecosystems.

    Main Advantage:
    RealityFund-tokens do have value even for people not believing in new currencies/ utility tokens

    Main Disadvantages:
    Forking or splitting a company is much harder than just forking a utility token. New company leaders need to be chosen and the duplication process of company resources should not be hindered by licenses and copyrights.

    Hopefully, we will see that the RealityToken system anyways will not split for a longer time period - only temporarily - and hence the ecosystem would very very rarely go through the pain of splitting companies.

    If you like this plan as well, I will put more focus on the coding effort

    AlexHerrmann(josojo)
    @josojo
    @edmundedgar
    Do you like the idea of a fund, or do you think it is impractical?