Yah.  But I really don't like trusted third parties.  I'm trying to cut the current tribe of trusted third parties out of the deal in fact.

What I'm trying to do is set up the equivalent of a four-party transaction on two different blockchains -- where information can flow back and forth, but you cannot have a four-way transaction because two of the actors (or actually two of the wallets) are on one blockchain and two of the actors (or actually two of the wallets) are on the other. 

As an example of an application, consider the disarmingly simple proposal:

 "I'll send you 50 litecoin if you send me half a bitcoin." 

Each participant has a Bitcoin wallet and a Litecoin wallet, so they can do the individual movements.  The issue is whether they have to trust each other or not. Even with a modified protocol so a client can *see* both chains, or even with a modified blockchain so that key information from the other blockchain can be stored in the local blockchain and used by scripts, I don't see a good way to do it. 

If we come up with a solution for this problem, then we don't need coin exchanges to trade coins back and forth.   

I doubt this would ever happen with Bitcoin because I'm betting it would take a protocol modification and take a lot of security analysis to figure out how much risk an extra capability adds.  But if we can develop a modified protocol for altcoins that makes new coins freely and securely exchangable without a need for trusted third parties, that would rock.  Bitcoin could adopt it after the rough-n-ready risk testing is done on alts.

One possibility I've come up with is an "on-recieve script."  That is, a txout created with a stored script that runs immediately and automatically when a coin is sent to a prearranged txout.  You can put money in a txout with such a script, show the other participant a script that matches the hash so he knows what it is, and then either one of you could trigger it by sending a coin to the address.

So if we have an on-receive script that

* checks the block height or time to make sure an agreed-on interval has gone by and aborts if not,
* checks some 'oracle' information about the other blockchain to see if a transaction there has happened,
* and sends the coins stored in the scripted txout immediately to Bob if it has or Alice if it hasn't,

Then we have a situation where someone could present cryptographic proof that a given transaction has taken place in the other blockchain, store it in the 'oracle' location, immediate blockchain, and then either of them could trigger the script to run (either paying the seller or returning the buyers money) by sending a penny to the address specified in the scripted txout. 

There is one main problem with that idea.  "On-receive" scripts open a whole big can of worms that needs very careful security analysis.