Ruben,

In my opinion, this protocol is theoretical breakthrough as well as a practical protocol. Well done! I want to try and distil the core abstract ideas here as they appear to me. From my view, the protocol is a combination of two existing ideas and one new one:

1. In atomic swaps you can make the refund transaction on one chain dependent on the refund on the other using secret revelation. Thus only one chain needs to have a timelock and the other refund can be conditioned on a secret that is revealed when that first refund goes through. (This idea is in the monero atomic swap [1]).

2. Secret revelations can be used to give unconstrained spending power to one party. With an adaptor signature, rather than reveal a decryption key for another signature, you can just make the decryption key your signing key in the multisig so when you reveal it with the adaptor signautre the other party gains full knowledge of the private key for the output and can spend it arbitrarily. (this is just folklore and already what happens in HTLCs -- though it looks like lightning people are about to get rid of the unconstrained spend I think).

The combination of these two ideas is novel in itself. The problem with idea (2) is that your unconstrained spending power over an output doesn't matter much if there is a pre-signed refund transaction spending from it -- you still have to spend it before the refund becomes valid. But if you bring in idea (1)  this problem goes away!

However, you are left with a new problem: What if the party with the timelock never refunds? Then the funds are locked forever.

Here's where the truly novel part comes in. Ruben solves this by extending the standard *TLC contract:

1. Bob redeem with secret

2. Alice refund after T1

3. Bob redeem without secret after T2

We might call this a "Forced Refund *TLC". Alice must claim the refund or lose her money. This forces the refund secret revelation through punishment. If Alice refuses to refund Bob gets the asset he wanted anyway!

The resulting protocol you get from applying these ideas is three transactions. At the end, one party has their funds in a non HD key output but if they want that they can just transfer it to an HD output in which case you get four transactions again. Thus I consider this to be a strict improvement over the four transaction protocol. Furthermore, one of the chains does not need a timelock. This is remarkable as the four transaction atomic swap is one of the most basic and most studied protocols. I considered it to be kind of "perfect" in a way. It just goes to show that this field is still very new and there are still things to discover in what we think is the most well trodden ground.

I don't want to ignore that Ruben presents us with a two transaction protocol. He made a nice video explaining it here: https://www.youtube.com/watch?v=TlCxpdNScCA. It is harder to see the elegance of the idea in the two tx protocol because it involves revocation and relative timelocks etc. Actually, it is straightforward to naively achieve a two tx atomic swap with payment channels:

1. Alice and Bob set up payment channels to each other on different chains

2. They atomic swap the balances of the channels off-chain using HTLCs using the standard protocol.

3. Since one party exclusively owns the funds in each channel the party with no funds simply reveals their key in the funding OP_CHECKMULTISIG to the other

4. Both parties now watch the chain to see if the other tries to post a commitment transactions.

The advantages that Ruben's two tx protocol has over this is that timelocks and monitoring is only needed on one of the chains. This is nothing to scoff at but for me the three tx protocol is the most elegant expression of the idea and the two tx protocol is a more optimised version that might make sense in some circumstances.

[1] https://github.com/h4sh3d/xmr-btc-atomic-swap/blob/master/README.md

LL