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
|
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 9227AC0051
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 3 Sep 2020 09:46:08 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by silver.osuosl.org (Postfix) with ESMTP id 7EF1920501
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 3 Sep 2020 09:46:08 +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 uDgrROtuzK3q
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 3 Sep 2020 09:46:05 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40141.protonmail.ch (mail-40141.protonmail.ch
[185.70.40.141])
by silver.osuosl.org (Postfix) with ESMTPS id 5BBEC20373
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 3 Sep 2020 09:46:05 +0000 (UTC)
Date: Thu, 03 Sep 2020 09:45:53 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail; t=1599126362;
bh=1M2XM5/p2UK6ENhs76salrku2QJ05Z4Z5p8VyyXMmSk=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
b=mxfhpQJze+DKV9L6VkriFnGDYzArLv6JbKfFiXJ8apn0OepGh1z0auCGiyzoI8aS0
fkQTm0jl5mmdgFts0MTcSMswzq4UnbWR5mMOfJwa9kCaD1MegxktmS0h4GyFoaEY7t
LNITiWuvbV9Mr+aps2khD+I5pqeUzGlNHkFnB/XM=
To: Chris Belcher <belcher@riseup.net>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <bqFuDDJpKgkg1DaEQ9p14lxD__yLcJmklNqSK3jhmHxjxmhRYgHGJnUDDWMKfkZTJu-VqhFkVX4P2w6ipYuHpJ6umPmwe44PQs3HoNELEg4=@protonmail.com>
In-Reply-To: <0ac3fecb-012b-e210-55bb-36809682634a@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>
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 09:46:08 -0000
Good morning Chris,
> A big downside is that it really ruins the property of allowing coins to
> remain unspent indefinitely. That has privacy implications: if a coin
> remains unspent for longer than 2 weeks (or another short locktime) then
> for sure the transaction was not a CoinSwap, and so the anonymity set of
> the CoinSwap system would be far smaller For this reason I'm pretty
> desperate to solve the vulnerability without losing the coins remaining
> unspent indefinitely feature.
Ah, right.... accept no small privacy leaks!
>
> We need to solve the vulnerability you found, which I'll call the
> riskless theft attempt problem. So what do you think of this solution:
>
> =3D=3D Building block 1: A, B and C having different contract txes =3D=3D
>
> In the original proposal each CoinSwap peer has the same contract
> transaction, and either side can broadcast it whenever they like. This
> actually isn't necessary. We can have a contract transaction
> fully-signed but only known to one peer, with a possibly-different
> transaction transaction fully-signed and only known to the other peer.
>
> Obviously for the CoinSwap to work both contract transactions must have
> the same hash-time-locked contract, but they can differ in other ways.
>
> =3D=3D Building block 2: collateral payments =3D=3D
>
> The riskless theft attempt problem happens because the previous owner of
> the coins knows the fully-signed contract transaction and can broadcast
> it at no cost to themselves. So to solve the problem we add a cost.
>
> There is a 2of2 multisig made up of Bob's and Charlie's keys. The
> associated contract transaction known to Bob must now also have one of
> Bob's single-sig inputs. The outputs are such that some of the money
> from Bob's input now ends up in the HTLC output. The result is that
> after the CoinSwap if Bob broadcasts his contract transaction but fails
> to take the money from the HTLC output, then Bob will have lost money.
Just to be clear:
* B is the one who originally funded the HTLC, and owns the timelock.
* C is the one who will accept the HTLC, and owns the hashlock.
> I'm calling this idea collateral payments, by analogy with collateral
> used for loans. A collateral is someone valuable a debtor puts on the
> table, and if they don't repay the loan then they lose the collateral
> (presumably the creditor sells it to repay the loan).
>
> Here is a diagram of the contract transaction known to Bob:
>
> multisig (B+C) [I btc]---> (B+timelock_B OR C+hash) [I+K-M~ btc]
>
> collateral(B) [J btc] (Bob) [J-K btc]
>
>
> where:
> I =3D CoinSwap amount
> J =3D Value of Bob's collateral input
> K =3D Value that Bob loses if he broadcasts his contract tx but doesnt
> get the money
> M~ =3D miner fee (random variable)
>
> The value K is something that can be set by the protocol, and made high
> enough so that doing a riskless theft attempt is not worth it. Probably
> the value of K will be quite small because the odds of a riskless
> payment attempt succeeding is very small (assuming the makers all use
> multiple redundant watchtowers). Mostly likely K will be smaller than
> M~, so if the collateral is lost to Bob then the miners will the ones to
> gain, rather than Charlie.
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 valu=
e K, that it cannot swap (because if it tried to swap that amount, it would=
be unable to provide a collateral as well).
How much does C need to know about the B collateralized contract transactio=
n?
At the minimum, it has to know the output pays out to the correct contract,=
so it seems to me it has to know the entire B collateralized contract tran=
saction, 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 input o=
f B is now learned by C as having the same ownership as B.
A fresh maker that is given its starting funds in a single UTXO needs to sp=
lit up its funds to make at least one collateral input it can use.
Of note is that the B output also serves as a point for CPFPing this transa=
ction, thus only one version of the B collateralized contract transaction n=
eeds to be made, and the B collateralized contract transaction can be at or=
close to the minimum relay feerate and later CPFPed.
In terms of onchain analysis heuristics, it looks like the B output is chan=
ge, while the B+C contract output is the send-out, I think, for most cases.
In case of a protocol abort, this heuristic is misled, since both outputs b=
ecome owned by B due to the protocol abort.
In case of a protocol completion, this heuristic is accurate, since the B+C=
contract output will be claimed by C, but we do not expect this transactio=
n to be confirmed onchain after protocol completion anyway (it effectively =
donates K to C or miners), so this is fine.
> The other contract transaction, known only to Charlie, does not contain
> a collateral input or collateral value (K), because Charlie can't do a
> riskless theft attempt to Bob.
Because it has a single output only, the C contract transaction needs to ha=
ve RBFed versions.
> If Bob ever spends his collateral input in another transaction, then his
> contract transaction will become invalid. However Bob will only be
> harming himself, so he'll never do this.
At least until B gets its own incoming funds in the swap, at which point th=
e collateral input can be used for other purposes (and effectively "release=
s" the lease of B on that output).
Since C knows the collateral input (it has to, in order to verify the B col=
lateralized contract transaction is correct), it can monitor the collateral=
input for spendedness, and stop watching for the B collateralized contract=
transaction in its watchtower(s) if the collateral input is deeply spent.
The B collateralized contract transaction is invalidated if the collateral =
input is spent, and then only C can spend the funding outpoint at that poin=
t, so it can remove that from the watchtower.
This can be significant if C is using a for-pay watchtower that supports de=
letion of watches, which I believe is planned for watchtowers as well, and =
reduces the operating cost of C.
Regards,
ZmnSCPxj
|
