Oracle transactions

[Mike Hearn]

I rewrote the proposal for oracle transactions on the contracts page, after realizing it would not work.

An oracle transaction lets you lock up coins to arbitrary external state (eg the weather next week). It can be seen as a form of mediated dispute, but one in which the mediator is blind to the value of what they are mediating, so required trust is lower.

I've enclosed the newest proposal below. Your thoughts are welcome as always. Something like this may well have been proposed before.

Oracle transactions

Scripts are, by design, pure functions. They cannot poll external servers or import any state that may change as it would allow an attacker to outrun the block chain. But we can make transactions connected to the world in other ways.

Consider the example of an old man who wishes to give an inheritance to his grandson, either on the grandsons 18th birthday or when the man dies, whichever comes first.

To solve this, the man first sends the amount of the inheritance to himself so there is a single output of the right amount. Then he creates a transaction with a lock time of the grandsons 18th birthday that pays the coins to another key owned by the grandson, signs it, and gives it to him - but does not broadcast it. This takes care of the 18th birthday condition. If the date passes, the grandson broadcasts the transaction and claims the coins. He could do it before then, but it doesn't let him get the coins any earlier, and some nodes may choose to drop transactions in the memory pool with lock times far in the future.

The death condition is harder. As Bitcoin nodes cannot measure arbitrary conditions, we must rely on an oracle. An oracle is a server that has a keypair, and signs transactions on request when a user-provided expression evaluates to true.

Here is an example. The man creates a transaction spending his output, and sets the output to:

Code:

<oracle pubkey> CHECKSIGVERIFY <hash> OP_TRUE

This is the oracle script. It has an unusual form - after signature checking it pushes data to the stack then does not use it. The pubkey is published on the oracles website and is well known. The hash is set to be the hash of the user-provided expression stating that he has died, written in a form the oracle knows how to evaluate. For example it could be the hash of the string:

Code:

if (has_died('john smith', born_on=1950/01/02)) return 1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp;

This little language is hypothetical, it'd be defined by the oracle and could be anything. The return value is an address owned by the grandson.

Once more, the man creates this transaction but gives it directly to his grandson instead of broadcasting it. He also provides the expression that is hashed into the transaction and the name of the oracle that can unlock it.

It is used in the following algorithm:

• The oracle accepts a measurement request. The request contains the user-provided expression, a copy of the output script and a partially complete transaction provided by the user. Everything in this transaction is finished except for the scriptSig, which is empty.
• The oracle checks the user-provided expression hashes to the hash in the provided output script. If it doesn't, it returns an error.
• The oracle evaluates the expression. If the result is not the destination address of the output, it returns an error.
• Otherwise the oracle signs the transaction and inserts the signature into the scriptSig. Note that when signing a Bitcoin transaction, the input script is set to the connected output script. The reason is that when OP_CHECKSIG runs, the script containing the opcode is put in the input being evaluated, not the script containing the signature itself. The oracle has never seen the full output it is being asked to sign, but it doesn't have to. It knows the output script, its own public key, and the hash of the user-provided expression, which is everything it needs to check the output script and finish the transaction.
• The oracle returns the newly signed, unbroadcast transaction to the user.

If and only if the oracle agrees the man is dead, the grandson can broadcast the two transactions (the contract and the claim) and take the coins.

The oracle does not need to be highly trusted. It has not seen the transaction the grandson is trying to unlock, as it was never broadcast, thus, the oracle cannot hold the grandson to ransom because it does not know if the transaction it's signing for even exists. People can and should regularly challenge the oracle in an automated fashion to ensure it always outputs what is expected. The challenges can be done without spending any coins because the tx to be signed can be invalid (ie, connected to transactions that don't exist). The oracle has no way to know if a request to be signed is random or real. CHECKSIGVERIFY can be replaced with CHECKMULTISIGVERIFY to allow for n-of-m oracles if need be.

Oracles can potentially evaluate anything, yet the link to the block chain can always be the same. Consider the following possibilities:

Code:

// Require exchange rate to be between two values on a given date
today() == 2011/09/25 && exchange_rate(mtgoxUSD) >= 12.5 && exchange_rate(mtgoxUSD) <= 13.5

// A bet on me doing something that I will never actually do
google_results_count(site:www.google.com/hostednews 'Mike Hearn' olympic gold medal) > 0

// Choose between one of two winners of a bet on the outcome of the Eurovision song contest.
if (eurovision_winner() == 'Azerbaijan') 
  return 1Lj9udBVDwptFffGSJSC2sohCfudQgSTPD; 
else 
  return 1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp;

The conditions that control whether the oracle signs can be arbitrarily complex, but the block chain never needs to contain more than a single hash.

[1714136405]

1714136405

[1714136405]

1714136405

[bitplane]

I like the idea, it's really cool. It got me thinking: for it to be effective wouldn't we need a foolproof way of sharing and verifying facts on the Internet? Does something like this already exist? A semantic web of trust or something, preferably some form of decentralized network

[Mike Hearn]

No, that's the point of an oracle. You pick someone you trust to measure the world reliably, and on demand. You test them at any point you like, maybe multiple times, to ensure they do exactly that. They don't know what the outcomes of those tests will be, so they don't have an easy way to cheat and modify their behavior for financial gain.

If necessary, you can potentially combine different oracles. But that shouldn't be necessary - if you're locking up coins, you want to be sure you fully understand the conditions on which they can be released, which means the measured condition should be very precisely specifiable and context free.

[casascius]

Something like this could make sports betting interesting.

Suppose I publish two hash values h(X) and h(Y) and promise that after professional sports game S, that I will divulge only X or Y (but not both) depending on who the winner was.

One could effectively lock their bet into the blockchain.

[genjix]

I'm still halfway through understanding part 4, and it's super cool that you're brainstorming these ideas so I don't want you to think any criticism is because I find them worthless- au contraire. Hopefully we'll arrive at good tools in time. I like the idea of shared wallets that require everyone's permission to spend the funds.

Example 3: Assurance contracts. In Las Vegas the casinos around this river, agreed to fund bridges. People like to walk the length of them, and so the casinos all found it advantageous to build these bridges to allow people to cross over and walk back down the over side (and maybe gamble more). That works well.

The thing with funding public good, is that it doesn't scale. Once it's 1000 people, one guy might try to see if he can get away with not paying up if he sees that everyone else would still be willing to go along with funding it themselves.

Instead I'd try to frame this for when projects want to crowd-source funding and need X in order to continue. i.e Pioneer One asking for $25k to fund their series. There are lots of these on the bitcoin forums (I pledge 1 BTC for this initiative!) but it'd be an incremental improvement to not have to chase down all those people once the goal is reached, and to know how much is actually pledged.

[elk-tamer]

Any number of business agreements would be good candidates for this too. A freely traded market value would be easy to confirm, but I wonder about values from an independent auditor. I like the idea of the result from the oracle not being open to debate.
"oracle transactions" aren't a good name though, too well known from the database software.

[cunicula]

Presumably, the contracting parties will know what the verification condition is. Wouldn't the parties want to compete to bribe the oracle, e.g. announce the true verification condition and offer the oracle a bribe for a false report.

Increasing the number of oracles and polling them or randomizing across them increases the cost of bribes, but it doesn't solve the problem. Unless oracles can be disciplined in some way, they still stand to earn more from sharing in bribes than answering questions honestly.

Am I missing something here? In particular, I don't understand why the oracle doesn't need to be highly trusted.

[samr7]

Based on the subject, I thought you were talking about using an Oracle database.  Keep Larry Ellison away from my bitcoins!

Am I missing something here? In particular, I don't understand why the oracle doesn't need to be highly trusted.

+1

This would seem to build an escrow service into the block chain, and if that's an accurate interpretation, the entity making the decisions is more than just an oracle that answers questions, it's a trusted third party.

[wumpus]

Cool ideas,

One impractical thing about this inheritance scheme is that you need to have all your coins locked up. Assuming you don't know when you're going to die, and would still like to use some of your coins after you set this up, how would it work?

I'm afraid that the pre-stored transaction would fail in this case, as the number of coins that it specifies is larger than the number of coins left in the address.

[Mike Hearn]

Yes, you can bribe all the oracles. But when the signed transaction is broadcast, evidence of the oracles duplicity will be enshrined in the block chain for all time. It can be proven (and thus the oracles business harmed) if the program is known by somebody who got screwed, and the measurements used in the program were recorded in history.

For instance, if you locked up some coins on the condition that the exchange rate was at a certain range on a certain date, and your counterparty bribed an oracle to unlock the coins despite that, you could publish the program you used and everyone could see for themselves that the transaction was signed despite the program evaluating to false. It works because the exchange rate is a matter of public record. Presumably, other people wouldn't want to use that oracle in future - and besides, bribery is illegal, so that would give fairly good evidence with which to start a criminal investigation.

Note that not broadcasting the contract means that the potential for bribery exists but the potential for ransom does not - the oracle can't require you to cut them in. That makes it a bit different to a mediated dispute for cases where the condition can be expressed programmatically and measured regularly.

The thing with funding public good, is that it doesn't scale. Once it's 1000 people, one guy might try to see if he can get away with not paying up if he sees that everyone else would still be willing to go along with funding it themselves.

The point of an assurance contract is that the coins are only locked if enough people contribute to reach the goal. So if the 1001th guy sees that the contract will probably commit with or without him, no problem, he just doesn't contribute - and that's OK because his contribution wasn't necessary, the others valued the public good enough that he is irrelevant.

There is another case, where people aren't sure whether it's in their best interests to take part or not. This is what Tabarroks dominant assurance contract (DAC) is designed to solve. If the contract fails the entrepreneur pays you. If the contract commits, the entrepreneur gets paid. DACs are a very modern idea and so far they are theoretical, I've yet to find examples of them being used in the real world.

Based on the subject, I thought you were talking about using an Oracle database.

The term "oracle" comes from cryptography:

  http://en.wikipedia.org/wiki/Oracle_machine

... and obviously from even earlier, "oracles" were people who answered questions.

One impractical thing about this inheritance scheme is that you need to have all your coins locked up. Assuming you don't know when you're going to die, and would still like to use some of your coins after you set this up, how would it work?

It's pretty common to put inheritance money into some kind of (paper based) lockbox, I think. But yes, if you don't broadcast the transaction then the coins are still available for spending. Using them invalidates the contract but you can always recreate it, or rather, the software you use can recreate it for you.

The more interesting case is where the grandson may not trust the grandfather to really sit on the coins. Well, this example is very contrived, business contracts are a more likely application. This case is more complex because you don't want to broadcast the contract - it opens you up to coercion by the oracle, as they'd now know the contract they were signing for was real rather than a test, and moreover, they'd know how much it was worth. But if you don't broadcast it, the coins aren't locked and could be spent invalidating the contract.

You can solve it by using a service that runs secure hardware, like an IBM cryptocard or a computer that uses a trusted boot. The trick is to spend the coins to a key that is used to sign the contract, and then destroyed. You get back the signed contract which is the only way to spend the coins, but you don't have to broadcast it immediately because the key was destroyed, so there's no chance of the coins being spent in another way. The secure hardware is helpful so everyone can be sure the key was really destroyed.

Suppose I publish two hash values h(X) and h(Y) and promise that after professional sports game S, that I will divulge only X or Y (but not both) depending on who the winner was.

Yes, oracle transactions are a generalization of this idea, so you only need one type of script.

[samr7]

The term "oracle" comes from cryptography:

  http://en.wikipedia.org/wiki/Oracle_machine

... and obviously from even earlier, "oracles" were people who answered questions.

Indeed!

I still don't like the name.  While this entity does produce digital signatures -- a role which "oracle" certainly fits, its bigger picture role is to perform a sort of fiduciary duty, and it would make more sense if that was reflected in the terminology.

Otherwise the idea is great!