From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Ruben Somsen <rsomsen@gmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] SAS: Succinct Atomic Swap
Date: Tue, 12 May 2020 04:41:43 +0000 [thread overview]
Message-ID: <OyxLj_9i4yfbKGK-W0GXc2V9bQA3RJBPGHmPUz3OtwG6ZMCpRwgXtuFl9E_aDi4M_VP3cNIVoqj3mIjTJ_2rRdGuWyoJcNNCKs2G6znGhck=@protonmail.com> (raw)
In-Reply-To: <CAPv7TjYePyEt2YMg3J_KinK6Lv6SSLAF2nrOj79_oVt8qBXN0w@mail.gmail.com>
Good morning Ruben,
> 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
>
> I agree, I didn't mean to imply that was new, only that this protocol
> makes it more efficient.
>
Indeed; basically, any innovations in cross-chain swaps can be adapted to a CoinSwap (though not necessarily vice-versa, if a CoinSwap innovation requires certain specific blockchain features).
> > "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
>
An interesting setup.
So I was wondering why something like this would not work instead:
0. Alice has BTC, Bob has LTC, they agree on exchange rates and two future timelock L1 and L2 such that L1 < L2.
1. Alice creates keypairs Alice[0] Alice[1] Alice[2], Bob creates Bob[0] Bob[1] Bob[2], and share the pubkeys.
2. Alice creates, but does not sign, a funding tx on BTC whose output requires Alice[0] && Bob[0].
3. Bob creates a backout transaction spending the BTC funding txo, with an absolute timelock L1, whose output goes to Alice[2], then provides to Alice a signature for Bob[0] and requires an adaptor such that completing the signature with Alice[0] reveals Alice[1].
nLockTime L1
BTC funding txo ---> Alice[0] && Bob[0] ---> Alice[2]
reveals Alice[1]
4. Alice creates a timeout transaction spending the BTC funding txo, with an absolute timelock L2, whose output goes to Bob[2], then provides to Bob a signature for Alice[0] and requires an adaptor such that completing the signature with Bob[0] reveals Bob[1].
nLockTime L2
BTC funding txo ---> Alice[0] && Bob[0] ---> Bob[2]
reveals Bob[1]
5. Alice signs the BTC funding tx and broadcasts it.
6. Alice and Bob wait for the BTC funding tx to be confirmed.
7. Bob creates an LTC funding tx whose output requires Alice[1] && Bob[1].
8. Alice and Bob wait for the LTC funding tx to be confirmed.
9. Alice creates a success transaction spending the BTC funding txo, with no practical absolute timelock (current blockheight + 1), whose output goes to Bob[2], then provides to Bob a signature for Alice[0] and requires an adaptor such that completing the signature with Bob[0] reveals Bob[1].
nLockTime now
BTC funding txo ---> Alice[0] && Bob[0] ---> Bob[2]
reveals Bob[1]
10. Bob gives the secret key of Bob[1] to Alice.
11. Alice gives the secret key of Alice[0] to Bob.
12. Bob claims the BTC funding txo before L1.
Aborts and stalls:
* Aborts before step 5 are safe: no money is ever committed yet.
Stalls before step 5 can be promoted to aborts.
* If aborted between step 5 and step 8, Alice reclaims her BTC via the backout transaction.
Since Bob did not confirm any locked funds in LTC, revealing Alice[1] does not give Bob any extra funds it did not already have.
If Bob stalls before step 8 Alice can abort at L1 using the backout transaction.
* If Alice stalls at step 9, Bob can force the completion using the timeout transaction at L2, revealing Bob[1] and claiming the BTC.
* If Alice instead aborts at step 9 using the backout transaction at L1, Bob learns Alice[1] and can reclaim its LTC.
* Steps 10 and 11 are optional and "only" give Alice and Bob extra flexibility in what they can do with the funds (such as sweeping multiple swaps, RBFing, performing another swap, etc.), i.e. private key turnover.
Bob can always claim the BTC funding txo before L1 by signing and broadcasting the success transaction.
Would this not work?
It requires that at least one chain involved supports witness segregation, in order to allow signing a dependent transaction before signing what it spends.
This has the advantage of using only absolute timelocks, which are better for privacy since ordinary wallets like Bitcoin Core and C-Lightning use absolute timelocks for ordinary spends onchain.
>
> Unfortunately this does not hold for the revoke transaction. It would
> be a bit awkward if Alice had a high fee copy after the protocol
> completes. She could send it to the blockchain and essentially Bob
> would be paying for it. I'm not as concerned about the other
> transactions, because those could all be bumped with CPFP if needed,
> but having different feerates would be nice.
>
> And a general comment about privacy: it seems inevitable that some
> information will be leaked if the protocol does not complete
> cooperatively. As long as the cooperative case is not traceable, that
> seems about as good as it can get. That's my view, at least. I'd be
> curious to hear if you see that differently.
If the above counterproposal would work, it seems to me that all abort and stall scenarios "just" involve an absolute-timelock `SIGHASH_ALL` signed transaction, so it might not be so inevitable.
In addition, the above counterproposal has the transaction signatures be completed by whoever ends up getting the money, so will rationally use the version with the best feerate.
While leaking information in case of uncooperative abort is acceptable, it still seems to me that in this case, we can have a solution where an uncooperative abort has no information leak.
My thesis is that, if relative locktimes are used as often as absolute locktimes for block-sniping-prevention and a decent Scriptless Script system, then all protocol aborts should be doable with no information leaks, at the cost of pre-signing a bunch of timelocked transactions.
---
A sidenote as well, that if Alice typically uses an HD wallet, the UTXO on the LTC side would not be in that HD, and if Alice wants to cold-store the LTC, it should move the money as well into an HD pubkey.
Regards,
ZmnSCPxj
next prev parent reply other threads:[~2020-05-12 4:41 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-11 15:29 Ruben Somsen
2020-05-11 16:45 ` ZmnSCPxj
2020-05-11 17:50 ` Ruben Somsen
2020-05-12 4:41 ` ZmnSCPxj [this message]
2020-06-03 9:04 ` Dmitry Petukhov
2020-06-03 14:36 ` ZmnSCPxj
2020-05-12 22:50 ` Chris Belcher
2020-05-12 6:10 ` Lloyd Fournier
2020-05-12 6:50 ` Lloyd Fournier
2020-05-12 11:30 ` Ruben Somsen
2020-05-12 11:34 ` Ruben Somsen
2020-05-12 15:05 ` ZmnSCPxj
2020-05-12 16:30 ` Ruben Somsen
2020-05-13 8:39 ` ZmnSCPxj
2020-05-13 9:57 ` Ruben Somsen
2020-05-13 9:58 ` Ruben Somsen
2020-05-13 11:39 ` ZmnSCPxj
2020-05-13 12:33 ` Ruben Somsen
2020-05-15 4:39 ` ZmnSCPxj
2020-05-15 19:47 ` Ruben Somsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='OyxLj_9i4yfbKGK-W0GXc2V9bQA3RJBPGHmPUz3OtwG6ZMCpRwgXtuFl9E_aDi4M_VP3cNIVoqj3mIjTJ_2rRdGuWyoJcNNCKs2G6znGhck=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=rsomsen@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox