Good morning Ruben,

> Hi ZmnSCPxj,
> >on completion of the protocol, if Bob lets the refund tx#1 become valid 
> >(i.e. does not spend the BTC txo) then Alice can broadcast it, putting both 
> >their funds into chaos
> You forget, refund tx #1 has a script (which btw won't be visible with 
> taproot): "Alice & Bob OR Alice inĀ +1 day" (relative) so if Alice broadcasts 
> it after protocol completion, she is just giving Bob the key to her LTC 
> (note: if she's wise she'd move the LTC beforehand), but Bob doesn't lose the 
> BTC because he has both keys and can just react before the relative timelock 
> expires. No chaos.

Ah, that explains the existence of the Alice && Bob clause in that output then.

The attack is now as follows:

* Alice completes the protocol up to handing over `sigSuccessAlice` to Bob.
* Bob returns the `secretBob`.
* Alice stalls the protocol and never sends the `Alice` privkey, and waits for 
1 day, then sneaks the refund tx #1 and spends the LTC via direct miner 

The proper response here is that Bob should broadcast success tx before the 
refund tx #1 becomes valid.
(Which I think is the point: chaos can only occur if you let backouts become 
valid, and it is the best policy for Bob to just spend the BTC txo well before 
the timeout.
Even if the protocol is completed, without a bring-your-own-fees that lets you 
malleate the tx (i.e. CPFP hooks still require the transction itself to reduce 
the fund by at least the minimum feerate), at least part of the fund must be 
lost in fees and Bob can still suffer a small loss of funds.)


Tangentially, I now think in the case of client-server CoinSwap, the server 
should take Alice position and the client should take Bob position.

Suppose a client wants to do some mixing of its own received coins.
It should not depend on only one server, as the server might secretly be a 
surveillor (or hacked by a surveillor) and recording swaps.
Thus, a client will want to make multiple CoinSwaps in sequence, to obscure its 

(Do note the objections under "Directionality" in though; a counter to this 
objections is that the analysis there is only applicable if the surveillor 
already identified the CoinSwap sequence, but hopefully the increased 
steganography of CoinSwaps means they are not identifiable anyway.)

Since Bob really should spend its received coin before a timeout, it is best 
for Bob to be the client; it is likely that the client will need to swap "soon" 
again, meaning it has to redirect the funds to a new 2-of-2 anyway.

For the final swap, the client can then spend the final coins to an HD wallet 
it controls, reducing the key backup load on the client to be the same as 
normal HD wallets.
Presumably the server in this situation has greater ability to dynamically 
update its backups to include key backups for `secretAlice` keys.

Further, if the client program has the policy that all spends out of the wallet 
must be done via a swap (similar to a rule imposed by JoinMarket where always does 1 CoinJoin), then this still matches well with the 
requirement on Bob to spend the fund before the first timeout of refund tx #1.

If the client needs to spend to a classic, address-using service, then nothing 
in the SAS protocol allows Alice to receive its funds directly into a specific 
third-party address.
However, Bob can hand over a specific third-party address to use in the success 
Indeed, the SAS protocol can be modified so that Bob can specify a set of 
address/value pairs to be put in the success tx instead of just Bob pubkey; for 
example, Bob might swap more than the amoutn that needs to be paid to the 
third-party service, in order to give some additional leeway later for RBF once 
Alice hands over the Alice privkey and Bob can remake the success tx (and more 
importantly, ensure the txo is spent before refund tx #1 becoms valid).

bitcoin-dev mailing list

Reply via email to