Of course from a UI point of view it can be very simple. Alice just asks Freenode's website what she should put in the "condition" field in her "bitcoin send" window.

Yeah! ClearCoin is a kind of referee and could become a trusted certificate issuer.
But there are also many potential referees that would refuse to handle the coins themselves.

It's possible, though I think you need some out-of-band system to get the escrow agent to sign your transaction.

Do you have a script example? How do you deal with the deadline?
Which OP_s have to be activated in the client?

Sorry, lots of questions

This is the bit where I tout the usefulness of OP_BLOCKNUMBER in spite of the modest complications a safe implementation would entail.   most recently discussed here http://bitcointalk.org/index.php?topic=6439.0

Much as I think that the scripting is the best bit of Satoshi's work, I'm doubtful it will ever be revived.
The fact that a bitcoin is increasingly valuable with scripting disabled means that scripting is not essential. Enabling scripting, although I'm a big fan, would break the rule that a successful product should do one thing well.

ByteCoin

In the event of a block chain reorganization, in the absence of a double spending attack, all the transactions on the shorter branch can expect to be incorporated into the longer chain. The only "money" that's lost is the rewards for finding blocks on the shorter branch - the coinbase transactions. There's a reason why coinbase takes such a long time to mature, it's because it's subject to being disappeared in the event of a reorg. We assume that reorgs can't take place at a depth of 120 blocks so coinbase matures after that time.
The problem comes with OP_BLOCKNUMBER transactions which are involved in a reorg where they get incorporated into a block which changes the functionality of the script because of the different block number. Any transactions spending coins depending on OP_BLOCKNUMBER transactions may also get invalidated and that's bad. So to be safe there would have to be some scheme that provides as much assurance as is provided with coinbase maturing for 120 blocks. I guess that coinbase matures at a rate of 5BTC every 12 blocks so perhaps OP_BLOCKNUMBER transactions shouldn't mature until max(120,ceil(value_in_bitcoins/5*12)) blocks have passed to provide similar assurances.

It's not a great solution as OP_BLOCKNUMBER transactions are treated differently to any others.

ByteCoin  

Interesting! Strange that this ownership is symmetric in sender/recipient/escrow.

I was thinking that the referee should be left apart from the actual bitcoin transaction and would only sign a "<B> gave <A> his account prior to <date>" certificate. But maybe it's a good way to deal with the deadline problem? (Referee would be trusted to handle the deadline correctly.)

I'm not really sure your argument is valid or possibly I don't understand.
Bob would put the data in the chain when he provide the scriptSig (he forged using the certificated) to redeem his due.
He is supposed to do that before the deadline, and bitcoins are frozen until then. What fork could that induce?

You're right -- it is impossible to do safely. The attacker could do something like:

The block in which the script is meant to be included into can't be known by people verifying the transaction.