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
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
|
Return-Path: <antoine.riard@gmail.com>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 84F0EC0177
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Feb 2020 18:27:07 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by silver.osuosl.org (Postfix) with ESMTP id 6CB862051C
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Feb 2020 18:27:07 +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 hF8H4IAkDAcB
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Feb 2020 18:27:05 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-pj1-f66.google.com (mail-pj1-f66.google.com
[209.85.216.66])
by silver.osuosl.org (Postfix) with ESMTPS id 154BC20500
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Feb 2020 18:27:05 +0000 (UTC)
Received: by mail-pj1-f66.google.com with SMTP id 12so114654pjb.5
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Feb 2020 10:27:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=tjvljFNG1wzZrQameEXm2Q2FADZ/qylV22JJFju+Ijw=;
b=YzZ+GVq/SdyAplxUcsOAj/vh+2ML8ugeVaInUWaQo9iJz+h/+m1OYBQn88CnNzrZBC
+fCP5tWXwmXlyzh+0Vv+c0DHuYYzAW1QuiWT53IC1VTKMf0qo3R9aO6036LTwGIz0hTj
DipdlA3lr5Ns2L+6ZVnCunKw90vO9RnIQ2xJRx67Gp0R/Yp/NiGtVLhr9ZTZ4HLh9fWO
C2Gwjqw8Dan8BrUmFMuo3eclndHa/jRHzHmSoOmn++XYUEORcfV2IVVra+b5Rqi4u4tF
u9NQrVSM/m01vJfRZcWGC0sHUkAQAL3xORmb/8rz4jaECxvMglBf4IwQVnTdB7eQe82V
g97g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=tjvljFNG1wzZrQameEXm2Q2FADZ/qylV22JJFju+Ijw=;
b=a6lf0sIrwFg7CTjLZFI0kuMlJj6kOgHcylT06Hms6n+eMw6GsRUIIjOtXrxpAzSMlp
TIau+nvgfqWMqXFGNMPghTrYSFCkgbfEP7lfwzjXN9WA/ycyu4k1hoerlhAzrkm2LV7B
vMwIn/BzpdwNgSdOGbkrHiq3jK/Ym/uThROu17+QEKI/G+duC7QDFMNzK3DZDdcJIoYI
U2v6BwpQWtMfQMkDWW2UTbtMKch29euZ0KFVRKaZViGus4GfUjVmzvNKqYamclw69WeO
8h0BMYWMppyTwPs4mPk5vLZ54WianQvI2mdyR+7y4u5m+mTCp1kNPtSuZa1ujp/tP4Gm
7elg==
X-Gm-Message-State: APjAAAX3pLqwO+mrGbpu8zDOGCK1C+366rptkriVKNF/3wa1HsbZufId
HDH84cgyZoRnqpfWvAN/YLs7iwbMKMqAR467fhs=
X-Google-Smtp-Source: APXvYqyeNxueFH517vqHj6q0TjmWw9rBgIyyxU6ySM///Z9gIsT/owKyo2haIxatd+VSzg+c8C+oJt4YBNBvmBrLuq8=
X-Received: by 2002:a17:90a:2004:: with SMTP id n4mr482617pjc.20.1582568824529;
Mon, 24 Feb 2020 10:27:04 -0800 (PST)
MIME-Version: 1.0
References: <CALZpt+E4Mr=g8zw95tyteGh53DH1mZ2HhNzQdy92+ErTtx3VbQ@mail.gmail.com>
<wUeoSi98_WNKqyiqI0yZ7YKCjsWqBO4lprQkQXbO_VkrALVxaYWsMRvbgnsHMWXA7QsB2gp9N2-a-gLuxY74xQMXwdyYKsKyLbNe1OSUVoQ=@protonmail.com>
In-Reply-To: <wUeoSi98_WNKqyiqI0yZ7YKCjsWqBO4lprQkQXbO_VkrALVxaYWsMRvbgnsHMWXA7QsB2gp9N2-a-gLuxY74xQMXwdyYKsKyLbNe1OSUVoQ=@protonmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Mon, 24 Feb 2020 13:26:52 -0500
Message-ID: <CALZpt+H6g4ak_kzbNr-QwTd04YwqBqkmHL4ZYPxqxQLgtv9W6Q@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="0000000000009e66e0059f5684dc"
X-Mailman-Approved-At: Mon, 24 Feb 2020 18:40:40 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] LN & Coinjoin, a Great Tx Format Wedding
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: Mon, 24 Feb 2020 18:27:07 -0000
--0000000000009e66e0059f5684dc
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
> I notice your post puts little spotlight on unilateral cases.
> A thing to note, is that we only use `nSequence` and the weird watermark
on unilateral closes.
> Even HTLCs only exist on unilateral closes --- on mutual closes we wait
for HTLCs to settle one way or the other before doing the mutual close.
Yes, I'm only aiming LN-cooperative cases, as your noticed HTLCs only exist
on commitment txn and masquerading them in some Taptree would come
with its own challenges. Cooperative closings should be the majority of
channels if network is reliable and so would be a set big enough to achieve
the goal
of blurring Coinjoins among LN transactions.
Right now we don't use `nSequence` but the current interactive tx
construction proposal uses it for RBF (weird watermark was an example).
> On mutual closes, we should probably set `nLockTime` to the current
blockheight + 1 as well.
> This has greater benefit later in a Taproot world.
I assume mutual closes would fall under the aforementioned tx construction
proposal, so a closing may be a batch to fund other channels or
splice existent ones.
> A kind of non-equal-value CoinJoin could emulate a Lightning open +
close, but most Lightning channels will have a large number of blocks
(thousands or tens of thousands) between the open and the close; it seems
unlikely that a short-term channel will exist > that matches the
non-equal-value CoinJoin.
That's a really acute point, utxo age and spending frequency may be obvious
protocol leaks. Splicing may help there because a LN node would do multiple
chain writes during channel lifecycle for liquidity reasons but it's
near-impossible to predict its frequency without deployment. Even with
this, I do fear an analysis gap between Coinjoin spending delta and LN
ones. A way to circumvent this would be for CoinjoinXT to timelock its PTG
transactions to mimick actively-spliced LN channels. That's where adoption
of a common format by other onchain transactions than LN ones would help a
lot.
> Should always be on, even if we do not (yet) have a facility to
re-interact to bump fees higher.
> While it is true that a surveillor can determine that a transaction has
in fact been replaced (by observing the mempool) and thus eliminate the set
of transactions that arose from protocols that mark RBF but do not (yet)
have a facility to bump fees higher, this > information is not permanently
recorded on all fullnodes and at least we force surveillors to record this
information themselves.
Yes but if you do this for Core and given some merchants are refusing RBF
transactions for onchain payments, people are going to complain...
Also see footnote on spurious-RBF about not-having facility to bump fees
higher (you can sign multiple RBF transactions in 1-RTT and agree to
broadcast them later to obfuscate mempool analysis).
> However, it seems to me that we need to as well nail down the details of
this format.
Of course, just curious of people opinions right now but if it's a good way
to solve the described problem, will draft a spec.
Le sam. 22 f=C3=A9vr. 2020 =C3=A0 20:29, ZmnSCPxj <ZmnSCPxj@protonmail.com>=
a =C3=A9crit :
> Ggood morning Antoine, and list,
>
>
> > * nLocktime/nSequence
> > ...
> > * weird watermark (LN commitment tx obfuscated commitment number)
> > ...
> > LN (cooperative case):
>
> I notice your post puts little spotlight on unilateral cases.
> A thing to note, is that we only use `nSequence` and the weird watermark
> on unilateral closes.
> Even HTLCs only exist on unilateral closes --- on mutual closes we wait
> for HTLCs to settle one way or the other before doing the mutual close.
>
> If we assume that unilateral closes are rare, then it might be an
> acceptable risk to lose privacy in that case.
> Of course, it takes two to tango, and it takes two to make a Lightning
> channel, so ---
> In any case, I explored some of the difficulties with unilateral closes a=
s
> well:
>
> *
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/00=
2421.html
> *
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/00=
2415.html
>
> On mutual closes, we should probably set `nLockTime` to the current
> blockheight + 1 as well.
> This has greater benefit later in a Taproot world.
>
> > Questions:
> > * Are there any protocol-specific semantic wrt to onchain transactions
> incompatibility
> > between Coinjoin and cooperative LN txn ?
>
> A kind of non-equal-value CoinJoin could emulate a Lightning open + close=
,
> but most Lightning channels will have a large number of blocks (thousands
> or tens of thousands) between the open and the close; it seems unlikely
> that a short-term channel will exist that matches the non-equal-value
> CoinJoin.
>
> In particular, a LN cooperative close will, in general, have only one
> input.
> A new form of CoinJoin could, instead of using a single transaction, use
> two, with an entry transaction that spends into an n-of-n of the
> participants, and the n-of-n being spent to split the coin back to their
> owners.
> But again: a Lightning network channel would have much time with the fund=
s
> in a single UTXO before later splitting the funds,
> This also starts edging closer to CoinJoinXT territory.
>
> > * What about RBF-by-default ?
>
> Should always be on, even if we do not (yet) have a facility to
> re-interact to bump fees higher.
> While it is true that a surveillor can determine that a transaction has i=
n
> fact been replaced (by observing the mempool) and thus eliminate the set =
of
> transactions that arose from protocols that mark RBF but do not (yet) hav=
e
> a facility to bump fees higher, this information is not permanently
> recorded on all fullnodes and at least we force surveillors to record thi=
s
> information themselves.
>
> > * Core wallet or any other protocol or even batching algorithms could
> adopt
> > to this format ?
>
> It seems likely.
> However, it seems to me that we need to as well nail down the details of
> this format.
>
> > * Is artificially increasing the number of outputs to mimic Coinjoins t=
xn
> > acceptable wrt to utxo bloat/fees ?
>
> That is indeed an issue.
>
> Regards,
> ZmnSCPxj
>
--0000000000009e66e0059f5684dc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div><div><div>> I notice your post puts litt=
le spotlight on unilateral cases.<br>
> A thing to note, is that we only use `nSequence` and the weird waterma=
rk on unilateral closes.<br>
> Even HTLCs only exist on unilateral closes --- on mutual closes we wai=
t=20
for HTLCs to settle one way or the other before doing the mutual close.<br>=
<br></div>Yes, I'm only aiming LN-cooperative cases, as your noticed HT=
LCs only exist on commitment txn and masquerading them in some Taptree woul=
d come<br></div>with its own challenges. Cooperative closings should be the=
majority of channels if network is reliable and so would be a set big enou=
gh to achieve the goal<br></div><div>of blurring Coinjoins among LN transac=
tions. <br><br>Right now we don't use `nSequence` but the current inter=
active tx construction proposal uses it for RBF (weird watermark was an exa=
mple).<br></div><br>> On mutual closes, we should probably set `nLockTim=
e` to the current blockheight + 1 as well.<br>
> This has greater benefit later in a Taproot world.<span class=3D"gmail=
-im"><br></span><br></div>I assume mutual closes would fall under the afore=
mentioned tx construction proposal, so a closing may be a batch to fund oth=
er channels or<br></div>splice existent ones.<br><br>> A kind of non-equ=
al-value CoinJoin could emulate a Lightning open +=20
close, but most Lightning channels will have a large number of blocks=20
(thousands or tens of thousands) between the open and the close; it=20
seems unlikely that a short-term channel will exist > that matches the=
=20
non-equal-value CoinJoin.<div><div><br><div>That's a really acute point=
, utxo age and spending frequency may be obvious protocol leaks. Splicing m=
ay help there because a LN node would do multiple chain writes during chann=
el lifecycle for liquidity reasons but it's</div><div>near-impossible t=
o predict its frequency without deployment. Even with this, I do fear an an=
alysis gap between Coinjoin spending delta and LN ones. A way to circumvent=
this would be for CoinjoinXT to timelock its PTG<br></div><div>transaction=
s to mimick actively-spliced LN channels. That's where adoption of a co=
mmon format by other onchain transactions than LN ones would help a lot.<br=
><br>> Should always be on, even if we do not (yet) have a facility to r=
e-interact to bump fees higher.<br>
> While it is true that a surveillor can determine that a transaction ha=
s=20
in fact been replaced (by observing the mempool) and thus eliminate the=20
set of transactions that arose from protocols that mark RBF but do not=20
(yet) have a facility to bump fees higher, this > information is not=20
permanently recorded on all fullnodes and at least we force surveillors=20
to record this information themselves.<span class=3D"gmail-im"><br><br></sp=
an></div><div><span class=3D"gmail-im">Yes but if you do this for Core and =
given some merchants are refusing RBF transactions for onchain payments, pe=
ople are going to complain...<br></span></div><div><span class=3D"gmail-im"=
>Also see footnote on spurious-RBF about not-having facility to bump fees h=
igher (you can sign multiple RBF transactions in 1-RTT and agree to broadca=
st them later to obfuscate mempool analysis).<br><br>> </span>However, i=
t seems to me that we need to as well nail down the details of this format.=
<span class=3D"gmail-im"><br><br></span></div><div><span class=3D"gmail-im"=
>Of course, just curious of people opinions right now but if it's a goo=
d way to solve the described problem, will draft a spec.<br></span></div></=
div></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gm=
ail_attr">Le=C2=A0sam. 22 f=C3=A9vr. 2020 =C3=A0=C2=A020:29, ZmnSCPxj <<=
a href=3D"mailto:ZmnSCPxj@protonmail.com">ZmnSCPxj@protonmail.com</a>> a=
=C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x">Ggood morning Antoine, and list,<br>
<br>
<br>
> * nLocktime/nSequence<br>
> ...<br>
> * weird watermark (LN commitment tx obfuscated commitment number)<br>
> ...<br>
> LN (cooperative case):<br>
<br>
I notice your post puts little spotlight on unilateral cases.<br>
A thing to note, is that we only use `nSequence` and the weird watermark on=
unilateral closes.<br>
Even HTLCs only exist on unilateral closes --- on mutual closes we wait for=
HTLCs to settle one way or the other before doing the mutual close.<br>
<br>
If we assume that unilateral closes are rare, then it might be an acceptabl=
e risk to lose privacy in that case.<br>
Of course, it takes two to tango, and it takes two to make a Lightning chan=
nel, so ---<br>
In any case, I explored some of the difficulties with unilateral closes as =
well:<br>
<br>
* <a href=3D"https://lists.linuxfoundation.org/pipermail/lightning-dev/2020=
-January/002421.html" rel=3D"noreferrer" target=3D"_blank">https://lists.li=
nuxfoundation.org/pipermail/lightning-dev/2020-January/002421.html</a><br>
* <a href=3D"https://lists.linuxfoundation.org/pipermail/lightning-dev/2020=
-January/002415.html" rel=3D"noreferrer" target=3D"_blank">https://lists.li=
nuxfoundation.org/pipermail/lightning-dev/2020-January/002415.html</a><br>
<br>
On mutual closes, we should probably set `nLockTime` to the current blockhe=
ight + 1 as well.<br>
This has greater benefit later in a Taproot world.<br>
<br>
> Questions:<br>
> * Are there any protocol-specific semantic wrt to onchain transactions=
incompatibility<br>
> between Coinjoin and cooperative LN txn ?<br>
<br>
A kind of non-equal-value CoinJoin could emulate a Lightning open + close, =
but most Lightning channels will have a large number of blocks (thousands o=
r tens of thousands) between the open and the close; it seems unlikely that=
a short-term channel will exist that matches the non-equal-value CoinJoin.=
<br>
<br>
In particular, a LN cooperative close will, in general, have only one input=
.<br>
A new form of CoinJoin could, instead of using a single transaction, use tw=
o, with an entry transaction that spends into an n-of-n of the participants=
, and the n-of-n being spent to split the coin back to their owners.<br>
But again: a Lightning network channel would have much time with the funds =
in a single UTXO before later splitting the funds,<br>
This also starts edging closer to CoinJoinXT territory.<br>
<br>
> * What about RBF-by-default ?<br>
<br>
Should always be on, even if we do not (yet) have a facility to re-interact=
to bump fees higher.<br>
While it is true that a surveillor can determine that a transaction has in =
fact been replaced (by observing the mempool) and thus eliminate the set of=
transactions that arose from protocols that mark RBF but do not (yet) have=
a facility to bump fees higher, this information is not permanently record=
ed on all fullnodes and at least we force surveillors to record this inform=
ation themselves.<br>
<br>
> * Core wallet or any other protocol or even batching algorithms could =
adopt<br>
> to this format ?<br>
<br>
It seems likely.<br>
However, it seems to me that we need to as well nail down the details of th=
is format.<br>
<br>
> * Is artificially increasing the number of outputs to mimic Coinjoins =
txn<br>
> acceptable wrt to utxo bloat/fees ?<br>
<br>
That is indeed an issue.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
</blockquote></div>
--0000000000009e66e0059f5684dc--
|