Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Edmund Edgar
    @edmundedgar
    in theory I don't need to store anything that's hashed in the question ID because you could make the user supply it, but again it makes it look complex to call
    well true, the bond part is probably just going to happen from the dapp or whatever
    the bit contracts want is getting the final answer
    josojo
    @josojo
    yeap...
    Edmund Edgar
    @edmundedgar
    and the getFinalAnswerIfMatches workflow already requires the user to pass in a matching question ID
    so maybe it wouldn't be such a big deal to make them pass the rest
    josojo
    @josojo
    hm have to think this through...

    Another quick question:

    the variables in the claimWinning function:

            question_claims[question_id].payee = payee;
            question_claims[question_id].last_bond = last_bond;
            question_claims[question_id].queued_funds = queued_funds;

    are they stored with these commands in memory or is the opcode MODSTORE here already called?

    because if this implies an MODSTORE, then it would make sense to offer an claimWinning that does not store these variables and only succeeds if it runs through with one go.
    Edmund Edgar
    @edmundedgar
    So if you call claimWinning with the full history in one transaction, none of it is stored, it just reads them at the beginning and sees they're not there
    However we can't be sure you will call in one tx because
    1) gas may be over block gas limit
    2) lowest bonds may be uneconomical to claim
    3) lower bonds may benefit someone else, and you don't want to pay to assign them
    josojo
    @josojo
    my fault... you are right, they are only stored if it does not run through.
    good then its cheap already
    Edmund Edgar
    @edmundedgar
    but only claiming partway costs 3 storage writes and you don't get the history clearance refund, so normally you would do it all in one tx
    even if that pays someone else
    you'd have to have quite a monster long history to want to split into multiple txes
    josojo
    @josojo
    right, think so too
    Edmund Edgar
    @edmundedgar
    overall I think gas costs were normally something like:
    • ask question: a little over 100,000
    • first answer: about 100,000
    • subsequent answers: about 50,000
    • claim: about 50,000 net but you have to set a higher gas limit because the refunds only get handled at the end
    I optimized for making subsequent answers cheap, because if someone puts in a wrong answer you have to get a transaction through before the timeout. It's a bit nasty because the wrong-answering attacker gets to choose the timing, eg they can send their tx right before an ico so the defender has to get their tx through during the ico
    josojo
    @josojo
    sounds very reasonable. :+1: thumbs up:
    Edmund Edgar
    @edmundedgar
    Deployed the Reality Check contract to the main network, but this is so it can be audited in its final form, nobody use it yet...
    https://etherscan.io/address/0x007112089f32c0fb6cc1921d4877c2c97270c5ab#code
    Christopher Scott
    @McKean
    good day! Just stumbled over your project reality check and I am wondering what the state of this is. Are you pursuing this?
    Edmund Edgar
    @edmundedgar
    Thanks for stopping by, Christopher. We certainly are, the DApp is ready to go and the auditor is currently trying to find bugs in the contract. If we get the OK auditor it'll go live, if not we fix the bugs then repeat the cycle.
    Next things on the TODO list going forward will then be:
    • Letting people know about the contract / app
    • Helping people set up contracts using it as a data source
    • Filling out the options for arbitrators, beyond just Reality Keys
    • Bringing out a subjectivocratic token so that you can use Reality Check without trusting the auditor
    josojo
    @josojo

    Hey,
    I am currently talking to a technical engineer of the BBC. They want to get involved into Blockchain technology and are seeking out for partners to build prototypes for potential usecases. @edmundedgar Would you mind, if I am sharing your dapp with them? I think they would be a great arbitrator in your system.

    I would like show the dapp to them, because I think it a opportunity for them. Although it seems that they are more interested in being a general feed publisher at this point. If you are interested, we I could also connect you directly.

    Edmund Edgar
    @edmundedgar
    Yes, please do show them. I'd also love to talk to them if you can hook me up with an introduction
    Edmund Edgar
    @edmundedgar
    The bug bounty for the main Reality Check contracts is now live:
    https://medium.com/@edmundedgar/reality-check-bug-bounty-46054a94820e
    sumukhshetty
    @sumukhshetty
    was reading about reality check and had a question. Isn't there an issue of someone being able to make the final bid if they have a large incentive in changing the truth that the oracle proclaims ?
    Nikete
    @nikete_twitter
    @sumukhshetty there is no way to guarantee your bid will be the final one; so you are always exposing yourself to someone with a bigger wallet coming along and correcting it
    @edmundedgar is there anything beyond the medium post on the subjectivocratic token so that you can use Reality Check without trusting the auditor?
    josojo
    @josojo
    @nikete_twitter there is the devcon talk of edmund and come join the channel here:
    https://gitter.im/realitykeys/token
    And take a look at:
    https://github.com/realitykeys/subjectivocracy
    We are currently redesigning the realitytoken a little.
    Edmund Edgar
    @edmundedgar
    @nikete_twitter We have code and talks on the subjectivocratic token but we haven't shipped anything yet
    @nikete_twitter The other option will be to use Augur as the arbitrator, it'll need a little bridge contract but it should be fairly straightforward
    Edmund Edgar
    @edmundedgar
    @sumukhshetty Like @nikete_twitter says there's always a risk that someone bigger will show up. Also there's arbitration as a backstop, as long as you can afford the arbitration fee x2, you can always correct bad data yourself and still make a profit
    sumukhshetty
    @sumukhshetty
    @nikete_twitter Doesnt it make it easy for someone with a lot of money and who may have an incentive for pushing forward something else but the truth, for example in a prediction market. They can make an assymetric bet on an obvious bet and invest tons in making sure reality check oracles push their option as the truth
    @edmundedgar isnt this risk bad for a system thats built to push the absolute truth ?
    Edmund Edgar
    @edmundedgar
    @sumukhshetty They can try but other people will have an incentive to call them on their bullshit and take their bonds
    sumukhshetty
    @sumukhshetty
    What if there is not other person tracking this oracle ? Obviously an edge case, but what happens then ? It seems like clunky UX to me. Asking someone to bet against the bond, especially in th eearly days when people are still understanding the system
    Interesting project though, will follow progress.
    Ben Smith
    @tokyoben
    Hello!
    Edmund Edgar
    @edmundedgar
    Hi
    Edmund Edgar
    @edmundedgar

    /@all Quick update, as of last week we're live on mainnet. What we were calling Reality Check is now called Realitio.

    We've set up new Discord community for all the dev and UI discussion, where we're talking subjectivocracy, crowd-sourced verification tools, prediction markets, oracles and all this other fascinating stuff.

    You can join the Realitio Discord with the invite here:
    https://discord.gg/9aksWup

    Edmund Edgar
    @edmundedgar
    BTW to test things out we're going to be putting some wrong answers in the system and backing them with bonds, feel free to correct them and take our money