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
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
