If you really just want something conditionally redeemable by one person or another, I would recommend the transaction type I recommend for reality keys:
Reality keys will reveal private key A if a true/false fact is true, and private key B if it's false.
Alice and Bob want to make a contract to hedge the outcome of a fact because they each have opposing short positions relative to the fact. Alice will be paid if the fact is true, Bob will be paid if the fact is false.
Reality keys publishes the pubkey pairs a := gA ; b := gB
Alice has private key X and corresponding pubkey x, Bob has private key Y and corresponding pubkey y.
Alice and Bob compute new pubkeys q:=x+a and r:=y+b and they send their coins to a 1 of 2 multisig of those new pubkeys, q,r.
The values q,r are zero-knoweldge indistinguishable from a and b unless you know x and/or y, so no one except alice and bob, not even reality keys can tell which transaction on the network is mediated by the release of A vs B.
Later, realitykeys releases A or B, lets say alice wins. She computes a new private key X+A, and uses it to redeem the multisig. Bob cannot redeem the multisig because he knows neither X or B.
This looks like a perfectly boring transaction to everyone else. Alice and Bob collectively cannot be robbed by a third party, though they could be held up or if realitykeys conspires with Alice or Bob then there could be cheating. This risk could be reduced by using a threshold of multiple observers— which this scheme naturally extends to.
Sorry for hijacking the thread over this but just one thing to add on this pattern to avoid people getting into trouble - hopefully gmaxwell will correct me if I've got this wrong.
Since these x + a and y + b operations are invertible, you need to be careful that Alice doesn't know x, and Bob doesn't know y, until they've shown each other their own keys, a and b respectively. If they know the Reality Keys pubkeys in advance, it seems to be possible to make a special tricksy a or b key such that, when combined to make q or r, the owner could get the combined private key Q or R without knowing the relevant Reality Key private key X or Y.
See Alan Reiner's comment here:
http://permalink.gmane.org/gmane.comp.bitcoin.devel/4173In theory it looks like everything should be OK as long as you don't register the Reality Key until after you've seen the other party's public key, but if you're able to avoid this restriction it would be safer; Not only do you have to make sure you do everything in the right order, you also have to rely on us (Reality Keys) keeping our public keys secret until after you've made the exchange. The public keys are indeed supposed to be secret until they're allocated, but they're harder for us to secure than the private keys, since we need to be able to give them out to people on demand in real time. (Also there are some benefits to the same keys being shared for multiple people's contracts, rather than being assigned uniquely every time.)
I suspect you could defeat tricksy key attacks by Alice and Bob each producing an extra private key, sending it to their counter-party and requiring them to combine it with their Reality Key in a non-invertible operation, but I'm too far out of my depth to assess this. (It might also have some privacy benefits, so I'd be interested to hear what knowledgeable people think.) For now when I've been building demo applications on Reality Keys I've gone with the non-standard branching transaction approach, since sending these transactions to Eligius is practical at the moment and they should become standard in the next major Bitcoin release.
