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

From: Dmitry Petukhov <dp@simplexum•com>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] SAS: Succinct Atomic Swap
Date: Wed, 3 Jun 2020 14:04:25 +0500	[thread overview]
Message-ID: <20200603140425.2a4e9d60@simplexum.com> (raw)
In-Reply-To: <OyxLj_9i4yfbKGK-W0GXc2V9bQA3RJBPGHmPUz3OtwG6ZMCpRwgXtuFl9E_aDi4M_VP3cNIVoqj3mIjTJ_2rRdGuWyoJcNNCKs2G6znGhck=@protonmail.com>

I made a version of the TLA+ spec according to the suggested variant,
as I understood it from your description. This version is in
the separate branch in the SASwap repo, 'variant_ZmnSCPxj' [1]

If I understood and specified your variant correctly, there is a
deadlock possible after step 9, if Bob fails to publish success tx in
time. After refund tx becomes spendable, Alice cannot publish it via
mempool, because Bob can learn her secret and has a chance invalidate
her refund tx by giving his success tx to friendly miner, while taking
back the locked LTC because both secrets are known. At the same time,
Bob cannot publish success tx via mempool, because then Alice can do
the same thing, invalidating his success tx with refund tx via friednly
miner.

There is a possibility that this deadlock can be resolved if one
participant indeed has possibility to confirm their tx directly,
bypassing the mempool, so the counterparty won't learn the secret until
transaction is in the block. But then this just raises the cost of the
attack because the counterparty will need to invalidate (orphan) the
whole block instead of just a transaction in the mempool, after
learning the other secret from the recent block.

[1] https://github.com/dgpv/SASwap_TLAplus_spec/tree/variant_ZmnSCPxj

В Tue, 12 May 2020 04:41:43 +0000
ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:

> 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