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
|
Return-Path: <fresheneesz@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 07C7FC000B
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 15 Feb 2022 17:10:19 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id DD93180C13
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 15 Feb 2022 17:10:18 +0000 (UTC)
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
Authentication-Results: smtp1.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=gmail.com
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 Rgz5Iw58MTr4
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 15 Feb 2022 17:10:17 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com
[IPv6:2a00:1450:4864:20::630])
by smtp1.osuosl.org (Postfix) with ESMTPS id E264580C01
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 15 Feb 2022 17:10:16 +0000 (UTC)
Received: by mail-ej1-x630.google.com with SMTP id h8so19139096ejy.4
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 15 Feb 2022 09:10:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=2SKHncSTr4jTYQFDuBhaotBxw/4PYFrmKNBVyDQtXhA=;
b=EcKR0cm6jKq30wJ/7obnWyNayJxRTySu9AkwGiJX8yQxJGP60PD8eBn0VIHdoJWpvb
fsDtP4ORwUiH7h+25bpeT9oAY25YMzEqS+dP+/lEdcRFH/+DjLVfW+xEyssFomJ89wVs
bLcwPT3k5AS4Ingf8rE9X+JhhxxguBNgJHapO/fEjV8miDrW/xjOO0ny+1vN+YzNcMVo
9ZPQGwx9EgGj1K8JHc9hD3xUY1Krs0EP0jGXsrJvy2bG4M56OAFe/3XL+xDeN+B3EfzH
VThoEXQl9ZG39+fulvnX7XHmsmHSWg0wIzIM2J9CMuqzN9pUOADbMtVdS1nh2o0aV5JF
KSFA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=2SKHncSTr4jTYQFDuBhaotBxw/4PYFrmKNBVyDQtXhA=;
b=n0T+Bh8CAGI32cl0ngCx936Cq1UGNc4WTVDmnAommy42put3VNNSzBTCLtw3K51mDX
pgPXa9aGNhyoScARHcPoeZxy2Vfd4qUzgeycIeQ3hgFhNmd8COV+9kRcS+ilEGxbShWX
MKRkxXNSpNsPk4jpQiQtnbk2ebrM+j2eaEQ4Ku4PPrnh3CvjpRU7Oef3V5F0iaDewJ3Q
6ynAdruo4CZk9o12zFtL3ZSynz268vz/G+YnWBKyADfy7Vevk71CIKZwFauaT8gUmBAG
vrQijX6TQsRez6MXfN6jHQL47qXgpaMGMmpF9kLi8jWetqv7gem/kWitHlroIhDxEIwj
S0vg==
X-Gm-Message-State: AOAM531nFobihcImqVdcXSLSEJxjnp6Py+frcEFJR4rG56aF2jg9/TuW
6AzgOhO5tXwGir5L3tMOeZHVrcmLhJxyw+R0mFR3vWz3bPE=
X-Google-Smtp-Source: ABdhPJxEJba2TuMaEa02n0y5EptpfIBid0miGlZE8c2x5ESpyjaB57Si1dX3xNVX9ieRFDiGvxF75Com+aUxR+JPA+Q=
X-Received: by 2002:a17:906:9741:: with SMTP id o1mr53380ejy.452.1644945014937;
Tue, 15 Feb 2022 09:10:14 -0800 (PST)
MIME-Version: 1.0
References: <CAPfvXfKrnju1fzxOKs3Fx00NOPWHjedF7e4xMSGs8buwc0O2kw@mail.gmail.com>
<CALZpt+FwZTXEYYiJ=1XTXbDVECW41e9rNq8rn8AYr6m3yLAkPA@mail.gmail.com>
<CAPfvXfJN9zeJDYka8BycU102xGdwQ2O9=Khgjag-eYLmXRdsdA@mail.gmail.com>
<CALZpt+G0uXL04onty2N++6tWeX7Y=5KWw3x8-A0MvyUgZR-4Xw@mail.gmail.com>
In-Reply-To: <CALZpt+G0uXL04onty2N++6tWeX7Y=5KWw3x8-A0MvyUgZR-4Xw@mail.gmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Tue, 15 Feb 2022 11:09:56 -0600
Message-ID: <CAGpPWDaZ=Qx_phzjFJXzQc0ePWfuJmGKsPrsvj9X1pBTBrRgWA@mail.gmail.com>
To: Antoine Riard <antoine.riard@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000004a5e1405d8119b0d"
X-Mailman-Approved-At: Tue, 15 Feb 2022 19:09:09 +0000
Subject: Re: [bitcoin-dev] Thoughts on fee bumping
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, 15 Feb 2022 17:10:19 -0000
--0000000000004a5e1405d8119b0d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
> If you wish to fee-bump transaction X with sponsor, how can you be sure
that transaction isn't present in the majority of network nodes, and X has
_not_ been dropped since your last broadcast ?
You're right that you can't assume your target transaction hasn't been
dropped. However, I assume when James said "No rebroadcast (wasted
bandwidth) is required for the original txn data" he meant that in the
context of the "diff" he was talking about. It would be easy enough to
specify a sponsorship transaction that points to a transaction with a
specific id without *requiring* that transaction to be rebroadcast. If your
partner node has that transaction, no rebroadcast is necessary. If your
partner node doesn't have it, they can request it. That way rebroadcast is
only done when necessary. Correct me if my understanding of your suggestion
is wrong James.
>> 2. (from Suhas) "once a valid transaction is created, it should not
become invalid later on unless the inputs are double-spent."
> This doesn't seem like a huge concern to me
I agree that this shouldn't be a concern. In fact, I've asked numerous
people in numerous places what practical downside there is to transactions
that become invalid, and I've heard basically radio silence other than one
off hand remark by satoshi at the dawn of time which didn't seem to me to
have good reasoning. I haven't seen any downside whatsoever of transactions
that can become invalid for anyone waiting the standard 6 confirmations -
the reorg risks only exists for people not waiting for standard
finalization. So I don't think we should consider that aspect of a
sponsorship transaction that can only be mined with the transaction it
sponsors to be a problem unless a specific practical problem case can be
identified. Even if a significant such case was identified, an easy
solution would be to simply allow sponsorship transactions to be mined on
or after the sponsored transaction is mined.
On Mon, Feb 14, 2022 at 7:10 PM Antoine Riard via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> > In the context of fee bumping, I don't see how this is a criticism
> > unique to transaction sponsors, since it also applies to CPFP: if you
> > tried to bump fees for transaction A with child txn B, if some mempool
> > hasn't seen parent A, it will reject B.
>
> Agree, it's a comment raising the shenanigans of tx-diff-only propagation=
,
> afaict affecting equally all fee-bumping primitives. It wasn't a criticis=
m
> specific to transaction sponsors, as at that point of your post, sponsors
> are not introduced yet.
>
> > This still doesn't address the issue I'm talking about, which is if you
> > pre-commit to some "fee-bumping" key in your CPFP outputs and that key
> > ends up being compromised. This isn't a matter of data availability or
> > redundancy.
>
> I'm not sure about the real safety risk of the compromise of the anchor
> output key. Of course, if your anchor output key is compromised and the
> bumped package is already public/known, an attacker can extend your packa=
ge
> with junk to neutralize your carve-out capability (I think). That said,
> this issue sounds solved to me with package relay, as you can always
> broadcast a new version of the package from the root UTXO, without
> attention to the carve-out limitation.
>
> (Side-note: I think we can slowly deprecate the carve-out once package
> relay is deployed, as the fee-bumping flexibility of the latter is a
> superset of the former).
>
> > As I mentioned in the reply to Matt's message, I'm not quite
> > understanding this idea of wanting to bump the fee for something
> > without knowing what it is; that doesn't make much sense to me.
> > The "bump fee" operation seems contingent on knowing
> > what you want to bump.
>
> From your post : "No rebroadcast (wasted bandwidth) is required for the
> original txn data."
>
> I'm objecting to that supposed benefit of a transaction sponsor. If you
> have transaction X and transaction Y spending the same UTXO, both of them
> can be defined as "the original txn data". If you wish to fee-bump
> transaction X with sponsor, how can you be sure that transaction
> Y isn't present in the majority of network nodes, and X has _not_ been
> dropped since your last broadcast ? Otherwise iirc sponsor design, your
> sponsor transaction is going to be rejected.
>
> I think you can't, and thus preventively you should broadcast as a (new
> type) of package the sponsoring/sponsored transaction.
>
> That said, I'm not sure if that issue is equally affecting vaults than
> payment channels. With vaults, the tree of transactions is known ahead,
> and there is no competition in the spends. Assuming the first broadcast h=
as
> been efficient (and it could be a reasonable assumption thanks to mempool
> rebroadcast), the sponsor should propagate.
>
> So I think here for the sake of sponsor efficiency analysis, we might hav=
e
> to class between the protocol with once-for-all-transaction-negotiation
> (vaults) and the ones with off-chain, dynamic re-negotiation (payment
> channels, factories) ?
>
> > I'm not familiar with the L2 dust-limit issues, and I do think that
> > "fixing" RBF behavior is *probably* worthwhile.
>
> Sadly, it sounds that "fixing" RBF behavior is a requirement to eradicate
> the most advanced pinnings... That fix is independent of the fee-bumping
> primitive considered.
>
> > Those issues aside, I
> > think the transaction sponsors idea may be closer to a silver bullet
> > than you're giving it credit for, because designing specifically for th=
e
> > fee-management use case has some big benefits.
>
> I don't deny the scheme is interesting, though I would argue SIGHASH_GROU=
P
> is more efficient, while offering more flexibility. In any case, I think =
we
> should still pursue further the collections of problems and requirements
> (batching, key management, ...) that new fee-bumping primitives should ai=
m
> to solve, before engaging more on the deployment of one of them [0].
>
> [0] In that sense see
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/019031.h=
tml
>
> Le lun. 14 f=C3=A9vr. 2022 =C3=A0 15:29, James O'Beirne <james.obeirne@gm=
ail.com> a
> =C3=A9crit :
>
>> Thanks for your thoughtful reply Antoine.
>>
>> > In a distributed system such as the Bitcoin p2p network, you might
>> > have transaction A and transaction B broadcast at the same time and
>> > your peer topology might fluctuate between original send and
>> > broadcast of the diff, you don't know who's seen what... You might
>> > inefficiently announce diff A on top of B and diff B on top A. We
>> > might leverage set reconciliation there a la Erlay, though likely
>> > with increased round-trips.
>>
>> In the context of fee bumping, I don't see how this is a criticism
>> unique to transaction sponsors, since it also applies to CPFP: if you
>> tried to bump fees for transaction A with child txn B, if some mempool
>> hasn't seen parent A, it will reject B.
>>
>> > Have you heard about SIGHASH_GROUP [0] ?
>>
>> I haven't - I'll spend some time reviewing this. Thanks.
>>
>> > > [me complaining CPFP requires lock-in to keys]
>> >
>> > It's true it requires to pre-specify the fee-bumping key. Though note
>> > the fee-bumping key can be fully separated from the
>> > "vaults"/"channels" set of main keys and hosted on replicated
>> > infrastructure such as watchtowers.
>>
>> This still doesn't address the issue I'm talking about, which is if you
>> pre-commit to some "fee-bumping" key in your CPFP outputs and that key
>> ends up being compromised. This isn't a matter of data availability or
>> redundancy.
>>
>> Note that this failure may be unique to vault use cases, when you're
>> pre-generating potentially large numbers of transactions or covenants
>> that cannot be altered after the fact. If you generate vault txns that
>> assume the use of some key for CPFP-based fee bumping and that key
>> winds up being compromised, that puts you in a an uncomfortable
>> situation: you can no longer bump fees on unvaulting transactions,
>> rendering the vaults possibly unretrievable depending on the fee market.
>>
>> > As a L2 transaction issuer you can't be sure the transaction you wish
>> > to point to is already in the mempool, or have not been replaced by
>> > your counterparty spending the same shared-utxo, either competitively
>> > or maliciously. So as a measure of caution, you should broadcast
>> > sponsor + target transactions in the same package, thus cancelling
>> > the bandwidth saving (I think).
>>
>> As I mentioned in the reply to Matt's message, I'm not quite
>> understanding this idea of wanting to bump the fee for something
>> without knowing what it is; that doesn't make much sense to me.
>> The "bump fee" operation seems contingent on knowing
>> what you want to bump.
>>
>> And if you're, say, trying to broadcast a lightning channel close and
>> you know you need to bump the fee right away, before even broadcasting
>> it, either you're going to
>>
>> - reformulate the txn to bring up the fee rate (e.g. add inputs
>> with some yet-undeployed sighash) as you would have done with RBF, or
>>
>> - you'd have the same "package relay" problem with CPFP that you
>> would with transaction sponsors.
>>
>> So I don't understand the objection here.
>>
>> Also, I didn't mean to discourage existing work on package relay or
>> fixing RBF, which seem clearly important. Maybe I should have noted
>> that explicitly in the original message
>>
>> > I don't think a sponsor is a silver-bullet to solve all the
>> > L2-related mempool issues. It won't solve the most concerning pinning
>> > attacks, as I think the bottleneck is replace-by-fee. Neither solve
>> > the issues encumbered by the L2s by the dust limit.
>>
>> I'm not familiar with the L2 dust-limit issues, and I do think that
>> "fixing" RBF behavior is *probably* worthwhile. Those issues aside, I
>> think the transaction sponsors idea may be closer to a silver bullet
>> than you're giving it credit for, because designing specifically for the
>> fee-management use case has some big benefits.
>>
>> For one, it makes migration easier. That is to say: there is none,
>> whereas there is existing RBF policy that needs consideration.
>>
>> But maybe more importantly, transaction sponsors' limited use case also
>> allows for specifying much more targeted "replacement" policy since
>> sponsors are special-purpose transactions that only exist to
>> dynamically bump feerate. E.g. my SIGHASH_{NONE,SINGLE}|ANYONECANPAY
>> proposal might make complete sense for the sponsors/fee-management use
>> case, and clarify the replacement problem, but obviously wouldn't work
>> for more general transaction replacement. In other words, RBF's
>> general nature might make it a much harder problem to solve well.
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--0000000000004a5e1405d8119b0d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">>=C2=A0
=C2=A0If you wish to fee-bump transaction X with sponsor, how can you be su=
re that transaction=C2=A0isn't present in the majority of network nodes=
, and X has _not_ been dropped since your last broadcast ?<div><br></div><d=
iv>You're right that you can't assume your target transaction hasn&=
#39;t been dropped. However, I assume when James said "No rebroadcast =
(wasted bandwidth) is required for the original txn data" he meant tha=
t in the context of the "diff" he was talking about. It would be =
easy enough to specify a sponsorship transaction that points to a transacti=
on with a specific id without *requiring* that transaction to be rebroadcas=
t. If your partner node has that transaction, no rebroadcast is necessary. =
If your partner node doesn't have it, they can request it. That way reb=
roadcast is only done when necessary. Correct me if my understanding of you=
r suggestion is wrong James.</div><div><br></div><div>>> 2. (from Suh=
as) "once a valid transaction is created, it should not become invalid=
later on unless the inputs are double-spent."</div>> This doesn=
9;t seem like a huge concern to me=C2=A0<div><br></div><div>I agree that th=
is shouldn't be a concern. In fact, I've asked numerous people in n=
umerous places what practical downside there is to transactions that become=
invalid, and I've heard basically radio silence other than one off han=
d remark by satoshi at the dawn of time which didn't seem to me to have=
good reasoning. I haven't seen any downside whatsoever of transactions=
that can become invalid for anyone waiting the standard 6 confirmations - =
the reorg risks only exists for people not waiting for standard finalizatio=
n. So I don't think we should consider that aspect of a sponsorship tra=
nsaction that can only be mined with the transaction it sponsors to be a pr=
oblem unless a specific=C2=A0practical problem case can be identified. Even=
if a significant such=C2=A0case was identified, an easy solution would be =
to simply allow sponsorship transactions to be mined on or after the sponso=
red transaction is mined.=C2=A0</div><div><br></div><div><br></div></div><b=
r><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, =
Feb 14, 2022 at 7:10 PM Antoine Riard via bitcoin-dev <<a href=3D"mailto=
:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.o=
rg</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
"><div dir=3D"ltr">> In the context of fee bumping, I don't see how =
this is a criticism<br>> unique to transaction sponsors, since it also a=
pplies to CPFP: if you<br>> tried to bump fees for transaction A with ch=
ild txn B, if some mempool<br>> hasn't seen parent A, it will reject=
B.<br><br>Agree, it's a comment raising the shenanigans of tx-diff-onl=
y propagation, afaict affecting equally all fee-bumping primitives. It wasn=
't a criticism specific to transaction sponsors, as at that point of yo=
ur post, sponsors are not introduced yet.<br><br>> This still doesn'=
t address the issue I'm talking about, which is if you<br>> pre-comm=
it to some "fee-bumping" key in your CPFP outputs and that key<br=
>> ends up being compromised. This isn't a matter of data availabili=
ty or<br>> redundancy.<br><br>I'm not sure about the real safety ris=
k of the compromise of the anchor output key. Of course, if your anchor out=
put key is compromised and the bumped package is already public/known, an a=
ttacker can extend your package with junk to neutralize your carve-out capa=
bility (I think). That said, this issue sounds solved to me with package re=
lay, as you can always broadcast a new version of the package from the root=
UTXO, without attention to the carve-out limitation.<br><br>(Side-note: I =
think we can slowly deprecate the carve-out once package relay is deployed,=
as the fee-bumping flexibility of the latter is a superset of the former).=
<br><br>> As I mentioned in the reply to Matt's message, I'm not=
quite<br>> understanding this idea of wanting to bump the fee for somet=
hing<br>> without knowing what it is; that doesn't make much sense t=
o me.<br>> The "bump fee" operation seems contingent on knowin=
g<br>> what you want to bump.<br><br>From your post : "No rebroadca=
st (wasted bandwidth) is required for the original txn data." <br><br>=
I'm objecting to that supposed benefit of a transaction sponsor. If you=
have transaction X and transaction Y spending the same UTXO, both of them =
can be defined as "the original txn data". If you wish to fee-bum=
p transaction X with sponsor, how can you be sure that transaction<br>Y isn=
't present in the majority of network nodes, and X has _not_ been dropp=
ed since your last broadcast ? Otherwise iirc sponsor design, your sponsor =
transaction is going to be rejected.<br><br>I think you can't, and thus=
preventively you should broadcast as a (new type) of package the sponsorin=
g/sponsored transaction.<br><br>That said, I'm not sure if that issue i=
s equally affecting vaults than payment channels. With vaults, the tree of =
transactions is =C2=A0known ahead, and there is no competition in the spend=
s. Assuming the first broadcast has been efficient (and it could be a reaso=
nable assumption thanks to mempool<br>rebroadcast), the sponsor should prop=
agate.<br><br>So I think here for the sake of sponsor efficiency analysis, =
we might have to class between the protocol with once-for-all-transaction-n=
egotiation (vaults) and the ones with off-chain, dynamic re-negotiation (pa=
yment channels, factories) ?<br><br>> I'm not familiar with the L2 d=
ust-limit issues, and I do think that<br>> "fixing" RBF behavi=
or is *probably* worthwhile.<br><br>Sadly, it sounds that "fixing"=
; RBF behavior is a requirement to eradicate the most advanced pinnings... =
That fix is independent of the fee-bumping primitive considered.<br><br>>=
; =C2=A0Those issues aside, I<br>> think the transaction sponsors idea m=
ay be closer to a silver bullet<br>> than you're giving it credit fo=
r, because designing specifically for the<br>> fee-management use case h=
as some big benefits.<br><br>I don't deny the scheme is interesting, th=
ough I would argue SIGHASH_GROUP is more efficient, while offering more fle=
xibility. In any case, I think we should still pursue further the collectio=
ns of problems and requirements (batching, key management, ...) that new fe=
e-bumping primitives should aim to solve, before engaging more on the deplo=
yment of one of them [0].<br><br>[0] In that sense see <a href=3D"https://l=
ists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/019031.html" target=
=3D"_blank">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-Ma=
y/019031.html</a><br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" =
class=3D"gmail_attr">Le=C2=A0lun. 14 f=C3=A9vr. 2022 =C3=A0=C2=A015:29, Jam=
es O'Beirne <<a href=3D"mailto:james.obeirne@gmail.com" target=3D"_b=
lank">james.obeirne@gmail.com</a>> a =C3=A9crit=C2=A0:<br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Thanks for your =
thoughtful reply Antoine.<br><br>> In a distributed system such as the B=
itcoin p2p network, you might<br>> have transaction A and transaction B =
=C2=A0broadcast at the same time and<br>> your peer topology might fluct=
uate between original send and<br>> broadcast of the diff, you don't=
know who's seen what... You might<br>> inefficiently announce diff =
A on top of B and diff B on top A. We<br>> might leverage set reconcilia=
tion there a la Erlay, though likely<br>> with increased round-trips.<br=
><br>In the context of fee bumping, I don't see how this is a criticism=
<br>unique to transaction sponsors, since it also applies to CPFP: if you<b=
r>tried to bump fees for transaction A with child txn B, if some mempool<br=
>hasn't seen parent A, it will reject B. <br><br>> Have you heard ab=
out SIGHASH_GROUP [0] ? <br><br>I haven't - I'll spend some time re=
viewing this. Thanks.<br><div><br></div><div>> > [me complaining CPFP=
requires lock-in to keys]</div><div>><br></div>> It's true it re=
quires to pre-specify the fee-bumping key. Though note<br>> the fee-bump=
ing key can be fully separated from the<br>> "vaults"/"ch=
annels" set of main keys and hosted on replicated<br>> infrastructu=
re such as watchtowers.<br><br>This still doesn't address the issue I&#=
39;m talking about, which is if you<br>pre-commit to some "fee-bumping=
" key in your CPFP outputs and that key<br>ends up being compromised. =
This isn't a matter of data availability or<br>redundancy. <br><br>Note=
that this failure may be unique to vault use cases, when you're<br>pre=
-generating potentially large numbers of transactions or covenants<br>that =
cannot be altered after the fact. If you generate vault txns that<br>assume=
the use of some key for CPFP-based fee bumping and that key<br>winds up be=
ing compromised, that puts you in a an uncomfortable<br>situation: you can =
no longer bump fees on unvaulting transactions,<br>rendering the vaults pos=
sibly unretrievable depending on the fee market.<br><br>> As a L2 transa=
ction issuer you can't be sure the transaction you wish<br>> to poin=
t to is already in the mempool, or have not been replaced by<br>> your c=
ounterparty spending the same shared-utxo, either competitively<br>> or =
maliciously. So as a measure of caution, you should broadcast<br>> spons=
or + target transactions in the same package, thus cancelling<br>> the b=
andwidth saving (I think).<br><br>As I mentioned in the reply to Matt's=
message, I'm not quite<br>understanding this idea of wanting to bump t=
he fee for something<br><div>without knowing what it is; that doesn't m=
ake much sense to me. <br></div><div>The "bump fee" operation see=
ms contingent on knowing<br></div><div>what you want to bump.<br></div><br>=
And if you're, say, trying to broadcast a lightning channel close and<b=
r>you know you need to bump the fee right away, before even broadcasting<br=
>it, either you're going to<br><br>- reformulate the txn to bring up th=
e fee rate (e.g. add inputs<br>=C2=A0 with some yet-undeployed sighash) as =
you would have done with RBF, or<br><br>- you'd have the same "pac=
kage relay" problem with CPFP that you<br>=C2=A0 would with transactio=
n sponsors.<br><br>So I don't understand the objection here.<br><br>Als=
o, I didn't mean to discourage existing work on package relay or<br>fix=
ing RBF, which seem clearly important. Maybe I should have noted<br>that ex=
plicitly in the original message<br><br>> I don't think a sponsor is=
a silver-bullet to solve all the<br>> L2-related mempool issues. It won=
't solve the most concerning pinning<br>> attacks, as I think the bo=
ttleneck is replace-by-fee. Neither solve<br>> the issues encumbered by =
the L2s by the dust limit.<br><br>I'm not familiar with the L2 dust-lim=
it issues, and I do think that<br>"fixing" RBF behavior is *proba=
bly* worthwhile. Those issues aside, I<br><div>think the transaction sponso=
rs idea may be closer to a silver bullet <br></div><div>than you're giv=
ing it credit for, because designing specifically for the<br></div>fee-mana=
gement use case has some big benefits.<br><br>For one, it makes migration e=
asier. That is to say: there is none,<br>whereas there is existing RBF poli=
cy that needs consideration. <br><br>But maybe more importantly, transactio=
n sponsors' limited use case also<br>allows for specifying much more ta=
rgeted "replacement" policy since<br>sponsors are special-purpose=
transactions that only exist to<br>dynamically bump feerate. E.g. my SIGHA=
SH_{NONE,SINGLE}|ANYONECANPAY<br>proposal might make complete sense for the=
sponsors/fee-management use<br>case, and clarify the replacement problem, =
but obviously wouldn't work<br>for more general transaction replacement=
. In other words, RBF's<br>general nature might make it a much harder p=
roblem to solve well.<br></div>
</blockquote></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
--0000000000004a5e1405d8119b0d--
|