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
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
|
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 E2B99C0051
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 3 Sep 2020 23:39:15 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by silver.osuosl.org (Postfix) with ESMTP id C22102E16B
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 3 Sep 2020 23:39:15 +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 YsFmf+GVh7xh
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 3 Sep 2020 23:39:13 +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 D33A72E154
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 3 Sep 2020 23:39:12 +0000 (UTC)
Date: Thu, 03 Sep 2020 23:39:02 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail; t=1599176350;
bh=9pgXrmJsTrena4G2wRITIq+x9a32Qe8Y9igOequXFlA=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
b=gV7k1gr2JKpAgupsfb6xKqK2JpspEfBh0umQ/4z4V0RiBTKDluLYMPQb2RTm/Hlja
uJxArMymrTjBVo2SCU5w1EdBwlPgP7TEApeK7DQDt757r4YQeeDs5GzyIrxswhunp0
VQSIbd/jDz3JNszsTnOUVrqVzlLUZjCknKWoWYgM=
To: Chris Belcher <belcher@riseup.net>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <Vf-RtORZUR0QYHZiYeyfVyJEIQbh0RYnPpZEeeDiIwaiGvu-R9wxhHm6D4b_Nwd8Ia2n6u2OL4u48Ra6t8BGWOCgGXJpFkFWQeAX2S4ijiI=@protonmail.com>
In-Reply-To: <8f387b40-8212-9807-70cc-b527902609c2@riseup.net>
References: <813e51a1-4252-08c0-d42d-5cef32f684bc@riseup.net>
<CALZpt+GxKDEDAGUH3Jb3rcZdh_jy_depLRE5KzGTpkZOLVH+QA@mail.gmail.com>
<VpsctPiYOV704v9wZiSROdRggid7uRv2mZVnCIILEPL4_VmwKhMVdNMPBj9XaF73-39jFLl3cq1o2tSk8h45tMuWM9W_i4_MQHKoJdYh9ew=@protonmail.com>
<0ac3fecb-012b-e210-55bb-36809682634a@riseup.net>
<bqFuDDJpKgkg1DaEQ9p14lxD__yLcJmklNqSK3jhmHxjxmhRYgHGJnUDDWMKfkZTJu-VqhFkVX4P2w6ipYuHpJ6umPmwe44PQs3HoNELEg4=@protonmail.com>
<8f387b40-8212-9807-70cc-b527902609c2@riseup.net>
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] Detailed protocol design for routed
multi-transaction CoinSwap
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: Thu, 03 Sep 2020 23:39:16 -0000
Good morning Chris,
> > This seems a great solution!
> > Since B is the one offering HTLCs, the taker of a CoinSwap sequence can=
be B as well.
> > This means, the taker has to have some collateral input, of at least va=
lue K, that it cannot swap (because if it tried to swap that amount, it wou=
ld be unable to provide a collateral as well).
> > How much does C need to know about the B collateralized contract transa=
ction?
> > At the minimum, it has to know the output pays out to the correct contr=
act, so it seems to me it has to know the entire B collateralized contract =
transaction, meaning it learns another input of B ("collateral(B)") that is=
not otherwise involved in the CoinSwap.
> > This is important, again, if B is a taker, as it means an unrelated inp=
ut of B is now learned by C as having the same ownership as B.
>
> Yes, in fact that's why in my example I talk about a CoinSwap between
> two makers Bob and Charlie. Makers can be reasonably expected to own
> multiple UTXOs, but takers cannot. As you say because collateral
> payments breaks the ability of takers to sweep their entire wallet
> through CoinSwap.
>
> Happily, I think takers themselves don't need to use collateral
> payments. Here's an argument to why:
>
> Riskless theft attempts by the taker who no longer controls the coins
> actually isnt riskless or costless: Because it reduces the privacy of
> the previously-owned coins. If a taker genuinely wanted good privacy
> (Which, after all, they're paying for via miner fees and CoinSwap fees)
> then they would benefit if the coins they no longer own remain unspent
> for a long time, because it increases their anonymity set by making them
> hide among a greater crowd of coins which also don't get spent for a
> long time.
Hmmm.
The attack can only be mounted after protocol completion.
Thus, at that point, makers have made money, and takers have paid.
And taker is now in possession of a coin unlinked with its original coin, w=
hich is what it paid for.
However, if the taker considers the maker fee it has already paid as a sunk=
cost, then it would still be rational of them to mount this attack (sunk c=
osts should be ignored).
From this point-of-view, it is possible to do so with only a *subsequent* p=
otential gain, and still no downside.
For example, suppose the taker has already performed an "honest" CoinSwap.
Then, it is now in possession of a UTXO that is not linked with its income =
stream.
It can then perform another CoinSwap, and *then* perform the attack.
This reveals that the UTXO it provided is involved in a CoinSwap due to pub=
lication of the contract transaction, which is not a loss in this case sinc=
e the UTXO it put in was not linked to its income stream already, via a pre=
vious non-attacked CoinSwap.
A taker might rationally consider doing riskless costless theft with its al=
ready-delinked coins if it assesses that some maker is not sufficiently onl=
ine and with insufficient watchtowers (both operating expenditures!) that i=
t has some probability of success times amount it has to seed the theft, ve=
rsus the fee of that maker plus miner fees.
In response, a maker that is forced to accept a sweeping taker will raise i=
ts fee, so as to disincentivize this attack using already-delinked coins.
Hmmm.
In addition, post-Scriptless-Script, assuming relative-locktime-use is "nor=
malized" as proposed in https://lists.linuxfoundation.org/pipermail/lightni=
ng-dev/2020-January/002412.html , then the "contract transaction" and its t=
imelock-path-transaction look exactly the same as ordinary (P2SH-)P2WPKH si=
ngle-input-single-output transactions, thus in that case the taker does ***=
not*** lose any privacy.
This removes whatever protection you can get from contract transaction blac=
kmail.
--
The above suggests to me that you still want the collateralized contract tr=
ansaction from the taker as well.
A sweeping taker can split its funds in half, swapping one half (and using =
the remainder for collateral input), then after that swap, using the alread=
y-swapped coins for the collateral input of the remaining unswapped coins.
This leaks information: you are now linking a post-mix coin with a pre-mix =
coin, not onchain (if you do not mount an attack, which you probably will n=
ot) but you *do* reveal this information to the maker (one input is from th=
e funding tx that is pre-mix, the collateral input is from the post-mix coi=
n).
The only protection here is that the maker is unaware of the fact that your=
input coin is pre-mix and your collateral input is post-mix, so it can be =
hard for a maker to *use* this information.
However, it might be possible to prevent the maker from learning the collat=
eral input at all.
If my understanding of BIP-143 is correct, inputs are hashed separately (`h=
ashPrevouts`) from outputs (`hashOutputs`).
Bob can provide the `hashPrevouts` as an opaque hash, while providing a dec=
ommitment of `hashOutputs` to show that the outputs of the collateralized c=
ontract transaction are correct, which is all that Charlie really needs to =
know.
Bob is incentivized to provide the correct `hashPrevouts`, because if it pr=
ovides an incorrect `hashPrevouts` it cannot get a signature for a transact=
ion it can use in case of a protocol abort, thus potentially losing its mon=
ey in case of a protocol abort.
Conversely, Charlie does not care *where* Bob gets the funds that goes into=
its contract output come from, it only cares that the Bob collateralized c=
ontract output is I+K.
It loses nothing to sign that transaction, and it would prefer that transac=
tion since its own contract output is only I.
This solution is mildly "unclean" as it depends on the details of the sigha=
sh algorithm, though, and is not proposed seriously.
Hopefully nobody will change the sighash algorithm anytime soon.........
In addition, it complicates reusing Lightning watchtowers.
Lightning watchtowers currently trigger on txid (i.e. it would have trigger=
ed on the txid of the B collateralized contract tx), but watching this need=
s to trigger on the spend of a txo, since it is not possible to prove that =
a specific `hashPrevouts` etc. goes with a specific txid without revealing =
the whole tx (which is precisely what we are trying to avoid), as both are =
hashes.
Watchtowers may need to be entrusted with privkeys, or need to wait for `SI=
GHASH_ANYPREVOUT` so that the exact txid of the B collateralized contract t=
x does not need to be fixed at signing time, thus this solution is undesira=
ble as well.
Regards,
ZmnSCPxj
|
