I rely on nLockTime and fees to switch directions. Basically, when you're going in one direction, the payee always has the incentive to broadcast the most recent refund transaction version and have it committed to the blockchain.
To switch directions, the nLockTime of the new refund version should be earlier. That way, the more recent version of the refund transaction is valid for inclusion in the blockchain first. I'd also increase the transaction fee in order to incent miners to include the newer version of a transaction over an earlier version for additional safety (in case the nLockTime difference between the versions is too small for the newest to be included by the time the second newest is valid).
I ended up presenting this concept Friday night in San Francisco. I think there will be a video put up; I'll link to it when it is.
Thanks; that sounds really useful. In fact, in the development of Amiko Pay, I'm exactly at the point where I should be integrating my multi-signature implementation into a payment link, so this comes exactly at the right moment.
I remember we discussed these things before in other threads; I think back then I criticized your ideas for having flaws. The way I see it now, this does exactly what it promises - provide a secure bi-directional channel - assumed that, around nLockTime, both parties are online to publish their transaction. Optionally, this "transaction publishing" can be delegated to a cloud provider, of course.
This does not completely eliminate the need for direct-neighbor trust in the Amiko network, but the way I see it now, that is impossible anyway with the current capabilities of Bitcoin. So, I'll continue developing my prototype for as far as is possible now, and then we'll see how to continue from there.
