Re: [bitcoin-dev] SAS: Succinct Atomic Swap

[Chris Belcher <belcher@riseup.net>]

Hello list,

This proposal is very cool. It is very useful to have a coinswap scheme
requiring only two transactions.

As well as improving the scalability of the system by saving block
space, it also improves privacy because the coins could stay unspend for
a long time, potentially indefinitely. While in the original coinswap
proposal an analyst of the chain would always see a funding transaction
followed closely in time by a success transaction, and this could be
used as a fingerprint.

On 11/05/2020 18:50, Ruben Somsen via bitcoin-dev wrote:
> Hi ZmnSCPxj,
> 
> Thanks for your feedback :)
>
>> CoinSwap for privacy is practically a "cross" chain atomic swap with the same chain and token for both sides of the swap, see also this set of ideas: https://github.com/AdamISZ/CoinSwapCS/issues/53
>>
>> "Instead, Bob simply hands secretBob to Alice" is basically the same as private key turnover
> 
> Thanks for the link. I will add it to the links at the bottom of the
> write-up, as I agree it's related. Do note there are a few key
> differences:
> 
> - The swap is set up in an "asymmetric" way with only timelocks on one
> side, so on the other side the swap *never* expires
> - The timelocks are set up in such a way that the swap does not expire
> unless Alice starts the relative timelock countdown (the revoke
> transaction)
> - This relative timelock setup comes practically for free, because the
> asymmetry naturally requires that kind of setup

You could create an old-style coinswap scheme using relative timelocks
(with OP_CSV). The original proposal uses absolute timelocks but there's
no reason relative timelocks can't be used instead, as long as the party
who starts with knowledge of the preimage has a timelock further away in
the future.

Using relative timelocks and private key handover for old-style
coinswaps would give us the same two-transaction effect and the
corresponding efficiency and privacy gains.

Of course we still don't get the effect that the swap on the other side
never expires.

A fun fact is that the idea of private key handover was mentioned as
early as 2016 in the original Lightning Network paper. The bottom of
page 27 says: "Instead  of disclosing the BR1a/BR1b signatures, it’s
also possible to just disclose the private keys to the counterparty.
This is more effective as described later in the key storage section".
Although it looks like nobody thought to apply it to coinswap or
realized the benefits.


Regards
CB