I'm still in the early days of thinking this through, but this idea from @RubenSomsen looks really excellent:

twitter.com/SomsenRuben/status

(Deliberately linking the tweet, because I believe you really need the diagram most of all to understand the idea, there is a gist linked in there too).

Basically coinswap with 2 instead of 4 transactions. This was always the dream for me, and it nicely connects with recent work on single signer ECDSA adaptors.

@RubenSomsen
So I'm going to expand on this a bit in thread. My purpose is to make it a bit less impenetrable.

It is sophisticated thinking and in my view an actual innovation in off-chain contracting of a type I've kind of been expecting (segwit's bugfix enables stuff like this, as it does coinjoinxt and host of other things - it's not just Lightning!).

It's not a magical super-leap over existing CoinSwap design. It's just, most likely, a *lot* better.

Next: how it works (2/n)

Show thread

@RubenSomsen
The core idea is to *enforce a refund*.

Earlier coinswap ideas had something like this:

in the background are pre-agreed txs that are locked to each other, where spending one reveals a secret to allow spending the other, or allowing backout if non-cooperation (this is basically the "HTLC" idea).

Then overlay with a simple transfer; the HTLC versions only happen if there is non-cooperation.

This all involves spend-in to co-control (2 of 2 multisig), ...

(3/n)

Show thread

@RubenSomsen
... followed by cooperative spend out. So 4 transactions in *best* case.

Those 2 overlay spends had to be embedded into the blockchain.

As in CoinJoinXT, the new scheme starts by preparing a bunch off pre-signed transactions from a root/anchor funding transaction that *will* be paid into by Alice (say Alice and Bob are the parties). The most important thing about those presigned tx is: they all are funded by the same (Alice+Bob 2 of 2) construct, and the first is ... (4/n)

Show thread

@RubenSomsen

... timelocked 2 days into the future (say), CLTV style. The innovation is the second layer txs after this: this second tx pays into either a refund for Alice, *the signing of which reveals a secret of Alice's*, or after even later delay (these are relative/CSV delays), a transfer directly to Bob is activated. These last two parts constitute the "enforce a refund* mentioned above.

So, in the new scheme, Bob, on his side, after the above has been done, can send his funds ... (5/n)

Show thread

@RubenSomsen

... into a different 2 of 2 (where Alice's side is the exact refund secret mentioned above), without any backout mechanism, even though previously that was considered impossible - what if Alice never showed up? Your funds are permanently deadlocked. But here, while Alice still has her refund mechanism in case Bob is unreliable, she is FORCED to exercise that refund mechanism, thus she is forced to reveal the aforementioned secret if she ever wants her money back, ... (6/n)

Show thread

@RubenSomsen

... and if she doesn't, after a suitable timeout, her money gets given unconditionally to Bob. This is a punishment incentive as in Lightning, kinda (although it's not asymmetric - it's not more than originally was intended to be transferred).

That difference seems obscure but is crucial for Bob. He knows that even if Alice does not cooperate, he will get *her* coins after a timeout, or else she's forced to cough up her key for the 2 of 2, which will give Bob ... (7/n)

Show thread

@RubenSomsen
... unconditional control over that 2 of 2 output he created.

So given the above, Bob can transfer into a simple 2 of 2 on-chain.

At this point, if you're following along, we have two transactions that were broadcast onto the blockchain, and about 3 off-chain txs that are partially or fully signed, but not broadcast.

This is where another element is added in: the "success" transaction. What this does is gives Bob a way to take full ownership of Alice's coins, ... (8/n)

Show thread

@RubenSomsen

... modulo attempts to broadcast the earlier mentioned refund stuff. Alice and Bob co-sign a tx sending the original Alice's coins (now in a 2 of 2 remember), to Bob. For Alice's safety, Bob's side is an adaptor sig - he can't broadcast this transaction without revealing the secret for his own 2 of 2 (the same one where he got a defence against Alice by forcing her to reveal her secret, *if* she ever used the refund mechanism).

Once this is set up, he now just *gives* ... (9/n)

Show thread

@RubenSomsen
... his secret for his 2/2 to Alice. *Alice now has exclusive control of Bob's original coin(s)*.

So she doesn't need to broadcast a second transaction; that original 2 of 2 is now functionally a single-key utxo that she owns.

But does Bob have exclusive control of Alice's original coin(s)? The answer is yes, but.

First, clearly he can broadcast the success tx any time in the next day (or 2, whatever the timelock is). This would give finality, it would invalidate the ... (10/n)

Show thread

@RubenSomsen
... refund path, which is timelocked.
But if we wanted to avoid that third transaction broadcast we have a last trick:
At this point, Alice can *give* Bob her key in the 2/2 that she originally funded at the start. Then he has exclusive control of the output that was created there, and we can say 'the 2 transaction coinswap is finished'!. But not quite - he has "exclusive control", except for the refund transactions we created at the start. If he goes to sleep for the ... (11/n)

Show thread
Follow

@RubenSomsen

... next month, Alice can broadcast the first one, and the second one, which pays her the coins in refund. The first was locked with CLTV for a day and the second was CSV locked for a further day. If Bob is watching the blockchain and sees the *first* of these broadcasts, he has another day's grace period, where, since he fully controls the Alice/Bob 2/2 involved, he can then unilaterally transfer it to himself.

As mentioned at the start, this is not asymmetric ... (12/n)

@RubenSomsen

... punishment, rather just enforcement that each party gets what they were intended to get.

That's a summary. Watch Ruben's video for a elegant pictorial explanation. Also the mailing list discussion is interesting, particularly Lloyd Fournier's perspective:

lists.linuxfoundation.org/pipe

(13/n?)

Show thread
Sign in to participate in the conversation
unidentified instance

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!