1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id A0CBCC016F
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 15 May 2020 04:39:44 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by silver.osuosl.org (Postfix) with ESMTP id 87D102E1C6
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 15 May 2020 04:39:44 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from silver.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id S7XpLVbFPn3B
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 15 May 2020 04:39:39 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch
[185.70.40.132])
by silver.osuosl.org (Postfix) with ESMTPS id 4EB122E1BB
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 15 May 2020 04:39:39 +0000 (UTC)
Date: Fri, 15 May 2020 04:39:33 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail; t=1589517576;
bh=OTyZ1Xyl682L6jhzFNEJbJ5UafqV+yyT1deMeaZ15aA=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
b=h9kQmdqojUQhHV4a4v0z+p970xZDejMM2JC6x1uCRRYYMVLXtYJPEWSUYVArRbuJH
Fn+x2YSZg+XLrTAYYb1HAsJjulTQxCBhQ3EpDldVyH4FS02fBsg0OcmmnYpXG5w9nB
/0lZ4aU0DahEgJFvtzaPQEB0mELEvsRsG/iEHFjU=
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
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 15 May 2020 04:39:44 -0000
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
|
