Date: Fri, 15 May 2020 04:39:33 +0000
To: Ruben Somsen <rsomsen@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <Wi0Hnr40e1Zhe_F5SfprEkMgCNmcvhJsGAdlEpJDWO1kKsGIsg0hEHKA-YyeMt7NBYa7nMPiePpOEjefcO6epuLVfyuweXJjjX-YfRpw4DQ=@protonmail.com>
In-Reply-To: <CAPv7TjaG3jxCDv5PtSeLeXi3Emo1_hvgYP1KEQg8+LU41SUqqQ@mail.gmail.com>
References: <CAPv7TjZGBbf6f1y49HLFD2eNiP5d4e+=dFGqiMFs6jaeYyH-NQ@mail.gmail.com>
 <CAPv7TjYqC73zRQq2yQy9RpeHUUexjSS23uU9VwJvvoRr50p2vA@mail.gmail.com>
 <Mpqd20ZM9-93dIIhe1yS4QEGKmzT-uuBrAn1e4omDbA1YJvXrEmZ3IZeoz90s5AHVLAdYwF0PhxgMZwqDdHxQ0UQw2eEEytngEXSsXeLM14=@protonmail.com>
 <CAPv7TjbfuV1YvgTS4pjr_56R_-=spb9DzPwqP1HFCBOZpSOq8Q@mail.gmail.com>
 <2-ZZw_6q-EBo5DmIK5PtzWCE9zd9FdNtYuhFf84FKxRHwmL7g7kA9YvYB9iqFFkGy_xoXARzRW8hiZa-ZcLPWeZ60PNMQc9yMdZLnTsp1yo=@protonmail.com>
 <CAPv7TjZAv_tVn=Wxf3LpfMmAzj8+mWiLr+7HMjjNArD7ThKO_A@mail.gmail.com>
 <CAPv7TjYewKe=Gt8io+uGNzeKmAq758vH9aB2OpFt=rGth8DZEg@mail.gmail.com>
 <oIiSWK9E-M53lQD3BxO8vQBHzZ7vUSISzDElSaA0v3BFS4_WeFAHNybHttJLstlAiz6Xem4VWy9Ktp6hgklsPqkvqnKVMOUAuA_aKpjOFLA=@protonmail.com>
 <CAPv7TjaG3jxCDv5PtSeLeXi3Emo1_hvgYP1KEQg8+LU41SUqqQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] SAS: Succinct Atomic Swap
Precedence: list

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 ta=
proot): "Alice & Bob OR Alice in=C2=A0+1 day" (relative) so if Alice broadc=
asts it after protocol completion, she is just giving Bob the key to her LT=
C (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 ti=
melock expires. No chaos.

Ah, that explains the existence of the Alice && Bob clause in that output t=
hen.

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=
 collusion.

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 becom=
e valid, and it is the best policy for Bob to just spend the BTC txo well b=
efore 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 fun=
d 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 history.

(Do note the objections under "Directionality" in https://zmnscpxj.github.i=
o/bitcoin/multiswap.html though; a counter to this objections is that the a=
nalysis there is only applicable if the surveillor already identified the C=
oinSwap sequence, but hopefully the increased steganography of CoinSwaps me=
ans they are not identifiable anyway.)

Since Bob really should spend its received coin before a timeout, it is bes=
t 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 wall=
et it controls, reducing the key backup load on the client to be the same a=
s 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 wa=
llet must be done via a swap (similar to a rule imposed by JoinMarket where=
 sendpayment.py 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 noth=
ing in the SAS protocol allows Alice to receive its funds directly into a s=
pecific third-party address.
However, Bob can hand over a specific third-party address to use in the suc=
cess tx.
Indeed, the SAS protocol can be modified so that Bob can specify a set of a=
ddress/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 t=
he third-party service, in order to give some additional leeway later for R=
BF once Alice hands over the Alice privkey and Bob can remake the success t=
x (and more importantly, ensure the txo is spent before refund tx #1 becoms=
 valid).


Regards,
ZmnSCPxj