Topic: [ANN] Reality Keys: An oracle letting you use external state in transactions (Read 7785 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.

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.

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.

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.


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

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.

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://bitcointalksearch.org/topic/are-multi-sig-m-of-n-transactions-with-n-3-supported-508256

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.

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/

Agreed. Script 2.0 is the way to go

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.

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.

Yes, I think it could be useful in that area. We're missing a couple of features right now in that respect but they're on the todo list:

1) Watching individual transactions - currently we can tell you about total payments coming into addresses and the total balance in an address, but we don't look at specific transactions. I haven't thought much about the kind of things we'd test for, but let us know if anyone has any specific comparisons they'd like to be able to make against these.

2) Monitoring other chains. We're watching blockchain.info for Bitcoin, but we also built some functionality to watch cryptocoin explorer for alt-chains. This is turned off right now because some of their API calls seem to be misbehaving at the moment, and in any case they seem to be down a lot of the time. People who need this functionality might like to consider donating to them.

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.

I can just as easily construct a spendable txout to tempt the release of a hash-preimage:\

DUP SHA256 EQUALVERIFY CHECKSIG

and send Reality Keys an email informing them of their bounty, if only they'd be dishonest...


Low is my guess among the current set of developers. But if you can come up with a good reason...

Then again, if you used a hash, there wouldn't be any addresses to spend to. One advantage I can see is that doing it with an address rather than a hash is that you don't run afoul of IsStandard. Any other pros or cons?

And speaking of IsStandard, what are the prospects of less restrictive rules any time soon, perhaps only for P2SH scripts?

Ah thanks, that makes sense.


OK, it sounds like for our current purposes we're best sticking with the current thing (a gazillion random key-pairs pre-generated by a plain old vanilla bitcoind with only the public keys accessible to the public web server until an event is settled) and building a bit more verifiability on top. It shouldn't be an impossible problem given that all the data we're talking about is public. We're currently logging all registered events and assigned public keys to an external syslog service, and it should be fairly straightforward to add blockchain notarization or some other form of integrity checking on top of that.


Even on the current scheme I guess it would be possible for us to release keys for an event without knowing the contents unless we needed to adjudicate it; If you gave us a regular hash of the event you want keys for rather than the content, you wouldn't have to give us the content until such time as you needed adjudication. Not a feature I'm inclined to offer at the moment, though.


Right, and I suspect there are lots of other little benefits to this approach that we haven't thought of yet.

You're caution was quite justified in this case! Unfortunately the way ECC math works if you release the secret key for one of these ECC-multiplication-derived pubkeys - as you must in your application - the master secret key can be recovered with some arithmetic if the pubkey key is known - again a must for the public derivation to be useful. Unfortunately there is no known way around this problem with ECC math, and the Bitcoin scripting language is too primitive to check an arbitrary signed message instead. I actually had the same idea when I originally thought of the pubkey derivation, and mentally filed it under "yet another example of BIP32 pubkey derivation is subtly dangerous"

Having said that, if you accept the need for the user to contact you first you can still do this deterministically by just hashing some master seed with the thing the user is asking and using that hash digest to derive a secret key and finally public key. However that version requires you to keep the master secret online on a potentially hackable server - I'd recommend adding at least one more layer of indirection to that system to derive a per-day secret and transferring that secret to the server in question somehow. You probably also want to separate the server holding the secret from the webserver - make the former communicate with the latter (and outside world) by some tightly controlled communication channel and no other means of access.

Finally one curious property of the above is that you can interactively commit to releasing a secret key for a question unknown to you. e.g. you can provide the corresponding pubkey for H(question) without knowing the question itself until the time comes to reveal it. I'm not sure this is necessarily a good thing!


Elliptic Curve Diffie-Hellman key agreement is how that encryption works. Bitmessage implements it here



Note how this is actually an advantage of using revealed secret keys over my earlier proposal of releasing hash pre-images: you can spend such a donation without revealing the secret key.

And of course, it wouldn't bias your decision either way, since you could spend outputs that had been donated to both addresses before destroying the key for the eventuality that didn't happen.

Congrats on the launch! It's looking really great - using Freebase is a fascinating idea.

Probably the nearest term useful app for this would be some kind of currency hedging system. But as you note, it's quite complicated.

As you'd guessed, we want to stay as far away from any actual contract as possible for the reasons you've given. This approach is also nice and simple and transparent. Everybody can figure out what we're doing, all our events are public, and the results are public too, so everybody can see how we settle them.

Also, although we've been talking about this as a bitcoin service, it's not necessarily bitcoin-specific, or even crypto-currency specific, or particular to the use-cases that have been discussed to date. Our keys could be used for encrypting messages (I think they're really designed for signing, but apparently it's possible to encrypt with them - if people want to do this and need another type of key we can talk) to be released in the event that something happens. For example, "Barack Obama has hidden a fish in a big block of ice somewhere under the floorboards in the Oval Office. He's written a message that will be released if the Democrats win the next election, so they can find it and throw it away before it starts to rot. But if the Republicans win nobody will know about it and they'll be going nuts trying to figure out where that smell is coming from."


We'd consider it a donation.

I like the sound of that, I'll give it some thought.

IIUC there's another way we could be approaching this, which would be that rather using individual random key-pairs as we currently do, we'd use key-pairs derived deterministically from a single key-pair, combined with a hash of the event we've registered. If I've got this right, thanks to the magic of ECC multiplication, people would then be able to independently derive the the public keys used in each case, without being able to derive the private keys. That way we can almost get rid of the concept of "registering" an event altogether; If you've got a record of an event (allowing us to recreate the hash) and our corresponding public keys, you can bring them to us at the due date and we can derive the private keys again to release one. People could actually create events independently, without even using our API.

We didn't spend any time looking into doing things this way because I wasn't quite confident enough that we wouldn't screw it up in some subtle way that somebody would discover halfway through 2015 after people had used these keys for a bunch of contracts. But if it can really be done as I've described it the approach would head off all kinds of nasty potential problems, including our losing data after you register a fact, and somebody hacking our public web server and managing to monkey around with the registered events or public key assignations without us detecting them.

Could you explain why you've chosen to publish keys rather than using Mike Hearn's algorithm? I have to admit I find the writeup on the Bitcoin wiki confusing, but maybe you could shed some light on it.

One advantage your approach appears to have is that you are not signing a transaction, in fact you need not even know what transaction it might unlock if it used P2SH or hasn't been published. This could limit temptations or threats you might be exposed to, including legal liability.

A potential complication is that people could send money to the published public keys. What would you do with such funds?

Great stuff! I wonder if you guys could use a blockchain-based trusted timestamping service like virtual-notary.org, proofofexistence.com etc to keep a record of events that you've registered, together with the public keys for the two possible outcomes. Once you've published the correct private key for an event, you could have that fact notarised too. In this way you could build up a reliability record that people can check.

Thanks, I'll take a look at the feeds Reuters can provide and see if there's anything we can use. Some of the commercial feeds provide very good quality data, but I'm a little bit nervous about tripping over something in their Terms of Service, or them stumbling on some of the more mind-blowing implications of what we're doing here and suddenly terminating our access, which could suddenly leave people using keys based on that data SOL.

Great to hear, let us know if there's anything we can do to help.

Right, that's my assumption too. Like I told the Coindesk guys, it's a chicken-and-egg problem where we need a few different parts, and none of them are much use without the others. Anyhow we have to start somewhere, so here's a chicken. It won't cost much to run and we're not depending on it to pay next month's rent, so we're happy to keep it running for as long as it takes for the ecosystem to develop.

Anyhow I was a little bit taken aback by the amount of attention the CoinDesk piece got last week. It really does look like there's a lot of interest, and all kinds of potential if we can bring all the pieces together.

Edmund, you have no idea how excited I am about your project. 

I've been working on a project for the last month and a half which uses oracles extensively.  Reality Keys may rapidly accelerate development of my project!

Very interesting.  Even better if you are able to plug into more authorative sources such as Reuters monitor systems.  The quality of the data is obviously very important.

Ha, glad to help!

You know, I'm really excited to see this service pop up - I was expecting to see the software to actually use this stuff get developed first and see people struggle to actually get the important oracle infrastructure developed, but you've done the exact opposite. I will say, don't be surprised if adoption is slow at first, the infrastructure to actually use the oracle for real transactions isn't really there yet. But hang in there and give it time for use-cases to develop; I'm sure they will in the long run.

I'm pleased to announce the release of Reality Keys. We provide information about things happening in the world - everything from exchange rates to election results, drawn from services with public APIs - in a form that can be understood by miners and used to confirm Bitcoin transactions. Our service is a little bit different from the  "external state oracle" Mike Hearn discusses here:
https://en.bitcoin.it/wiki/Contracts
...but we hope people will find it useful for some of the use-cases he describes.

Specifically, you can register an event - "1 USD will be worth more than 1 Euro on Feb 24th", or "Edward Snowden will win the Nobel Peace Prize by the end of 2015" - and we give you a pair of public keys, one representing the event happening and another representing it not happening. When that date comes around, we'll query the relevant API to find out whether the thing happened or not and release the private key for the public key that corresponds to the outcome. You can then use those keys in multi-sig crypto-currency transactions in the same way you might use a normal signature.

Currently our data comes from Coindesk (Bitcoin exchange rates vs USD), the ECB (exchange rates of legacy currencies), blockchain.info (Bitcoin address balances) and Freebase (everything in the known universe). Let us know if anyone has anything else they'd like us to monitor; In principle we can handle any API you can point us to as long as it has reasonably permissive Terms of Service and some other feasible way to double-check the information we get from the it in the event that it misbehaves. Please be patient with us if we run into performance issues over the next week or two, or if you manage to turn up some patterns of information in Freebase that we hadn't bargained for.

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.

Note that although we think this will be useful for people making all kinds of Bitcoin contracts, including some of the scenarios described in this CoinDesk piece, we aren't going to do anything to help you find someone to make a contract with or actually create the transaction. Obviously our service isn't much use without being able to do these things one way or another, but software for brokering advanced transactions and (potentially p2p) order books are big projects in themselves, which we hope to leave to the people already working on them, who are generally much smarter than us. We've provided a simple, authentication-free API that you can use to register facts, grab the resulting keys and check on their status. Please don't hesitate to get in touch if there's anything we can do to make our service more useful to you.

Also note that, since we only issue keys to say what happened in the world rather than actually taking part in contracts, we're not in a position to confirm the legality of using our keys to create any particular contract in your particular jurisdiction. Please make sure you check these things yourself and abide by your local laws and regulations.

Finally, special thanks to a couple of people on these forums: Mike Hearn, who has long been blowing everybody's minds on all things contract-related, and Peter Todd, who seems to come out with at least one important bitcoin-related insight every weekend, and two on bank holidays.