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.
