[ANN] Reality Keys: An oracle letting you use external state in transactions

[edmundedgar]

Have you seen Bitrated yet? I'd strongly advise you to contact them and see what it'd take to add support for oracle transactions to their escrow service. You could almost even use it as-is right now, except that the system only (currently) lets you set a single pubkey for the escrow agent.

Yup, BitRated is a really nice piece of work. I'm just wading through a lot of different stuff trying to work out the most practical thing to say to people who would like to use our keys in contracts and don't where to start; Ideally I'd rather just focus on providing keys that prove facts and let other people figure out how they want to use them, but I guess there are some areas where we could provide a helpful nudge.

[1714929112]

1714929112

[1714929112]

1714929112

[1714929112]

1714929112

[1714929112]

1714929112

[1714929112]

1714929112

[slackerdic]

It's also nice that your blockchain watching functionality allows us to experiment with some of the things we might want to do in a Script 2.0 without too much risk.

Agreed. Script 2.0 is the way to go

[Abdussamad]

Ok this is all nice and everything but could you please explain what n of m combination would be used? Take this for example:

https://www.realitykeys.com/blockchain/52/

[edlund]

Ok this is all nice and everything but could you please explain what n of m combination would be used? Take this for example:

https://www.realitykeys.com/blockchain/52/

Let's say that Alice wants to bet 10 millibits against Bob's 10 millibits that the address 1BitcoinEaterAddressDontSendf59kuE will have at least 2000 millibits on 03/23/2014.
They create two new events like these:
https://www.realitykeys.com/blockchain/89/
https://www.realitykeys.com/blockchain/90/

Let's say that Alice has a public address corresponding to the private key 5JNsUzxm5gyRybX5GLJ56ccWo45zFT7RPJDoBgffuqq8DiRh7fu and Bob has a public address corresponding to the private key 5KTqVVteW3cUAyXxerB5ho9mkMFg6LJ9ez5mnRx2zLPZsXaoiCD.
They will create two 2-of-4 multisig addresses.
The first one consists of the 2 public keys which realitykeys.com* will reveal if 1BitcoinEaterAddressDontSendf59kuE has less than 2000 millibits on 03/23/2014, the public key of Alice, and 1 public key which realitykeys.com will reveal if otherwise. This gives us the address 39X1TUG2bTJQ4SJ2HRjGMWewdXDoR4sm3R and the redeem script:

5241044bd2c100f5b52b54217a4b7a1356abe8352fef64edc440bede7f14793b79e79f967633189 796ca838cb43374563090136faa3a573bbbdcf3ce8b7130e30a439a41047ee78ee7ed1f7e0e50d3 c0585e4c695dc68a2503ba8a5343338cd72f962ca500d5aabd41577391294725379cb746cd5f614 381951739d17a73da34c2d134b941410448b9ec5366e8c4dfe9f5599c926220c3fc594ce9322f17 feaf28b59eba4f3ca3193d7a9da63ab975d9ba4642056ccc3c15657b8eb58ed6f45e6663bd8531b ffb4104501598839906e9782d3ea82afafd87839ae6e1dc34061bb17b196b4d9bf4b76bd0f20fe7 83d87d995e88774b940866a70b51323ad188aaffaf51ae30a865882b54ae

The second 2-of-4 address consists of the 2 public keys which realitykeys.com* will reveal if 1BitcoinEaterAddressDontSendf59kuE has at least 2000 millibits on 03/23/2014, the public key of Bob, and 1 public key which realitykeys.com will reveal if otherwise. This gives us the address 3MDaf2H76q849GPh45bFkm1smfWE5fij5n and the redeem script:

524104501598839906e9782d3ea82afafd87839ae6e1dc34061bb17b196b4d9bf4b76bd0f20fe78 3d87d995e88774b940866a70b51323ad188aaffaf51ae30a865882b41043801df383779f7edf643 f2f195239032ee00bdc58fe7dd059c72c3e65853c92e926abe11896c509f8d8baeabd7d7cec0709 5472baa9b231f5e6aab0e64ea06864104ef264df632bb21aed00bdd2fed565496cbd017cbb59e8c b3b303cf1ab065d42b7205b0c991c540f02620ac2dafbc0cb21d23f4192b68a08e218aed91ed59f 71c41044bd2c100f5b52b54217a4b7a1356abe8352fef64edc440bede7f14793b79e79f96763318 9796ca838cb43374563090136faa3a573bbbdcf3ce8b7130e30a439a54ae

Alice sends 10 millibits to the first address, Bob sends 10 millibits to the second one.

After 03/24/2014, if 1BitcoinEaterAddressDontSendf59kuE has at least 2000 millibits, 1 public key from the first 2-of-4 address will be revealed, and 2 public keys from the second address. Alice will be able send all 20 millibits to her own address. If 1BitcoinEaterAddressDontSendf59kuE has less than 2000 millibits, 2 public keys from the first 2-of-4 address will be revealed, and 1 from the second address. Bob will be able to send all 20 millibits to his own address.

The beauty of it is that there is no third party involved in storing the millibits. If Alice and Bob fear that realitykeys.com can steal their millibits, they can create 4-of-6 addresses, with 3 public keys from Alice and Bob and the already mentioned 3 from realitykeys.com. This way even the guys from the website will not be able to touch the millibits.

*realitykeys.com shows the public keys in compressed form. In order to get the uncompressed addresses in hex, needed to create multi-sig addresses here, you can use the Bitcoin Address Utility by Casascius. You need to go to Tools > Address Utility > paste in „Public Key Hex“ > click Publick Key > Uncompress Public Key.

[Abdussamad]

Thank you edlund. There is just one thing. 2 of 4 and 3 of 6 addresses are not "standard". I read that people have difficulty spending from such addresses. 3 public keys seems to be the maximum number that is widely supported.

There is a discussion here: https://bitcointalk.org/index.php?topic=508256.0

[VTC]

After 03/24/2014, if 1BitcoinEaterAddressDontSendf59kuE has at least 2000 millibits, 1 public key from the first 2-of-4 address will be revealed, and 2 public keys from the second address. Alice will be able send all 20 millibits to her own address.

What prevents Bob, or anyone with knowledge of the redemption script, to quickly move 10 of the millibits  before Alice can do so, as soon as realitykeys reveals two of the keys?  If Bob keeps the redemption script private, how can Alice prove that Bob deposited coins for the bet.

[edlund]

After 03/24/2014, if 1BitcoinEaterAddressDontSendf59kuE has at least 2000 millibits, 1 public key from the first 2-of-4 address will be revealed, and 2 public keys from the second address. Alice will be able send all 20 millibits to her own address.

What prevents Bob, or anyone with knowledge of the redemption script, to quickly move 10 of the millibits  before Alice can do so, as soon as realitykeys reveals two of the keys?

Good question. The 4 public keys of the first address are:

1st public key if < 2000:
044BD2C100F5B52B54217A4B7A1356ABE8352FEF64EDC440BEDE7F14793B79E79F967633189796C A838CB43374563090136FAA3A573BBBDCF3CE8B7130E30A439A

2nd public key if < 2000:
047EE78EE7ED1F7E0E50D3C0585E4C695DC68A2503BA8A5343338CD72F962CA500D5AABD4157739 1294725379CB746CD5F614381951739D17A73DA34C2D134B941

Public key Alice:
0448B9EC5366E8C4DFE9F5599C926220C3FC594CE9322F17FEAF28B59EBA4F3CA3193D7A9DA63AB 975D9BA4642056CCC3C15657B8EB58ED6F45E6663BD8531BFFB

1st public key if >2000:
04501598839906E9782D3EA82AFAFD87839AE6E1DC34061BB17B196B4D9BF4B76BD0F20FE783D87 D995E88774B940866A70B51323AD188AAFFAF51AE30A865882B

Realitykeys will reveal two private keys for this address only if 1BitcoinEaterAddressDontSendf59kuE has less than 2000 millibits. Otherwise, they will reveal only one. Bob can not use the one private key to move the funds, because the address is 2-of-4. He doesn't know Alice's private key. So he needs 1BitcoinEaterAddressDontSendf59kuE to have less than 2000, and this is their original bet anyway.

If Bob keeps the redemption script private, how can Alice prove that Bob deposited coins for the bet.

Another good question. The redemption script is always the same, if you input the same public addresses and required signatures. If Alice knows, that the 4 keys will be the following, she can get the redeem script by herself and see for herself if Bob has deposited coins:
1st public key if > 2000:
04501598839906E9782D3EA82AFAFD87839AE6E1DC34061BB17B196B4D9BF4B76BD0F20FE783D87 D995E88774B940866A70B51323AD188AAFFAF51AE30A865882B

2nd public key if > 2000:
043801DF383779F7EDF643F2F195239032EE00BDC58FE7DD059C72C3E65853C92E926ABE11896C5 09F8D8BAEABD7D7CEC07095472BAA9B231F5E6AAB0E64EA0686

Public key Bob
04EF264DF632BB21AED00BDD2FED565496CBD017CBB59E8CB3B303CF1AB065D42B7205B0C991C54 0F02620AC2DAFBC0CB21D23F4192B68A08E218AED91ED59F71C

1st public key if < 2000:
044BD2C100F5B52B54217A4B7A1356ABE8352FEF64EDC440BEDE7F14793B79E79F967633189796C A838CB43374563090136FAA3A573BBBDCF3CE8B7130E30A439A

You can play around with this website and see for yourself - https://coinb.in/multisig/.

[Abdussamad]

After 03/24/2014, if 1BitcoinEaterAddressDontSendf59kuE has at least 2000 millibits, 1 public key from the first 2-of-4 address will be revealed, and 2 public keys from the second address. Alice will be able send all 20 millibits to her own address.

What prevents Bob, or anyone with knowledge of the redemption script, to quickly move 10 of the millibits  before Alice can do so, as soon as realitykeys reveals two of the keys?

Good question. The 4 public keys of the first address are:

I think VTC is asking about the 2nd address in that scenario - the one bob funded. He can move his bitcoins before alice finds out the keys have been revealed.

[edlund]

I think VTC is asking about the 2nd address in that scenario - the one bob funded. He can move his bitcoins before alice finds out the keys have been revealed.

Hm, you're right. In this case I again can't think of a good way to use realitykeys.com. Hopefully some new ideas will appear in this topic.

[edmundedgar]

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:

Code:

OP_IF
2 alice-pub rk-yes-pub 2 OP_CHECKMULTISIG
OP_ELSE
2 bob-pub rk-no-pub 2 OP_CHECKMULTISIG
OF_ENDIF

(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:

Code:

x sig sig 

...followed by a true or false value for the OP_IF to tell it which branch to follow, so

Code:

x sig sig OP_TRUE

or

Code:

x sig sig OP_FALSE

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.

[edlund]

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.

[edmundedgar]

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.

[edmundedgar]

Ok this is all nice and everything but could you please explain what n of m combination would be used? Take this for example:

https://www.realitykeys.com/blockchain/52/

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:

Code:

realitykeysdemo.py makekeys

...and from the output she gets a public key:

Code:

04994740a3853613b2f364dbf3211f090854a72a99392b0d2a905520bc1eba99c660da66477048b7559eb92fac0897e4446e025d9fd22f4e4e4f9a1ca2da3be44e

...and a temporary address (made from that public key):

Code:

15dArbQ38SGzB4QLpVUc2BREeHbGD4V3DM

Bob does the same:

Code:

realitykeysdemo.py makekeys
0408a672849229b94d0ccbcb3f5a845af268ee07210c87bef2b350ac858f11f67a524b888bd27c33f87893e69fa3d51ad7b3078b3e949dfc6d6ef57f24bb3882d8
13XhvrHipiq8DxoFTkU3Gy6pPr7fGx68Mf

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.

Code:

realitykeysdemo.py setup 52 
04994740a3853613b2f364dbf3211f090854a72a99392b0d2a905520bc1eba99c660da66477048b7559eb92fac0897e4446e025d9fd22f4e4e4f9a1ca2da3be44e 15000 
0408a672849229b94d0ccbcb3f5a845af268ee07210c87bef2b350ac858f11f67a524b888bd27c33f87893e69fa3d51ad7b3078b3e949dfc6d6ef57f24bb3882d8 30000

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

Code:

realitykeysdemo.py setup 52
04994740a3853613b2f364dbf3211f090854a72a99392b0d2a905520bc1eba99c660da66477048b7559eb92fac0897e4446e025d9fd22f4e4e4f9a1ca2da3be44e 15000
0408a672849229b94d0ccbcb3f5a845af268ee07210c87bef2b350ac858f11f67a524b888bd27c33f87893e69fa3d51ad7b3078b3e949dfc6d6ef57f24bb3882d8 30000
01000000024985ca532b791f0f88557f2106515bc96070b0324b08a50e7da98f2466569cdc010000008c493046022100d175dd038014362aa72275f7319cdc01cf3a84a075be82dd7b43f2fc325dece6022100b2e8504bced6c80296cf5917dae9687b4608d315d6fcd44f2681005de7c16068014104994740a3853613b2f364dbf3211f090854a72a99392b0d2a905520bc1eba99c660da66477048b7559eb92fac0897e4446e025d9fd22f4e4e4f9a1ca2da3be44effffffffb1e4119a810a07f4b711201b529bb2acaa661a0bccd17cbc328c03c6d431402e0000000000ffffffff01c8af00000000000017a9148a3b43e0f8635ebe49991f83e2a4f2095dccded98700000000

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:

Code:

OP_IF 2 alice-pub rk-yes-pub 2 OP_CHECKMULTISIG OP_ELSE 2 bob-pub rk-no-pub 2 OP_CHECKMULTISIG OP_ENDIF

I should probably change that to the shorter equivalent:

Code:

OP_IF 2 alice-pub rk-yes-pub OP_ELSE 2 bob-pub rk-no-pub OP_ENDIF 2 OP_CHECKMULTISIG 

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

Code:

realitykeysdemo.py claim 52
04994740a3853613b2f364dbf3211f090854a72a99392b0d2a905520bc1eba99c660da66477048b7559eb92fac0897e4446e025d9fd22f4e4e4f9a1ca2da3be44e
0408a672849229b94d0ccbcb3f5a845af268ee07210c87bef2b350ac858f11f67a524b888bd27c33f87893e69fa3d51ad7b3078b3e949dfc6d6ef57f24bb3882d8

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".

Code:

OP_FALSE
3045022077885c62ac0e84e11705556df3789087b913734ceaf7ad182851cb96affb355902210094834168b8e5f9668def1c4ea51284b6fa57d83d7bb6485a6d231ae90b8d5c3601
3045022058c0e7bc775fe5ba2e2c377988434145a18c9d81ddc30470d0a583051a050062022100f11380f703695dcfd6cd559d84790ffa3a3f52cf4462f0e8be032f0688cd56c01
OP_FALSE 

[qxzn]

Our service can be used free of charge, to the extent that you are happy to abide by the automated results we pull from our data sources. However, we also allow you to pay a fee, currently 10 mBTC, to have a human check what happened, in the event that you think the API-generated result was wrong. For exchange rates etc we expect that this facility will hardly ever be used, but it may be useful for if you've made - say - a high-rolling bet on an election result, and the loser tries to rip you off by tinkering with one of the community-curated databases that feed into Freebase.

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.

[edmundedgar]

Our service can be used free of charge, to the extent that you are happy to abide by the automated results we pull from our data sources. However, we also allow you to pay a fee, currently 10 mBTC, to have a human check what happened, in the event that you think the API-generated result was wrong. For exchange rates etc we expect that this facility will hardly ever be used, but it may be useful for if you've made - say - a high-rolling bet on an election result, and the loser tries to rip you off by tinkering with one of the community-curated databases that feed into Freebase.

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.

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.

[qxzn]

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.

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

[DistributedBUZZ]

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

[fairlay]

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?

[edmundedgar]

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?

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.

[fairlay]

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.