Topic: [ANN] Reality Keys: An oracle letting you use external state in transactions (Read 7787 times)

A price oracle already exists, and yes it enables trading binary options.
See https://medium.com/byteball/making-p2p-great-again-episode-iii-prediction-markets-f40d49c0abab

Any ideas on how to combine the RealityKeys oracle with this:
https://en.bitcoin.it/wiki/Binary_options

A quick update on our Freebase data source: Yesterday Google announced that they'll be closing Freebase to new edits at the end of March, 2015:
https://groups.google.com/forum/#!topic/freebase-discuss/s_BPoL92edc

We liked having Freebase there as a big, general data source allowing you to formulate pretty much any factual proposition in the known universe. We'll take a look at other options and see if we can replace it with something that performs the same role, although at this point we can't guarantee we'll be able to find something suitable, and if we do we're not sure whether we'll be able to seamlessly migrate the outstanding facts currently in our database over to it.

As of today we've stopped accepting new Freebase facts beyond March, 2015, since we're not yet sure that we'll be able to do automated resolution on them. We don't have a huge number of Freebase facts currently registered beyond that date, so in this case if we're unable to find a suitable replacement data source we plan to have a human settle them free of charge when their settlement dates come up in 2015 and 2016.

This mostly covers things already discussed on this thread, but we've written up some information about transaction patterns etc for creating contracts, with links to a couple of working examples:

https://www.realitykeys.com/developers/resources

OK, this is now live. You can select "difficulty" here:
https://www.realitykeys.com/blockchain/new
...to check the difficulty on a particular date.

You can also create and check these facts via our API:
https://www.realitykeys.com/developers#blockchain

After setting this up I took a look at the Fairlay site and realized that you're looking at block numbers rather than dates. Can you work with it this way, or do you need to be able to set a block number? (If that's what you need, it shouldn't be a big drama to add it.)

sounds very good - we will use the difficulty "keys"!

We're just finishing up an upgrade to the "blockchain" facts to include block difficulty, and also switching from blockchain.info to blockr.io, which will allow us to support Testnet and a number of alt-chains that they monitor.

While we're working on this, does have suggestions for related things they'd like included in this release? For example, we currently do address balances and total amounts received, but we don't currently cover the individual transactions that are producing those balances and amounts. If we did, would that be useful to anyone, and if so what would you want specifically?

PS. I should mention the awesome help we got from blockr.io. I asked them for a new API call last Wednesday, it was live by Friday.

You may have seen this but Gavin's written a pull request that would open up the whole set of legal-but-non-standard scripting for P2SH transactions, subject to a specific DoS-related limitation in the number of signature checks.
https://github.com/bitcoin/bitcoin/pull/4365

If and when this gets into a release - I'm very optimistic that it will - that will make the non-standard pattern I described up-thread using this script standard, avoiding the need to push to Eligius or work around the standard checks with ECC key combination clevers.

Nice catch, fixed.


Yup, should be doable, I'll take a look.

thanks for your answer!

Just a tiny bug I stumbled over: at: https://www.realitykeys.com/freebase/203/ the "headline": "Champion of 2010 FIFA World Cup to be Spain national football team" the links are somehow not correct. If I click on FIFA World Cup it links me to the Spain nation football team and the other way around.


Btw: It would be very interesting for us if you would provide keys for the current difficulty then we could do these with your site: https://www.fairlay.com/event/category/bitcoin/difficulty/
Since you are already using the blockchain.info API it should not be too complicated.

Again - congrats for this cool project.

I suspect Freebase is going to be hard to use in practice for sports betting because it can take a while to reflect the results, and people probably want a quick payout, although we could speed this up if somebody pays the fee and we go ahead and settle it manually. We're looking into adding some dedicated sports data feeds, but they tend to be proprietary and have quite restrictive Terms of Service. Ultimately Reality Keys may end up getting out-competed for sports betting by people running services anonymously and not worrying about whether their use of the data is legal...

Anyhow, to show you how to use Freebase, I had a go at:
https://www.fairlay.com/predict/registered/new/germany-will-win-the-football-world-cup/

The easiest way to do these is to start with an event that's already finished, so you can get a preview of what Freebase returns and make sure you've structured the thing correctly. Then you come back and do the future event that you're actually interested in.

So I start by typing in "world cup", and I get a list of previous World Cups, including "2014 FIFA World Cup" and "2010 FIFA World Cup". First I choose "2010 FIFA World Cup", which was won by Spain. A bunch of links appear for properties that the FIFA World Cup might have. I look for a link like "winner" and find "champion", which I click. At this point it pulls a preview of its current data and shows "Spain national football team" on the right-hand side of the screen.

It then shows me another box, and I start typing "Spain", who won in 2010. At this point Freebase is clever enough to know that the winner of the 2010 FIFA World Cup has to be a sports team, so it automatically filters the list to sports teams. (It's not quite clever enough to know that it's a national soccer team, so you get some other teams in there too, but it should be easy enough to find the national team.) I choose "Spain national football team" and I'm done. You can see the value is shown as "Yes", because Spain did in fact win that championship.
https://www.realitykeys.com/freebase/203/

Now I'm clear how to do it, and clear that it gives me what I expect, I repeat with 2014 and Germany. There's no preview this time, because nobody is the champion yet.
https://www.realitykeys.com/freebase/202/

PS I know it can be a bit baffling working out what property in Freebase you need; At some point we'll put in some templates for common queries like this so you don't need to puzzle it out unless you're searching for something obscure.

This is awesome - we will try to use really key results for our predictions on www.fairlay.com

In the next month we clearly aim to store the Bitcoins in a multi-sign address but as you all know it is a challenge especially when it is combined with a order book with several people involved. Also we want to give people the option to cash out and take a profit when the odds changed and not necessarily wait until the resolution. However - we will face it.

For now we would like to create really key events for as much as possible events on fairlay. To be honest I already got stuck for a very simple one: the world cup winner: https://www.fairlay.com/predict/registered/new/germany-will-win-the-football-world-cup/

It would be nice to have it done for these as well:
https://www.fairlay.com/predict/registered/new/don-draper-will-die-during-the-7th-season-of-mad-man/
https://www.fairlay.com/predict/registered/new/greater-then-6-0-earthquake-in-southern-california-this-year/

Anyone with more freebase experience who can help out?

been watching this project and its one of my favourites, truly innovative!

Ah, this makes much more sense. Thanks for the explanation.

To be clear, we release the result in two stages: First we publish the result, not the key. Then we wait for objections. _Then_ we release the key, based on either the original data from the API (if there was no objection) or the human check (if there was an objection). So nobody's cashing anything out based on our keys until either the objection period has elapsed or we've done a human check.

We don't currently provide an option to get a key without waiting for the objection period, although you can simulate it if that's what you want by setting a very short objection period. If we start providing feeds to systems like Ethereum we'll probably have two tiers as you suggest and provide two feeds, one for the original raw data from the API and another for data that's either been human-verified or sat for the duration of the objection period without anyone objecting.

The reasons somebody might conceivably still try to tinker with data sources and profit from it would be:
1) You're hoping your counter-party won't bother to check.
2) You have a contract that allows the two of you to settle without the data source if you both agree, and you're hoping you can extort your counter-party to pay you an amount less than our fee in exchange for a settlement in their favour.

I think (2) will tend to be ineffective, because humans like to punish this kind of behaviour if they can do so reasonably cheaply, so they'd generally prefer to pay us the fee rather than settle with the extortionist. Maybe it would work if they didn't realize that it was their counter-party who had broken the data.

(1) could be mitigated with software that the user runs, so they can have it check another data source or manually plug in what they expect the result to be and it'll alert them, and maybe even pay the fee automatically, if Reality Keys doesn't publish what they expect.

Correct me if I'm wrong, but doesn't this create a lot of incentive for such "tinkering"? If I make a bet, and somebody sets the result to the incorrect value when your system reads it, my counterparty cashes out the bet, I've already lost the money. Going back and fixing the result after the fact is too late.

One fix I can think of is to have two tiers of keys that you release -- one representing an automatically pulled result, and one representing a result which has been human verified. That way, if it's a bet of significant financial consequence, I can make it rely on the human-verified key and just plan on paying you the ten bucks if I win.

I think you'd want to be very careful with this, because the first time people get burned by an error (intentional or not) in your underlying data stream, you'll have a bit of a trust issue to claw back from.

Here's a proper worked example for you. This uses a non-standard transaction for the redeem part and gets it mined by pushing it to Eligius, which I think is cleaner and more straightforward than the alternatives, but as discussed there are non-non-standard ways to do it too.

Alice and Bob look at the realitykeys.com URL you mentioned and see that we're dealing with ID 52. Alice is going to pay in 15,000 Satoshis, Bob 30,000, and the winner takes it all (minus transaction fees). Here's how it happens:

They each grab my slightly rough-and-ready test script from here:
https://github.com/edmundedgar/realitykeys-examples/blob/master/realitykeysdemo.py

Alice creates an address:
...and from the output she gets a public key: ...and a temporary address (made from that public key):
Bob does the same:

Alice and Bob both exchange public keys and fund their own temporary addresses with their stakes. (This is an extra step that you probably wouldn't have in an advanced implementation, but it makes things easier here.)

Alice creates a transaction, using inputs from her and Bob's temporary addresses.

This outputs a transaction for her to send to Bob, who runs the same command, but with the transaction tacked on the end:
Bob:

The script broadcasts this and it shows up on the blockchain as the following transaction, which spends Alice and Bob's inputs to a P2SH address.
https://blockchain.info/tx/bdf985c0fa0ad9f1f9b33b3091547e06deda121a20c53496c062459f71018512
The blockchain won't show you how that P2SH address was made yet, but if you read the script you'll see that it was made by hashing this:

I should probably change that to the shorter equivalent:

They wait until the result is announced, then the winner (in this case it's Bob) does:

That creates a spending transaction and sends it to Eligius. You can see that here:
https://blockchain.info/tx/d105d570237d5be5476287fb1cfefb660996c054af133995ad7c7a1c2a8054b6

You'll see it was spent like a normal P2SH multisig script except there's an extra "OP_FALSE" tacked on the end. (The one on the beginning is always there to work around a bug.) This tells the script to use the second path (from OP_ELSE to OP_ENDIF) instead of the first (OP_IF to OP_ELSE). If Alice had won it would have been "OP_TRUE".

One more way of doing this - I'm not a big fan of this one, for reasons I'll give below, but I'm including it for the sake of completeness. Maybe someone can improve on it.

I haven't tried this yet but I think it should work, and even pass IsStandard(). This uses edlund's four-key pattern, but for the parties instead of the Reality Keys, so Alice will need pubkeys a1 and a2, and Bob will need pubkeys b1 and b2. It will only work if the parties know approximately when the event will be settled, but the way Reality Keys works right now they always know that. (Currently we only do "check on this date then release the right key", not "check every day and release a key if and when X happens".)

Alice: Make a transaction spendable with 3/4 [a1 a2 b1 rk-yes]. It's not valid yet because Bob's inputs are either not included or included but not signed, so the total output amount is greater than the total input amount. Send it to Bob to complete.
Bob  : Check, add inputs if necessary, sign, get the TXID, but don't broadcast or send back to Alice yet.
Bob  : Make another transaction, this one time-locked with nLockTime to a couple of weeks after the settlement date. This spends the previous transaction (the one we haven't broadcast yet) to 3/4 [b1 b2 a1 rk-no]. Send to Alice for her sig.
Alice: Sign Bob's transaction, send it back to Bob. (Since she hasn't seen the completed first transaction yet she's taking his word for it that the TXID is right, but she doesn't care because if it's wrong it'll be his loss not hers.)
Bob  : Check, broadcast the first transaction, hold on to the second.

The restriction here is that if Alice wins she'll have to spend before the lock time. If she's too slow then Bob could spitefully broadcast his transaction, making Alice's Reality Key useless and forcing her to negotiate with him if she wants her money.

There's an equivalent restriction on Bob that if he wins he can't claim until the lock time, unless Alice is feeling generous.

There's also a risk that somebody will take advantage of transaction malleability, see the first transaction being broadcast and mutate it before it gets mined, in which case the TXID will change and Bob's side of it will break. (Hopefully Alice would sign a new one if that happened, but it would be up to her.) I know there are some fixes for this in 0.9, but I'm not sure what the current status is, or whether it's even fixable in a case like this where one of the people who signed some of the inputs is potentially the attacker.

Thanks for the reply, Edmund, and congratulations for the work done. I really hope that more people will have a look at your project and expand it, it's one of the most exciting things I've seen.

If you can live with a non-standard transaction for the redeem step - which should be OK, as that part shouldn't be particularly time-sensitive and you can send it direct to Eligius or someone to get it mined - you should be able to do something like:
(That's the simplest case - in practice you probably also want another OP_IF for alice+bob.)

You'd spend this with a normal multisig sigScript which looks like:
...followed by a true or false value for the OP_IF to tell it which branch to follow, so
or

You probably want to fund this transaction atomically so that it's only valid if both parties pay, so the steps would be:

1) Alice and Bob agree on a fact.

2) Alice creates a transaction, signs it and sends it to Bob.
Note that when doing this Alice needs to either:
a) Sign her inputs with SIGHASH_ANYONECANPAY so that Bob can still add inputs.
b) Know Bob's inputs in advance (eg Bob tells her, or they have a standard process where they each put their money in a temporary address - I've been tinkering with this stuff and doing it that way seems to make things easier.)

3) Bob checks it, adds his inputs if doing the SIGHASH_ANYONECANPAY method and broadcasts it. IIUC since the non-standard OP_IF stuff will be hidden in a P2SH hash, this transaction will be standard, although you'll need a non-standard transaction when you try to redeem it.

4) Time passes

5) The winner gets rk-yes or rk-no and makes their spending transaction, which they send to a miner like Eligius to mine. (He has a handy web form you can post it to.)


If you don't like the non-standard transaction, it may be possible to make the equivalent of the above with some ECC voodoo, as Peter Todd suggests on this thread:
https://bitcointalk.org/index.php?topic=260898.60
I've been experimenting with this and got what seems to be a functioning setup by doing ECC addition to combine keys to simulate an "and", so you make one key indicating "alice + rk-yes", another indicating "bob+rk-no", and then use a standard multisig script. I'm reluctant to recommend this in this form because:
1) You need to make sure you exchange public keys before registering the fact and revealing the Reality Keys public keys, because otherwise one of the parties can make a key that cancels out the reality key.
2) This is a slightly odd thing to be doing, and may have other interesting problems that I'm not really qualified to assess.
There may be a way to do this properly by doing ECC multiplication instead of addition, but I figure this is probably better left to somebody who understands the maths better than I do.