summaryrefslogtreecommitdiff
path: root/eb/fe4bcb980df29ef2f17f3f9b1c6d5e2c049594
blob: 2872b5f952ecdd7cda5ea81a2e78b8aa71d6dce7 (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
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
Return-Path: <antoine.riard@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 7560FC002B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 15 Feb 2023 03:33:39 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 49E0F80C2D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 15 Feb 2023 03:33:39 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 49E0F80C2D
Authentication-Results: smtp1.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=PlCog4j+
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id CrStRU5Qm9nH
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 15 Feb 2023 03:33:37 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 02C5480BB0
Received: from mail-il1-x131.google.com (mail-il1-x131.google.com
 [IPv6:2607:f8b0:4864:20::131])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 02C5480BB0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 15 Feb 2023 03:33:36 +0000 (UTC)
Received: by mail-il1-x131.google.com with SMTP id 18so1021788ilg.3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 14 Feb 2023 19:33:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=uF0V/tMJGQT1au+GPwcGZnaHZgrHFguvxE24QmB7v2U=;
 b=PlCog4j+6WChAB8ipLv1aPT0k7BSmT7nS/EFsCWvVIbMaAM420zrUGysu/7J3DFmkk
 CXd5v8sQbAZ32vuI/Pk9t3InxmAB/qxnSrQ9zqJ8KYivn2oKMLp7tm47Q3XrOlevipzr
 V5ooV0Nhe8FdGwRZZqNBDn9CYv4mf8ToSz8Lbke5SxZtxkvrJ09OeZq07C0q8pyZeEZh
 bka+hilN45k2u2025o1OqmGO1gQE7Gsr3U4kfmGdokNBtM1yGjsO84Yy4IlhDbgdRcQB
 F3nVWZ5P8niN9L+R2SOAg+k2oqX6VRubaOLVUo1j7PxBIbCF6gntpIod+CitoUM0tSJt
 uXiQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=uF0V/tMJGQT1au+GPwcGZnaHZgrHFguvxE24QmB7v2U=;
 b=QyCM8mTGFrxYgpwVTu8ykyiJ5F27gUC4RpIKvrEP0/kZ5qHgV0MSozf28Fykg6edvv
 UXJzj0OmtxL1kMxcs7HuCyoiC3CgeLKJp/1k9/ossgjCpPVytC4Xmd35P28N8Ob/lWtv
 zlzVaWltx2D56m/lWl9i53hDr8gnM9Y9PGeOU0HBnaIT2+chTajMauhZLTYcTXMZDipw
 te5YFumZvyyAwZy7KGlPeabC5ernD5M34xK1lVVyGmByOLydMvnnL4Cz6GiykNB/FKHd
 ZG+bQaIa9t7W6ymba5WQMRbVJ9nxwFo/FACwaBFO96Flfuk6hHSRwukZvuoDFpdJJ8o/
 ZvYg==
X-Gm-Message-State: AO0yUKVAzy4o1DyXanY90cXWNpWgZm3f8pzPR7J952sVfDsRu5OQYjDC
 VeE8Rhj2XKjm5rKPg+UfAYxju9eikwrj38wiIA/05Swjkfc=
X-Google-Smtp-Source: AK7set8AwSfgKeSc3Nn6epO0G62MTKX8KT+26bRsUO8EOq2owS822rW3ujVE5wOQxqRIJ0SrzLGATfFpxcMD6tq+xbE=
X-Received: by 2002:a92:4441:0:b0:313:f870:58fb with SMTP id
 a1-20020a924441000000b00313f87058fbmr288424ilm.2.1676432015856; Tue, 14 Feb
 2023 19:33:35 -0800 (PST)
MIME-Version: 1.0
References: <CAAQdECCH=YOcu4g6Ku1_G4CnRg6rsaFPFPwbABx9aZin9A8+2A@mail.gmail.com>
 <CALZpt+E2XKmqAELcedN8-5JkCOwmEH-CN8nwmpwW74xGUZPtbA@mail.gmail.com>
 <CAAQdECCDfmAmxvSWfTsiTz_0TecpA8zoryZzHT==mXDU0p-xoA@mail.gmail.com>
In-Reply-To: <CAAQdECCDfmAmxvSWfTsiTz_0TecpA8zoryZzHT==mXDU0p-xoA@mail.gmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Wed, 15 Feb 2023 03:33:24 +0000
Message-ID: <CALZpt+HYinkSWvy56ky4KJrmLGaN1OxBy+6MOX6VkRgQu-7Y6g@mail.gmail.com>
To: Yuval Kogman <nothingmuch@woobling.org>
Content-Type: multipart/alternative; boundary="000000000000cb9bc705f4b4bebf"
X-Mailman-Approved-At: Wed, 15 Feb 2023 08:49:53 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Unenforceable fee obligations in multiparty
 protocols with Taproot inputs
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: Wed, 15 Feb 2023 03:33:39 -0000

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

> Apologies for not citing, I think I must have seen that before but
> only remembered the pinning variants, and so did not recall it at the
> time that I wrote this up, which I did rather hastily.

> However, I do think the adversary model should be broadened, as there
> is a potential positive externality to a party which simply wishes to
> get some witness data confirmed in a block while paying less than the
> market rate, without needing to assume time sensitive contracts in the
> threat model.


Please no apologies - Message matters more than the messenger in

open-source. Yes, on the adversary model I would like to note there is a

potential negative externality in the context of time-sensitive contract,
e.g

for a DLC with short-term maturity you can delay confirmation of the fundin=
g

transaction in function of the event outcome progression (e.g a basketball
quarters),

and if the outcome turns in your defavor, you just double-spend a funding
input.


> What I had in mind was the estimated witness size messages in the dual
> funding proposal and felt they would create a false sense of
> validation, specifically in the context of an adversary interested in
> having their ordinal inscriptions being paid for by someone else by
> subverting the a priori agreed upon feerate. From my point of view
> this is primarily an argument for RBF by default (ideally full RBF, as
> rule 3 of BIP 125 imposes difficult constraints on multiparty
> transaction construction) in such protocols.


We could have miniscript embedded in the backend of a Lightning

implementation, to reject any malleable witness (maybe with some tolerance
bounds ?),

to restrain a counterparty downgrading a posteriori its feerate
contribution.

Full rbf effectively would prevent timevalue DoS inflicted to the
most-utxo-value

contributor in dual-funding, however in the present flow, I don't know if i=
t

changes something, the witness downgrading counterparty benefits from

a feerate discount, not lack of confirmation.


> Yes, that doesn't make things incentive compatible but allows the
> potential victims to have clearer bounds on the potential positive
> payoff to the adversary. I think that's mainly useful in conjunction
> constraining the order of signature submission, going from smallest to
> largest input seems intuitively compelling but it seems to me like
> ordering by feerate of creating transaction or perhaps some
> combination of the two might provide a stronger deterrent.


I think some combination of the two can makes sense, as if the feerate

is what you paid, the input value is your "economically subjective"
liquidity

risk, and as such you might pay a better signature submission place for

a feerate contribution increase. Quite sophisticated for the basic
dual-funding flow.


> Either way the main takeaway in my opinion is not that this is a
> serious attack, as it's hard to exploit in theory and as far as I know
> none of the currently deployed protocols are in any way vulnerable:

> 1. dual funding supports RBF and quite amenable to reputation based
mitigations
> 2. in JoinMarket the taker can protect themselves
> 3. centralized coinjoins, despite misleading claims to the contrary by
> both vendors, currently strongly rely on a trusted server for many
> other aspects of the protocol and all three protocols are not
> currently exploitable as described (the attacker can't broadcast the
> transaction with a witness that would otherwise be rejected by the
> server)

> ... but rather that (full) RBF is required for incentive compatible
> multiparty transactions (or the closest approximation of incentive
> compatibility possible barring future soft forks).


Yep yep, all types of DoS are less concerning than "loss of funds"

severity pinning attacks, and doesn't sounds to affect currently

deployed protocols. Still concerned all those DoS once accumulated

might be a "practical" show-stopper, like we have with channel jamming.



Le ven. 10 f=C3=A9vr. 2023 =C3=A0 19:35, Yuval Kogman <nothingmuch@woobling=
.org> a
=C3=A9crit :

> On Wed, 8 Feb 2023 at 02:56, Antoine Riard <antoine.riard@gmail.com>
> wrote:
> > From what I understand, there are many inputs for the coinjoin
> transaction, the latest signer provides an inflated witness downgrading t=
he
> multi-party transaction feerate.
>
> Yep!
>
> >  It doesn't sound to me a fee siphoning as occurring with loose
> malleability [0], rather another case of transaction-relay jamming where
> the adversary's goal is to slow down the confirmation of the transaction =
to
> waste everyone timevalue.
> >
> > I think the issue has already been mentioned to advocate updating Core'=
s
> mempool acceptance policy, and allows wtxid-replacement [1]. There is als=
o
> a description available here [2].
>
> Yep, the mechanism is basically the same as witness malleability based
> jamming.
>
> Apologies for not citing, I think I must have seen that before but
> only remembered the pinning variants, and so did not recall it at the
> time that I wrote this up, which I did rather hastily.
>
> However, I do think the adversary model should be broadened, as there
> is a potential positive externality to a party which simply wishes to
> get some witness data confirmed in a block while paying less than the
> market rate, without needing to assume time sensitive contracts in the
> threat model.
>
> What I had in mind was the estimated witness size messages in the dual
> funding proposal and felt they would create a false sense of
> validation, specifically in the context of an adversary interested in
> having their ordinal inscriptions being paid for by someone else by
> subverting the a priori agreed upon feerate. From my point of view
> this is primarily an argument for RBF by default (ideally full RBF, as
> rule 3 of BIP 125 imposes difficult constraints on multiparty
> transaction construction) in such protocols.
>
> > I don't think increasing adversary costliness is that efficient as ther=
e
> is a scaling effect (e.g the feerate of the previous transaction can be
> used to feed N outputs for N dissociated attack contexts).
>
> Yes, that doesn't make things incentive compatible but allows the
> potential victims to have clearer bounds on the potential positive
> payoff to the adversary. I think that's mainly useful in conjunction
> constraining the order of signature submission, going from smallest to
> largest input seems intuitively compelling but it seems to me like
> ordering by feerate of creating transaction or perhaps some
> combination of the two might provide a stronger deterrent.
>
> Either way the main takeaway in my opinion is not that this is a
> serious attack, as it's hard to exploit in theory and as far as I know
> none of the currently deployed protocols are in any way vulnerable:
>
> 1. dual funding supports RBF and quite amenable to reputation based
> mitigations
> 2. in JoinMarket the taker can protect themselves
> 3. centralized coinjoins, despite misleading claims to the contrary by
> both vendors, currently strongly rely on a trusted server for many
> other aspects of the protocol and all three protocols are not
> currently exploitable as described (the attacker can't broadcast the
> transaction with a witness that would otherwise be rejected by the
> server)
>
> ... but rather that (full) RBF is required for incentive compatible
> multiparty transactions (or the closest approximation of incentive
> compatibility possible barring future soft forks).
>

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

<div dir=3D"ltr"><p style=3D"margin:0px;font-stretch:normal;font-size:11px;=
line-height:normal;font-family:Menlo;color:rgb(0,0,0)"><span style=3D"color=
:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;font-size:small">&gt;=
 Apologies for not citing, I think I must have seen that before but</span><=
br style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif"><sp=
an style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;font=
-size:small">&gt; only remembered the pinning variants, and so did not reca=
ll it at the</span><br style=3D"color:rgb(34,34,34);font-family:Arial,Helve=
tica,sans-serif"><span style=3D"color:rgb(34,34,34);font-family:Arial,Helve=
tica,sans-serif;font-size:small">&gt; time that I wrote this up, which I di=
d rather hastily.</span><br style=3D"color:rgb(34,34,34);font-family:Arial,=
Helvetica,sans-serif"><br style=3D"color:rgb(34,34,34);font-family:Arial,He=
lvetica,sans-serif"><span style=3D"color:rgb(34,34,34);font-family:Arial,He=
lvetica,sans-serif;font-size:small">&gt; However, I do think the adversary =
model should be broadened, as there</span><br style=3D"color:rgb(34,34,34);=
font-family:Arial,Helvetica,sans-serif"><span style=3D"color:rgb(34,34,34);=
font-family:Arial,Helvetica,sans-serif;font-size:small">&gt; is a potential=
 positive externality to a party which simply wishes to</span><br style=3D"=
color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif"><span style=3D"=
color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;font-size:small"=
>&gt; get some witness data confirmed in a block while paying less than the=
</span><br style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-se=
rif"><span style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-se=
rif;font-size:small">&gt; market rate, without needing to assume time sensi=
tive contracts in the</span><br style=3D"color:rgb(34,34,34);font-family:Ar=
ial,Helvetica,sans-serif"><span style=3D"color:rgb(34,34,34);font-family:Ar=
ial,Helvetica,sans-serif;font-size:small">&gt; threat model.</span><br></p>=
<p style=3D"margin:0px;font-stretch:normal;font-size:11px;line-height:norma=
l;font-family:Menlo;color:rgb(0,0,0)"><span style=3D"color:rgb(34,34,34);fo=
nt-family:Arial,Helvetica,sans-serif;font-size:small"><br></span></p><p sty=
le=3D"margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font=
-family:Menlo;color:rgb(0,0,0)"><span style=3D"color:rgb(34,34,34);font-fam=
ily:Arial,Helvetica,sans-serif;font-size:small">Please no apologies - Messa=
ge matters more than the messenger in</span></p><p style=3D"margin:0px;font=
-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;color:r=
gb(0,0,0)"><span style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,s=
ans-serif;font-size:small">open-source. Yes,=C2=A0</span><span style=3D"col=
or:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;font-size:small">on=
 the adversary model I would like to note there is a</span></p><p style=3D"=
margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-famil=
y:Menlo;color:rgb(0,0,0)"><span style=3D"color:rgb(34,34,34);font-family:Ar=
ial,Helvetica,sans-serif;font-size:small">potential negative=C2=A0</span><s=
pan style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;fon=
t-size:small">externality in the context of time-sensitive contract, e.g</s=
pan></p><p style=3D"margin:0px;font-stretch:normal;font-size:11px;line-heig=
ht:normal;font-family:Menlo;color:rgb(0,0,0)"><span style=3D"color:rgb(34,3=
4,34);font-family:Arial,Helvetica,sans-serif;font-size:small">for a DLC wit=
h=C2=A0</span><span style=3D"color:rgb(34,34,34);font-family:Arial,Helvetic=
a,sans-serif;font-size:small">short-term maturity you can delay confirmatio=
n of the funding</span></p><p style=3D"margin:0px;font-stretch:normal;font-=
size:11px;line-height:normal;font-family:Menlo;color:rgb(0,0,0)"><span styl=
e=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;font-size:s=
mall">transaction=C2=A0</span><span style=3D"color:rgb(34,34,34);font-famil=
y:Arial,Helvetica,sans-serif;font-size:small">in function of the event outc=
ome progression (e.g a basketball quarters),</span></p><p style=3D"margin:0=
px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;=
color:rgb(0,0,0)"><span style=3D"color:rgb(34,34,34);font-family:Arial,Helv=
etica,sans-serif;font-size:small">and if the outcome turns in your defavor,=
 you just double-spend a funding input.</span></p><p style=3D"margin:0px;fo=
nt-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;color=
:rgb(0,0,0)"><span style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica=
,sans-serif;font-size:small"><br></span></p><p style=3D"margin:0px;font-str=
etch:normal;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(0=
,0,0)"><span style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-=
serif;font-size:small">&gt; What I had in mind was the estimated witness si=
ze messages in the dual</span><br style=3D"color:rgb(34,34,34);font-family:=
Arial,Helvetica,sans-serif"><span style=3D"color:rgb(34,34,34);font-family:=
Arial,Helvetica,sans-serif;font-size:small">&gt; funding proposal and felt =
they would create a false sense of</span><br style=3D"color:rgb(34,34,34);f=
ont-family:Arial,Helvetica,sans-serif"><span style=3D"color:rgb(34,34,34);f=
ont-family:Arial,Helvetica,sans-serif;font-size:small">&gt; validation, spe=
cifically in the context of an adversary interested in</span><br style=3D"c=
olor:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif"><span style=3D"c=
olor:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;font-size:small">=
&gt; having their ordinal inscriptions being paid for by someone else by</s=
pan><br style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif=
"><span style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif=
;font-size:small">&gt; subverting the a priori agreed upon feerate. From my=
 point of view</span><br style=3D"color:rgb(34,34,34);font-family:Arial,Hel=
vetica,sans-serif"><span style=3D"color:rgb(34,34,34);font-family:Arial,Hel=
vetica,sans-serif;font-size:small">&gt; this is primarily an argument for R=
BF by default (ideally full RBF, as</span><br style=3D"color:rgb(34,34,34);=
font-family:Arial,Helvetica,sans-serif"><span style=3D"color:rgb(34,34,34);=
font-family:Arial,Helvetica,sans-serif;font-size:small">&gt; rule 3 of BIP =
125 imposes difficult constraints on multiparty</span><br style=3D"color:rg=
b(34,34,34);font-family:Arial,Helvetica,sans-serif"><span style=3D"color:rg=
b(34,34,34);font-family:Arial,Helvetica,sans-serif;font-size:small">&gt; tr=
ansaction construction) in such protocols.</span><span style=3D"color:rgb(3=
4,34,34);font-family:Arial,Helvetica,sans-serif;font-size:small"><br></span=
></p><p style=3D"margin:0px;font-stretch:normal;font-size:11px;line-height:=
normal;font-family:Menlo;color:rgb(0,0,0)"><span style=3D"color:rgb(34,34,3=
4);font-family:Arial,Helvetica,sans-serif;font-size:small"><br></span></p><=
p style=3D"margin:0px;font-stretch:normal;font-size:11px;line-height:normal=
;font-family:Menlo;color:rgb(0,0,0)"><span style=3D"color:rgb(34,34,34);fon=
t-family:Arial,Helvetica,sans-serif;font-size:small">We could have miniscri=
pt embedded in the backend of a Lightning</span></p><p style=3D"margin:0px;=
font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;col=
or:rgb(0,0,0)"><span style=3D"color:rgb(34,34,34);font-family:Arial,Helveti=
ca,sans-serif;font-size:small">implementation, to reject any malleable witn=
ess (maybe with some tolerance bounds ?),</span></p><p style=3D"margin:0px;=
font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;col=
or:rgb(0,0,0)"><span style=3D"color:rgb(34,34,34);font-family:Arial,Helveti=
ca,sans-serif;font-size:small">to restrain a counterparty downgrading a pos=
teriori its feerate contribution.</span></p><p style=3D"margin:0px;font-str=
etch:normal;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(0=
,0,0)"><span style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-=
serif;font-size:small">Full rbf effectively would prevent timevalue DoS inf=
licted to the most-utxo-value</span></p><p style=3D"margin:0px;font-stretch=
:normal;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(0,0,0=
)"><span style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-seri=
f;font-size:small">contributor in dual-funding, however in the present flow=
, I don&#39;t know if it</span></p><p style=3D"margin:0px;font-stretch:norm=
al;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(0,0,0)"><s=
pan style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;fon=
t-size:small">changes something, the witness downgrading counterparty benef=
its from</span></p><p style=3D"margin:0px;font-stretch:normal;font-size:11p=
x;line-height:normal;font-family:Menlo;color:rgb(0,0,0)"><span style=3D"col=
or:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;font-size:small">a =
feerate discount, not lack of confirmation.</span></p><p style=3D"margin:0p=
x;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;c=
olor:rgb(0,0,0)"><span style=3D"color:rgb(34,34,34);font-family:Arial,Helve=
tica,sans-serif;font-size:small"><br></span></p><p style=3D"margin:0px;font=
-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;color:r=
gb(0,0,0)"><span style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,s=
ans-serif;font-size:small">&gt; Yes, that doesn&#39;t make things incentive=
 compatible but allows the</span><br style=3D"color:rgb(34,34,34);font-fami=
ly:Arial,Helvetica,sans-serif"><span style=3D"color:rgb(34,34,34);font-fami=
ly:Arial,Helvetica,sans-serif;font-size:small">&gt; potential victims to ha=
ve clearer bounds on the potential positive</span><br style=3D"color:rgb(34=
,34,34);font-family:Arial,Helvetica,sans-serif"><span style=3D"color:rgb(34=
,34,34);font-family:Arial,Helvetica,sans-serif;font-size:small">&gt; payoff=
 to the adversary. I think that&#39;s mainly useful in conjunction</span><b=
r style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif"><spa=
n style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;font-=
size:small">&gt; constraining the order of signature submission, going from=
 smallest to</span><br style=3D"color:rgb(34,34,34);font-family:Arial,Helve=
tica,sans-serif"><span style=3D"color:rgb(34,34,34);font-family:Arial,Helve=
tica,sans-serif;font-size:small">&gt; largest input seems intuitively compe=
lling but it seems to me like</span><br style=3D"color:rgb(34,34,34);font-f=
amily:Arial,Helvetica,sans-serif"><span style=3D"color:rgb(34,34,34);font-f=
amily:Arial,Helvetica,sans-serif;font-size:small">&gt; ordering by feerate =
of creating transaction or perhaps some</span><br style=3D"color:rgb(34,34,=
34);font-family:Arial,Helvetica,sans-serif"><span style=3D"color:rgb(34,34,=
34);font-family:Arial,Helvetica,sans-serif;font-size:small">&gt; combinatio=
n of the two might provide a stronger deterrent.</span><span style=3D"color=
:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;font-size:small"><br>=
</span></p><p style=3D"margin:0px;font-stretch:normal;font-size:11px;line-h=
eight:normal;font-family:Menlo;color:rgb(0,0,0)"><span style=3D"color:rgb(3=
4,34,34);font-family:Arial,Helvetica,sans-serif;font-size:small"><br></span=
></p><p style=3D"margin:0px;font-stretch:normal;font-size:11px;line-height:=
normal;font-family:Menlo;color:rgb(0,0,0)"><span style=3D"color:rgb(34,34,3=
4);font-family:Arial,Helvetica,sans-serif;font-size:small">I think some com=
bination of the two can makes sense, as if the feerate</span></p><p style=
=3D"margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-f=
amily:Menlo;color:rgb(0,0,0)"><span style=3D"color:rgb(34,34,34);font-famil=
y:Arial,Helvetica,sans-serif;font-size:small">is what you paid, the input v=
alue is your &quot;economically subjective&quot; liquidity</span></p><p sty=
le=3D"margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font=
-family:Menlo;color:rgb(0,0,0)"><span style=3D"color:rgb(34,34,34);font-fam=
ily:Arial,Helvetica,sans-serif;font-size:small">risk, and as such you might=
 pay a better signature submission place for</span></p><p style=3D"margin:0=
px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;=
color:rgb(0,0,0)"><span style=3D"color:rgb(34,34,34);font-family:Arial,Helv=
etica,sans-serif;font-size:small">a feerate contribution increase. Quite so=
phisticated for the basic dual-funding flow.</span></p><p style=3D"margin:0=
px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;=
color:rgb(0,0,0)"><span style=3D"color:rgb(34,34,34);font-family:Arial,Helv=
etica,sans-serif;font-size:small"><br></span></p><p style=3D"margin:0px;fon=
t-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;color:=
rgb(0,0,0)"><span style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,=
sans-serif;font-size:small">&gt; Either way the main takeaway in my opinion=
 is not that this is a</span><br style=3D"color:rgb(34,34,34);font-family:A=
rial,Helvetica,sans-serif"><span style=3D"color:rgb(34,34,34);font-family:A=
rial,Helvetica,sans-serif;font-size:small">&gt; serious attack, as it&#39;s=
 hard to exploit in theory and as far as I know</span><br style=3D"color:rg=
b(34,34,34);font-family:Arial,Helvetica,sans-serif"><span style=3D"color:rg=
b(34,34,34);font-family:Arial,Helvetica,sans-serif;font-size:small">&gt; no=
ne of the currently deployed protocols are in any way vulnerable:</span><br=
 style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif"><br s=
tyle=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif"><span s=
tyle=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;font-siz=
e:small">&gt; 1. dual funding supports RBF and quite amenable to reputation=
 based mitigations</span><br style=3D"color:rgb(34,34,34);font-family:Arial=
,Helvetica,sans-serif"><span style=3D"color:rgb(34,34,34);font-family:Arial=
,Helvetica,sans-serif;font-size:small">&gt; 2. in JoinMarket the taker can =
protect themselves</span><br style=3D"color:rgb(34,34,34);font-family:Arial=
,Helvetica,sans-serif"><span style=3D"color:rgb(34,34,34);font-family:Arial=
,Helvetica,sans-serif;font-size:small">&gt; 3. centralized coinjoins, despi=
te misleading claims to the contrary by</span><br style=3D"color:rgb(34,34,=
34);font-family:Arial,Helvetica,sans-serif"><span style=3D"color:rgb(34,34,=
34);font-family:Arial,Helvetica,sans-serif;font-size:small">&gt; both vendo=
rs, currently strongly rely on a trusted server for many</span><br style=3D=
"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif"><span style=3D=
"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;font-size:small=
">&gt; other aspects of the protocol and all three protocols are not</span>=
<br style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif"><s=
pan style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;fon=
t-size:small">&gt; currently exploitable as described (the attacker can&#39=
;t broadcast the</span><br style=3D"color:rgb(34,34,34);font-family:Arial,H=
elvetica,sans-serif"><span style=3D"color:rgb(34,34,34);font-family:Arial,H=
elvetica,sans-serif;font-size:small">&gt; transaction with a witness that w=
ould otherwise be rejected by the</span><br style=3D"color:rgb(34,34,34);fo=
nt-family:Arial,Helvetica,sans-serif"><span style=3D"color:rgb(34,34,34);fo=
nt-family:Arial,Helvetica,sans-serif;font-size:small">&gt; server)</span><b=
r style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif"><br =
style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif"><span =
style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;font-si=
ze:small">&gt; ... but rather that (full) RBF is required for incentive com=
patible</span><br style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,=
sans-serif"><span style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,=
sans-serif;font-size:small">&gt; multiparty transactions (or the closest ap=
proximation of incentive</span><br style=3D"color:rgb(34,34,34);font-family=
:Arial,Helvetica,sans-serif"><span style=3D"color:rgb(34,34,34);font-family=
:Arial,Helvetica,sans-serif;font-size:small">&gt; compatibility possible ba=
rring future soft forks).</span><span style=3D"color:rgb(34,34,34);font-fam=
ily:Arial,Helvetica,sans-serif;font-size:small"><br></span></p><p style=3D"=
margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-famil=
y:Menlo;color:rgb(0,0,0)"><span style=3D"color:rgb(34,34,34);font-family:Ar=
ial,Helvetica,sans-serif;font-size:small"><br></span></p><p style=3D"margin=
:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menl=
o;color:rgb(0,0,0)"><span style=3D"color:rgb(34,34,34);font-family:Arial,He=
lvetica,sans-serif;font-size:small">Yep yep, all types of DoS are less conc=
erning than &quot;loss of funds&quot;</span></p><p style=3D"margin:0px;font=
-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;color:r=
gb(0,0,0)"><span style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,s=
ans-serif;font-size:small">severity pinning attacks, and doesn&#39;t sounds=
 to affect currently</span></p><p style=3D"margin:0px;font-stretch:normal;f=
ont-size:11px;line-height:normal;font-family:Menlo;color:rgb(0,0,0)"><span =
style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;font-si=
ze:small">deployed protocols. Still concerned all those DoS once accumulate=
d</span></p><p style=3D"margin:0px;font-stretch:normal;font-size:11px;line-=
height:normal;font-family:Menlo;color:rgb(0,0,0)"><span style=3D"color:rgb(=
34,34,34);font-family:Arial,Helvetica,sans-serif;font-size:small">might be =
a &quot;practical&quot; show-stopper, like we have with channel jamming.</s=
pan><span style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-ser=
if;font-size:small">=C2=A0 =C2=A0</span></p><p style=3D"margin:0px;font-str=
etch:normal;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(0=
,0,0)"><span style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-=
serif;font-size:small"><br></span></p></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0ven. 10 f=C3=A9vr. 2023 =C3=
=A0=C2=A019:35, Yuval Kogman &lt;<a href=3D"mailto:nothingmuch@woobling.org=
">nothingmuch@woobling.org</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:=
1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left=
:1ex">On Wed, 8 Feb 2023 at 02:56, Antoine Riard &lt;<a href=3D"mailto:anto=
ine.riard@gmail.com" target=3D"_blank">antoine.riard@gmail.com</a>&gt; wrot=
e:<br>
&gt; From what I understand, there are many inputs for the coinjoin transac=
tion, the latest signer provides an inflated witness downgrading the multi-=
party transaction feerate.<br>
<br>
Yep!<br>
<br>
&gt;=C2=A0 It doesn&#39;t sound to me a fee siphoning as occurring with loo=
se malleability [0], rather another case of transaction-relay jamming where=
 the adversary&#39;s goal is to slow down the confirmation of the transacti=
on to waste everyone timevalue.<br>
&gt;<br>
&gt; I think the issue has already been mentioned to advocate updating Core=
&#39;s mempool acceptance policy, and allows wtxid-replacement [1]. There i=
s also a description available here [2].<br>
<br>
Yep, the mechanism is basically the same as witness malleability based jamm=
ing.<br>
<br>
Apologies for not citing, I think I must have seen that before but<br>
only remembered the pinning variants, and so did not recall it at the<br>
time that I wrote this up, which I did rather hastily.<br>
<br>
However, I do think the adversary model should be broadened, as there<br>
is a potential positive externality to a party which simply wishes to<br>
get some witness data confirmed in a block while paying less than the<br>
market rate, without needing to assume time sensitive contracts in the<br>
threat model.<br>
<br>
What I had in mind was the estimated witness size messages in the dual<br>
funding proposal and felt they would create a false sense of<br>
validation, specifically in the context of an adversary interested in<br>
having their ordinal inscriptions being paid for by someone else by<br>
subverting the a priori agreed upon feerate. From my point of view<br>
this is primarily an argument for RBF by default (ideally full RBF, as<br>
rule 3 of BIP 125 imposes difficult constraints on multiparty<br>
transaction construction) in such protocols.<br>
<br>
&gt; I don&#39;t think increasing adversary costliness is that efficient as=
 there is a scaling effect (e.g the feerate of the previous transaction can=
 be used to feed N outputs for N dissociated attack contexts).<br>
<br>
Yes, that doesn&#39;t make things incentive compatible but allows the<br>
potential victims to have clearer bounds on the potential positive<br>
payoff to the adversary. I think that&#39;s mainly useful in conjunction<br=
>
constraining the order of signature submission, going from smallest to<br>
largest input seems intuitively compelling but it seems to me like<br>
ordering by feerate of creating transaction or perhaps some<br>
combination of the two might provide a stronger deterrent.<br>
<br>
Either way the main takeaway in my opinion is not that this is a<br>
serious attack, as it&#39;s hard to exploit in theory and as far as I know<=
br>
none of the currently deployed protocols are in any way vulnerable:<br>
<br>
1. dual funding supports RBF and quite amenable to reputation based mitigat=
ions<br>
2. in JoinMarket the taker can protect themselves<br>
3. centralized coinjoins, despite misleading claims to the contrary by<br>
both vendors, currently strongly rely on a trusted server for many<br>
other aspects of the protocol and all three protocols are not<br>
currently exploitable as described (the attacker can&#39;t broadcast the<br=
>
transaction with a witness that would otherwise be rejected by the<br>
server)<br>
<br>
... but rather that (full) RBF is required for incentive compatible<br>
multiparty transactions (or the closest approximation of incentive<br>
compatibility possible barring future soft forks).<br>
</blockquote></div>

--000000000000cb9bc705f4b4bebf--