summaryrefslogtreecommitdiff
path: root/de/1d7cb9aa3978734be423c5cf0ce74f8b2d91e2
blob: d6e854ccf35959e17ac8dcdda21c6b75a83690b2 (plain)
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
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
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 2CAC6C0177
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 25 Feb 2020 19:16:20 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by silver.osuosl.org (Postfix) with ESMTP id 19866203F8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 25 Feb 2020 19:16:20 +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 MdXOzXa1NYgM
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 25 Feb 2020 19:16:18 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-pf1-f193.google.com (mail-pf1-f193.google.com
 [209.85.210.193])
 by silver.osuosl.org (Postfix) with ESMTPS id F1388203A0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 25 Feb 2020 19:16:17 +0000 (UTC)
Received: by mail-pf1-f193.google.com with SMTP id 2so30535pfg.12
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 25 Feb 2020 11:16:17 -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=qNvHBAT58c66CaeGs4fnNTWeDME7/hb8LIuGsXwFpwQ=;
 b=Ncza+vcba0aUOuX1McXYlkkxMslQ0Jx+AVDPfWqdYcl+cPJv59Qiha2pk+1HlHekWW
 l0wHcj/n0w+DogE0yd6i+GN1P8ksqY+Uzv5jopBj46D8ZIOQpvBXJJKpkAfhXX+UikpW
 vG2Z/gaAnetChaCZ9ll9KwEq+pvciasGTI8Y08BLscvc6dIb49WDQfnVSD2uPu0nYDAP
 mwxs+jRuBq+n498y9camjFApsQXg9srtOhLZDlAyT/GEuxjOIbWsd/C91th8SXuhbfSf
 fkw1IQy1PVIKeaqM/qlLeYd3zJ7FvQBQSedShUSlpcRSQ6pEm4doy9zBqEqhDzC8kMd6
 J2oA==
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=qNvHBAT58c66CaeGs4fnNTWeDME7/hb8LIuGsXwFpwQ=;
 b=KxQWrqgrwAzNra7pXO/DFdYBnFwOeNRPSn2VeDjipSk0jgH5gHIAI0xR+NSqC1NEZT
 lGbjkBftIIxvbcVXabCPy4Jm8phbENggZgwA7BQPsNaEj6V489MT8Owu+00t+W6dDYr5
 8I/GICgydhBBjfKXwf7Rnj5RNNstvptMqc0mATtxmGchFhf2mnwAK0OGAtfyAtZK48hm
 YBjtEJv0c1to1OjeS2WicrHdZYwaWBWB2O63fjxFveYkD7QRWJxH4V6hiA3Br/6PYZBi
 PZeCSZvmSgv3Vw95/nWVLs06ARM7Hmz98zgcNobHgVie1yV3KumeQ0ca24S7Jsef5bOU
 6LQA==
X-Gm-Message-State: APjAAAVOtrGVpbA1tAWgLlkhsCfKsplIfrSbDyXZrDydkiSxE9Frg6nl
 Utr7NtayVS+cqyt63Y0w9Y3ML7bUMP1em5dyayY=
X-Google-Smtp-Source: APXvYqzIxjxpMscLjoYYk7FSH3n2Or2ltodF995A7la8u4utYeW6iMDbEPuJY3fVv5kOKbyDwBFZD0pBk5jBAhz8VD8=
X-Received: by 2002:a62:e111:: with SMTP id q17mr205190pfh.242.1582658177264; 
 Tue, 25 Feb 2020 11:16:17 -0800 (PST)
MIME-Version: 1.0
References: <CALZpt+E4Mr=g8zw95tyteGh53DH1mZ2HhNzQdy92+ErTtx3VbQ@mail.gmail.com>
 <wUeoSi98_WNKqyiqI0yZ7YKCjsWqBO4lprQkQXbO_VkrALVxaYWsMRvbgnsHMWXA7QsB2gp9N2-a-gLuxY74xQMXwdyYKsKyLbNe1OSUVoQ=@protonmail.com>
 <CALZpt+H6g4ak_kzbNr-QwTd04YwqBqkmHL4ZYPxqxQLgtv9W6Q@mail.gmail.com>
 <2-MilNWxNU5sCVK81AtIN7LhLButGQNbxgkr50rzsCvd5FqrD3VHBKCWjlxeFXYbKzC1XX5jm8NpzQUR95TGyupYqL6ggL8rPObGYC0AYWE=@protonmail.com>
In-Reply-To: <2-MilNWxNU5sCVK81AtIN7LhLButGQNbxgkr50rzsCvd5FqrD3VHBKCWjlxeFXYbKzC1XX5jm8NpzQUR95TGyupYqL6ggL8rPObGYC0AYWE=@protonmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Tue, 25 Feb 2020 14:16:03 -0500
Message-ID: <CALZpt+Fm1TxkVUL=L7vApzOY9TZ+LLcgmyHtwGk84ovhHxUeqg@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="00000000000074eda5059f6b5274"
X-Mailman-Approved-At: Tue, 25 Feb 2020 19:23:12 +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: Tue, 25 Feb 2020 19:16:20 -0000

--00000000000074eda5059f6b5274
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Morning Zeeman,

> I proposed before to consider splicing as a form of merged closing plus
funding, rather than a modification of channel state; in particular we
might note that, for compatibility with our existing system, a spliced
channel would have to change its short channel ID > and channel ID, so it
is arguably a different channel already.

Yes but you may want alias to keep your channel routing-score across
splicing, though how to do this is more LN-dev specific.

> Emulating LN splices mildly makes ConJoinXT less desirable, however, as
the mix takes longer and is more costly.

Intuitively, a lot of Coinjoin traffic may be redirected in the future
through LN when protocol matures, privacy properties may be better (though
need careful analysis).
Coinjoins would be only for high-amounts for which security/liquidity isn't
offered by LN, and in this case time for increasing privacy is IMO an
acceptable tradeoff.

> Does not Electrum do RBF by default?

Dunno, for more context on RBF and its controversies see
https://bitcoincore.org/en/faq/optin_rbf/ (or Optech resources)

> 1.5RTT with MuSig

Yes right I meaned you don't need to assume latter interactivity if it's a
multi-party tx construction you sign multiple RBF versions at same time.
Still need to think about privacy-preserving fee bumping wrt to mempool
observer

> This can be mitigated if all participants contribute equal or
nearly-equally to the fees, though that complicates single-funding, and may
violate Initiator Pays Principle (the initiator of an action should pay all
fees related to the action, as otherwise it may be  possible to create a
null operation that the acceptor of the action ends up paying fees for,
which can be used as a financial attack to drain acceptors).

Yes, but also you want the acceptor to pay for its inputs announced to
avoid pouring the spending burden on the initiator only, or doing any
free-ride aggregation .

> There may be other protocols interested in this as well --- for instance
"submarine swaps" and "lightning loops", which are the same thing.

Yes good point, specially batched submarine swaps are good candidates, also
DLCs (will enquiry on tx pattern of more bitcoin protocol)


Le lun. 24 f=C3=A9vr. 2020 =C3=A0 18:36, ZmnSCPxj <ZmnSCPxj@protonmail.com>=
 a =C3=A9crit :

> Good morning Antoine,
>
>
> > > 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.
>
> Ah, that is indeed of great interest.
> I proposed before to consider splicing as a form of merged closing plus
> funding, rather than a modification of channel state; in particular we
> might note that, for compatibility with our existing system, a spliced
> channel would have to change its short channel ID and channel ID, so it i=
s
> arguably a different channel already.
>
> >
> > > 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.
>
> Yes; I am curious how JoinMarket reconciles how makers mix their coins vs=
.
> how takers do; presumably the tumbler.py emulates the behavior of a maker
> somehow.
>
> > Splicing may help there because a LN node would do multiple chain write=
s
> during channel lifecycle for liquidity reasons but it's
> > near-impossible to predict its frequency without deployment.
>
> Long ago, I proposed an alternative to splicing, which would today be
> recognizable as a "submarine swap" or "lightning loop".
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2017-May/000692=
.html
> Perhaps the frequencies of those operations may hint as to how much
> splicing would occur in practice in the future.
>
> > 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.
>
> Well, one way to implement splice-in would be to have an output that is
> first dedicated to the splice-in, and *then* a separate transaction which
> actually does the splice-in.
> This has a drawback of requiring an extra transaction, which wins us the
> facility to continue operation of the channel even while the splice-in
> transactions are being confirmed while retaining only one state.
> (the latest proposal, I believe, does *not* use this construction, and
> instead requires both sides to maintain two sets of states, with one stat=
e
> being a fallback in case the splice-in gets double spent; but in times of
> high blockchain load this can lead to the channel having a two sets of
> states until blockchain load reduces.)
>
> As it happens, my alternate proposal for CoinJoinXT is similar in that
> there are "entry transactions" that introduce coins into the PTG, which a=
re
> needed to prevent participants from double-spending while the mix is
> on-going. https://zmnscpxj.github.io/bitcoin/coinjoinxt.html
> Note the proposal differs from the original by waxwing, which requires
> backouts at each intermediate output, and the entry transactions are
> potential watermarks on the CoinJoinXT protocol as well.
> A Chaumian CoinJoinXT cannot use backouts at each intermediate output
> since no participant should have any knowledge of how much each participa=
nt
> has contributed to each intermediate output, they only know they put so
> many funds in and so should get so many funds out.
>
> Emulating LN splices mildly makes ConJoinXT less desirable, however, as
> the mix takes longer and is more costly.
>
> >
> > > 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 t=
he
> 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 t=
o
> 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...
>
> Grumble grumble, all unconfirmed transaction are RBF because miners like
> money, grumble grumble, flagged RBF is just a node relay policy, grumble
> grumble, some humans sometimes, grumble grumble....
>
> Does not Electrum do RBF by default?
> Unless I have a lower-level agent that always enables RBF option when I
> install new Electrums, hmmm, maybe I should check first.
>
> > Also see footnote on spurious-RBF about not-having facility to bump fee=
s
> higher (you can sign multiple RBF transactions in 1-RTT and agree to
> broadcast them later to obfuscate mempool analysis).
>
> 1.5RTT with MuSig.
>
> An issue here is that if not all participants contribute to the fees
> equally, then a participant who is paying lower fee or no fee has a mild
> incentive to just broadcast the highest-fee version and be done with it:
> forget the other transactions and just aim for the highest fee immediatel=
y,
> ignore the mempool state so you do not have to do all those calculations =
or
> even maintain a mempool, and so on.
> This can be mitigated if all participants contribute equal or
> nearly-equally to the fees, though that complicates single-funding, and m=
ay
> violate Initiator Pays Principle (the initiator of an action should pay a=
ll
> fees related to the action, as otherwise it may be possible to create a
> null operation that the acceptor of the action ends up paying fees for,
> which can be used as a financial attack to drain acceptors).
>
>
> > > 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.
>
> There may be other protocols interested in this as well --- for instance
> "submarine swaps" and "lightning loops", which are the same thing.
>
> Regards,
> ZmnSCPxj
>
>

--00000000000074eda5059f6b5274
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div>Morning Zeeman,<br><br>&gt; I proposed befo=
re to consider splicing as a form of merged closing plus=20
funding, rather than a modification of channel state; in particular we=20
might note that, for compatibility with our existing system, a spliced=20
channel would have to change its short channel ID &gt; and channel ID, so i=
t=20
is arguably a different channel already.<span class=3D"gmail-im"><br></span=
><br></div>Yes but you may want alias to keep your channel routing-score ac=
ross splicing, though how to do this is more LN-dev specific.<br><br>&gt; E=
mulating LN splices mildly makes ConJoinXT less desirable, however, as the =
mix takes longer and is more costly.<br><br></div>Intuitively, a lot of Coi=
njoin traffic may be redirected in the future through LN when protocol matu=
res, privacy properties may be better (though need careful analysis).<br></=
div><div>Coinjoins would be only for high-amounts for which security/liquid=
ity isn&#39;t offered by LN, and in this case time for increasing privacy i=
s IMO an acceptable tradeoff.<br><br>&gt; Does not Electrum do RBF by defau=
lt?<br><br></div><div>Dunno, for more context on RBF and its controversies =
see <a href=3D"https://bitcoincore.org/en/faq/optin_rbf/">https://bitcoinco=
re.org/en/faq/optin_rbf/</a> (or Optech resources)</div><div><br>&gt; 1.5RT=
T with MuSig<br><br></div><div>Yes right I meaned you don&#39;t need to ass=
ume latter interactivity if it&#39;s a multi-party tx construction you sign=
 multiple RBF versions at same time. Still need to think about privacy-pres=
erving fee bumping wrt to mempool observer<br><br>&gt; This can be mitigate=
d if all participants contribute equal or=20
nearly-equally to the fees, though that complicates single-funding, and=20
may violate Initiator Pays Principle (the initiator of an action should=20
pay all fees related to the action, as otherwise it may be=C2=A0 possible t=
o=20
create a null operation that the acceptor of the action ends up paying=20
fees for, which can be used as a financial attack to drain acceptors).<span=
 class=3D"gmail-im"><br><br></span></div><div><span class=3D"gmail-im">Yes,=
 but also you want the acceptor to pay for its inputs announced to avoid po=
uring the spending burden on the initiator only, or doing any free-ride agg=
regation .<br></span></div><div><span class=3D"gmail-im"><br>&gt; There may=
 be other protocols interested in this as well --- for instance
 &quot;submarine swaps&quot; and &quot;lightning loops&quot;, which are the=
 same thing.<br><br></span></div><div><span class=3D"gmail-im">Yes good poi=
nt, specially batched submarine swaps are good candidates, also DLCs (will =
enquiry on tx pattern of more bitcoin protocol)<br></span></div><div><span =
class=3D"gmail-im"><br>
</span></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D=
"gmail_attr">Le=C2=A0lun. 24 f=C3=A9vr. 2020 =C3=A0=C2=A018:36, ZmnSCPxj &l=
t;<a href=3D"mailto:ZmnSCPxj@protonmail.com">ZmnSCPxj@protonmail.com</a>&gt=
; a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex">Good morning Antoine,<br>
<br>
<br>
&gt; &gt; On mutual closes, we should probably set `nLockTime` to the curre=
nt blockheight + 1 as well.<br>
&gt; &gt; This has greater benefit later in a Taproot world.<br>
&gt;<br>
&gt; I assume mutual closes would fall under the aforementioned tx construc=
tion proposal, so a closing may be a batch to fund other channels or<br>
&gt; splice existent ones.<br>
<br>
Ah, that is indeed of great interest.<br>
I proposed before to consider splicing as a form of merged closing plus fun=
ding, rather than a modification of channel state; in particular we might n=
ote that, for compatibility with our existing system, a spliced channel wou=
ld have to change its short channel ID and channel ID, so it is arguably a =
different channel already.<br>
<br>
&gt;<br>
&gt; &gt; A kind of non-equal-value CoinJoin could emulate a Lightning open=
 + close, but most Lightning channels will have a large number of blocks (t=
housands or tens of thousands) between the open and the close; it seems unl=
ikely that a short-term channel will exist &gt; that matches the non-equal-=
value CoinJoin.<br>
&gt;<br>
&gt; That&#39;s a really acute point, utxo age and spending frequency may b=
e obvious protocol leaks.<br>
<br>
Yes; I am curious how JoinMarket reconciles how makers mix their coins vs. =
how takers do; presumably the tumbler.py emulates the behavior of a maker s=
omehow.<br>
<br>
&gt; Splicing may help there because a LN node would do multiple chain writ=
es during channel lifecycle for liquidity reasons but it&#39;s<br>
&gt; near-impossible to predict its frequency without deployment.<br>
<br>
Long ago, I proposed an alternative to splicing, which would today be recog=
nizable as a &quot;submarine swap&quot; or &quot;lightning loop&quot;. <a h=
ref=3D"https://lists.linuxfoundation.org/pipermail/lightning-dev/2017-May/0=
00692.html" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundat=
ion.org/pipermail/lightning-dev/2017-May/000692.html</a><br>
Perhaps the frequencies of those operations may hint as to how much splicin=
g would occur in practice in the future.<br>
<br>
&gt; Even with this, I do fear an analysis gap between Coinjoin spending de=
lta and LN ones. A way to circumvent this would be for CoinjoinXT to timelo=
ck its PTG<br>
&gt; transactions to mimick actively-spliced LN channels. That&#39;s where =
adoption of a common format by other onchain transactions than LN ones woul=
d help a lot.<br>
<br>
Well, one way to implement splice-in would be to have an output that is fir=
st dedicated to the splice-in, and *then* a separate transaction which actu=
ally does the splice-in.<br>
This has a drawback of requiring an extra transaction, which wins us the fa=
cility to continue operation of the channel even while the splice-in transa=
ctions are being confirmed while retaining only one state.<br>
(the latest proposal, I believe, does *not* use this construction, and inst=
ead requires both sides to maintain two sets of states, with one state bein=
g a fallback in case the splice-in gets double spent; but in times of high =
blockchain load this can lead to the channel having a two sets of states un=
til blockchain load reduces.)<br>
<br>
As it happens, my alternate proposal for CoinJoinXT is similar in that ther=
e are &quot;entry transactions&quot; that introduce coins into the PTG, whi=
ch are needed to prevent participants from double-spending while the mix is=
 on-going. <a href=3D"https://zmnscpxj.github.io/bitcoin/coinjoinxt.html" r=
el=3D"noreferrer" target=3D"_blank">https://zmnscpxj.github.io/bitcoin/coin=
joinxt.html</a><br>
Note the proposal differs from the original by waxwing, which requires back=
outs at each intermediate output, and the entry transactions are potential =
watermarks on the CoinJoinXT protocol as well.<br>
A Chaumian CoinJoinXT cannot use backouts at each intermediate output since=
 no participant should have any knowledge of how much each participant has =
contributed to each intermediate output, they only know they put so many fu=
nds in and so should get so many funds out.<br>
<br>
Emulating LN splices mildly makes ConJoinXT less desirable, however, as the=
 mix takes longer and is more costly.<br>
<br>
&gt;<br>
&gt; &gt; Should always be on, even if we do not (yet) have a facility to r=
e-interact to bump fees higher.<br>
&gt; &gt; While it is true that a surveillor can determine that a transacti=
on 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 &gt; information is not per=
manently recorded on all fullnodes and at least we force surveillors to rec=
ord this information themselves.<br>
&gt;<br>
&gt; Yes but if you do this for Core and given some merchants are refusing =
RBF transactions for onchain payments, people are going to complain...<br>
<br>
Grumble grumble, all unconfirmed transaction are RBF because miners like mo=
ney, grumble grumble, flagged RBF is just a node relay policy, grumble grum=
ble, some humans sometimes, grumble grumble....<br>
<br>
Does not Electrum do RBF by default?<br>
Unless I have a lower-level agent that always enables RBF option when I ins=
tall new Electrums, hmmm, maybe I should check first.<br>
<br>
&gt; Also see footnote on spurious-RBF about not-having facility to bump fe=
es higher (you can sign multiple RBF transactions in 1-RTT and agree to bro=
adcast them later to obfuscate mempool analysis).<br>
<br>
1.5RTT with MuSig.<br>
<br>
An issue here is that if not all participants contribute to the fees equall=
y, then a participant who is paying lower fee or no fee has a mild incentiv=
e to just broadcast the highest-fee version and be done with it: forget the=
 other transactions and just aim for the highest fee immediately, ignore th=
e mempool state so you do not have to do all those calculations or even mai=
ntain a mempool, and so on.<br>
This can be mitigated if all participants contribute equal or nearly-equall=
y to the fees, though that complicates single-funding, and may violate Init=
iator Pays Principle (the initiator of an action should pay all fees relate=
d to the action, as otherwise it may be possible to create a null operation=
 that the acceptor of the action ends up paying fees for, which can be used=
 as a financial attack to drain acceptors).<br>
<br>
<br>
&gt; &gt; However, it seems to me that we need to as well nail down the det=
ails of this format.<br>
&gt;<br>
&gt; Of course, just curious of people opinions right now but if it&#39;s a=
 good way to solve the described problem, will draft a spec.<br>
<br>
There may be other protocols interested in this as well --- for instance &q=
uot;submarine swaps&quot; and &quot;lightning loops&quot;, which are the sa=
me thing.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
<br>
</blockquote></div>

--00000000000074eda5059f6b5274--