summaryrefslogtreecommitdiff
path: root/75/a3334a80c663892353ec4b373febfcf331b6af
blob: 3343530fbe012da4c505c8c26cb93007e8540c32 (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
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
Return-Path: <antoine.riard@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 00049C000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 11 Feb 2022 05:27:10 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id C61AB607B4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 11 Feb 2022 05:27:10 +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: smtp3.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id HmvkyuZO7nvL
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 11 Feb 2022 05:27:08 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com
 [IPv6:2607:f8b0:4864:20::b2c])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 721426079D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 11 Feb 2022 05:27:08 +0000 (UTC)
Received: by mail-yb1-xb2c.google.com with SMTP id y129so21772367ybe.7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 10 Feb 2022 21:27:08 -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;
 bh=Ootu4AaqPP8i3DeFJ3b5dkifAuMLgzvP+Fm8RiA9Crk=;
 b=Tf5RFVAscsi/H972KgCBBQV4dDt2U9pFU0G6YCdWr20QuDEIJAt6IGoXa87BBkevEF
 He735J/utOsIQ1T8qQTg/LTvx1tMvamYdHe7g4ZtHXLQlaMLM0rmJ5O7+whxhlPDBOaa
 DL5fD6ojDt0epOfnzX2FLorpvgZLiiE/6M5UKNKq2STgg8cg49DoSoy/bmFI0cct0Dz7
 QANfLQlNASHbFSeduZPWLIbst5vf3c71OZYnO5zsAd87RjX5L2+F4zRI8nMgKJ4oc6rT
 XhiSqZVPDhAnr2u6+atVHCv5J1Ndl+MnbYTaOHnrHdVmdC7xa6X+7++zxdIUAO5UN5A5
 9cCg==
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;
 bh=Ootu4AaqPP8i3DeFJ3b5dkifAuMLgzvP+Fm8RiA9Crk=;
 b=wo8w6jdZjWC4wWkSjRFSbDrhD+7bSQaZWa+R5BHJSX9dZh0VEYEh71xTkGvu5pye73
 diq2b/R3nu1YXbM2kCj/U80mlP9POZliNzROcYOKtf/8+4naVIuufN36Dp5HjBbdsCu6
 s0HOktz1DYYDpXswkd2R01ZlA1xewjWBSbWmQrV+LUx0lQku5AgmvAWeJTwZplltMUbz
 7IxePWcH76DX218arx17/slfS0Gjq3qibXIM7REM1mt4wBdldFkbbxx0MVyrXKDvj5DT
 gDDDfcqBL4G48jYZd2ghq3uyBbqm6Z/V4WzErc5WlulmKlT8pITChYjwaPs17iE+d83a
 lvJg==
X-Gm-Message-State: AOAM533rQnilxjm/2Oeuw3b8zqFkciZiQI82eM+gC0SpETlvAOlFokMk
 TicqFE0Ec+L87lfS9xUzi8Js1JE04J5hzTELsQg=
X-Google-Smtp-Source: ABdhPJxSwS1pFWLO7cAjP5Y80vek+cTIePLsqLIrZJWSCe7yeakjeHJwo58658FoErrE/fe5DrkEBGJVYUhFefqe0jA=
X-Received: by 2002:a81:b61b:: with SMTP id u27mr127913ywh.450.1644557226115; 
 Thu, 10 Feb 2022 21:27:06 -0800 (PST)
MIME-Version: 1.0
References: <CAPfvXfKrnju1fzxOKs3Fx00NOPWHjedF7e4xMSGs8buwc0O2kw@mail.gmail.com>
In-Reply-To: <CAPfvXfKrnju1fzxOKs3Fx00NOPWHjedF7e4xMSGs8buwc0O2kw@mail.gmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Fri, 11 Feb 2022 00:26:53 -0500
Message-ID: <CALZpt+FwZTXEYYiJ=1XTXbDVECW41e9rNq8rn8AYr6m3yLAkPA@mail.gmail.com>
To: "James O'Beirne" <james.obeirne@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000046865005d7b75109"
X-Mailman-Approved-At: Fri, 11 Feb 2022 09:12:53 +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: Fri, 11 Feb 2022 05:27:11 -0000

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

Hi James,

I fully agree on the need to reframe the conversation around
mempools/fee-bumping/L2s though please see my following comments, it's far
from simple!

> Layering on special cases, more carve-outs, and X and Y percentage
> thresholds is going to make reasoning about the mempool harder than it
> already is.

I think that's true with a lot of (all ?) pieces of software, there is a
trend towards complexification. As new Bitcoin use-cases such as LN or
vaults appear, it's not surprising to see the base layer upper interfaces
changing to support the requirements. Same with kernels, at beginning, you
can have a basic memory support with paging/memory rights/kernel allocators
then as you start to support more platforms/devices you might have to
support swaps/DMA/VMs management...

That we should keep the complexity reasonably sane to enable human
auditing, and maybe learn from the failures of systems engineering, that's
something to muse on.

> The countervailing force here ends up being spam prevention (a la
min-relay-fee)
> to prevent someone from consuming bandwidth and mempool space with a long
series of
> infinitesimal fee-bumps.

I think here we should dissociate a) long-chain of transactions and b)
high-number of repeated fee-bumps.

For a) _if_ SIGHASH_ANYPREVOUT is deployed and Eltoo adopted as a primary
update mechanism for stateful L2s, one might envision long-chain of update
transactions servicing as a new pinning vector, where all the chain
elements are offering a compelling feerate/fees. It might be solvable with
smarter mempool logic sorting the elements from the best offer to the lower
ones, though that issue would need more serious investigation.

For b) if we bound with a hard constant the number of RBF attempts, we
decrease the fault-tolerance of L2 transaction issuers. Some of them might
connect directly to the miners because they're offering higher number of
incentive-compatible RBF attempts than vanilla full-nodes. That might
provoke a more or slow centralization of the transaction relay topology...

> Instead of prompting a rebroadcast of the original transaction for
> replacement, which contains a lot of data not new to the network, it
> makes more sense to broadcast the "diff" which is the additive
> contribution towards some txn's feerate.

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.

> It's probably uncontroversial at this
> point to say that even RBF itself is kind of a hack - a special
> sequence number should not be necessary for post-broadcast contribution
> toward feerate.

I think here we should dissociate the replace-by-fee mechanism itself from
the replacement signaling one. To have a functional RBF, you don't need
signaling at all, just consider all received transactions as replaceable.
The replacement signaling one has been historically motivated to protect
the applications relying on zero-confs (with all the past polemics about
the well-foundedness of such claims on other nodes' policy).

> In a sane design, no structural foresight - and certainly no wasted
>bytes in the form of unused anchor outputs - should be needed in order
>to add to a miner's reward for confirming a given transaction.

Have you heard about SIGHASH_GROUP [0] ? It would move away from the
transaction to enable arbitrary bundles of input/outputs. You will have
your pre-signed bundle of inputs/outputs enforcing your LN/vaults/L2 and
then at broadcast time, you can attach an input/output. I think it would
answer your structural foresight.

> One of the practical downsides of CPFP that I haven't seen discussed in
> this conversation is that it requires the transaction to pre-specify the
> keys needed to sign for fee bumps. This is problematic if you're, for
> example, using a vault structure that makes use of pre-signed
> transactions.

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.

> The interface for end-users is very straightforward: if you want to bump
> fees, specify a transaction that contributes incrementally to package
> feerate for some txid. Simple.

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).

> This theoretical concession seems preferable to heaping more rules onto
an already labyrinthine mempool policy that is difficult for both
implementers and users to reason about practically and conceptually.

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.

> If a soft-fork is the cost of cleaning up this essential process,
> consideration should be given to paying it as a one-time cost. This
> topic merits a separate post, but consider that in the 5 years leading
> up to the 2017 SegWit drama, we averaged about a soft-fork a year.
> Uncontroversial, "safe" changes to the consensus protocol shouldn't be
> out of the question when significant practical benefit is plain to see.

Zooming out, I think we're still early in solving those L2 issues, as the
most major second-layers are still in a design or deployment phase. We
might freeze our transaction propagation interface, and get short for some
of the most interesting ones like channel factories and payment pools.
Further, I think we're not entirely sure how the mining ecosystem is going
to behave once the reward is drained and their incentives towards L2
confirmations.

Still, if we think we have a correct picture of the fee-bumping/mempools
issues and are sufficiently confident with the stability of L2 designs, I
think the next step would be to come with quantitative modelling of each
resources consumed by fee-bumping (CPU validation/bandwidth/signing
interactivity for the L2s...) and then score the "next-gen" fee-bumping
primitives.

> I'm not out to propose soft-forks lightly, but the current complexity
> in fee management feels untenable, and as evidenced by all the
> discussion lately, fees are an increasingly crucial part of the system.

Overall, I think that's a relevant discussion to have ecosystem-wise.
Though there is a lot of context and I don't think there is a simple way
forward. Maybe better to stick to an evolutionary development process with
those mempool/fee-bumping issues. We might envision two-or-three steps
ahead though unlikely more.

Cheers,
Antoine

[0] SIGHASH_GROUP described here
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/019031.htm=
l
and roughly roughly implemented here :
https://github.com/ariard/bitcoin/pull/1

Le jeu. 10 f=C3=A9vr. 2022 =C3=A0 14:48, James O'Beirne via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit :

> There's been much talk about fee-bumping lately, and for good reason -
> dynamic fee management is going to be a central part of bitcoin use as
> the mempool fills up (lord willing) and right now fee-bumping is
> fraught with difficulty and pinning peril.
>
> Gloria's recent post on the topic[0] was very lucid and highlights a
> lot of the current issues, as well as some proposals to improve the
> situation.
>
> As others have noted, the post was great. But throughout the course
> of reading it and the ensuing discussion, I became troubled by the
> increasing complexity of both the status quo and some of the
> proposed remedies.
>
> Layering on special cases, more carve-outs, and X and Y percentage
> thresholds is going to make reasoning about the mempool harder than it
> already is. Special consideration for "what should be in the next
> block" and/or the caching of block templates seems like an imposing
> dependency, dragging in a bunch of state and infrastructure to a
> question that should be solely limited to mempool feerate aggregates
> and the feerate of the particular txn package a wallet is concerned
> with.
>
> This is bad enough for protocol designers and Core developers, but
> making the situation any more intractable for "end-users" and wallet
> developers feels wrong.
>
> I thought it might be useful to step back and reframe. Here are a few
> aims that are motivated chiefly by the quality of end-user experience,
> constrained to obey incentive compatibility (i.e. miner reward, DoS
> avoidance). Forgive the abstract dalliance for a moment; I'll talk
> through concretes afterwards.
>
>
> # Purely additive feerate bumps should never be impossible
>
> Any user should always be able to add to the incentive to mine any
> transaction in a purely additive way. The countervailing force here
> ends up being spam prevention (a la min-relay-fee) to prevent someone
> from consuming bandwidth and mempool space with a long series of
> infinitesimal fee-bumps.
>
> A fee bump, naturally, should be given the same per-byte consideration
> as a normal Bitcoin transaction in terms of relay and block space,
> although it would be nice to come up with a more succinct
> representation. This leads to another design principle:
>
>
> # The bandwidth and chain space consumed by a fee-bump should be minimal
>
> Instead of prompting a rebroadcast of the original transaction for
> replacement, which contains a lot of data not new to the network, it
> makes more sense to broadcast the "diff" which is the additive
> contribution towards some txn's feerate.
>
> This dovetails with the idea that...
>
>
> # Special transaction structure should not be required to bump fees
>
> In an ideal design, special structural foresight would not be needed
> in order for a txn's feerate to be improved after broadcast.
>
> Anchor outputs specified solely for CPFP, which amount to many bytes of
> wasted chainspace, are a hack. It's probably uncontroversial at this
> point to say that even RBF itself is kind of a hack - a special
> sequence number should not be necessary for post-broadcast contribution
> toward feerate. Not to mention RBF's seemingly wasteful consumption of
> bandwidth due to the rebroadcast of data the network has already seen.
>
> In a sane design, no structural foresight - and certainly no wasted
> bytes in the form of unused anchor outputs - should be needed in order
> to add to a miner's reward for confirming a given transaction.
>
> Planning for fee-bumps explicitly in transaction structure also often
> winds up locking in which keys are required to bump fees, at odds
> with the idea that...
>
>
> # Feerate bumps should be able to come from anywhere
>
> One of the practical downsides of CPFP that I haven't seen discussed in
> this conversation is that it requires the transaction to pre-specify the
> keys needed to sign for fee bumps. This is problematic if you're, for
> example, using a vault structure that makes use of pre-signed
> transactions.
>
> What if the key you specified n the anchor outputs for a bunch of
> pre-signed txns is compromised? What if you'd like to be able to
> dynamically select the wallet that bumps fees? CPFP does you no favors
> here.
>
> There is of course a tension between allowing fee bumps to come from
> anywhere and the threat of pinning-like attacks. So we should venture
> to remove pinning as a possibility, in line with the first design
> principle I discuss.
>
>
> ---
>
> Coming down to earth, the "tabula rasa" thought experiment above has led
> me to favor an approach like the transaction sponsors design that Jeremy
> proposed in a prior discussion back in 2020[1].
>
> Transaction sponsors allow feerates to be bumped after a transaction's
> broadcast, regardless of the structure of the original transaction.
> No rebroadcast (wasted bandwidth) is required for the original txn data.
> No wasted chainspace on only-maybe-used prophylactic anchor outputs.
>
> The interface for end-users is very straightforward: if you want to bump
> fees, specify a transaction that contributes incrementally to package
> feerate for some txid. Simple.
>
> In the original discussion, there were a few main objections that I noted=
:
>
> 1. In Jeremy's original proposal, only one sponsor txn per txid is
>    allowed by policy. A malicious actor could execute a pinning-like
>    attack by specifying an only-slightly-helpful feerate sponsor that
>    then precludes other larger bumps.
>
> I think there are some ways around this shortcoming. For example: what
> if, by policy, sponsor txns had additional constraints that
>
>   - each input must be signed {SIGHASH_SINGLE,SIGHASH_NONE}|ANYONECANPAY,
>   - the txn must be specified RBFable,
>   - a replacement for the sponsor txn must raise the sponsor feerate,
>     including ancestors (maybe this is inherent in "is RBFable," but
>     I don't want to conflate absolute feerates into this).
>
> That way, there is still at most a single sponsor txn per txid in the
> mempool, but anyone can "mix in" inputs which bump the effective
> feerate of the sponsor.
>
> This may not be the exact solution we want, but I think it demonstrates
> that the sponsors design has some flexibility and merits some thinking.
>
> The second objection about sponsors was
>
> 2. (from Suhas) sponsors break the classic invariant: "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 if you consider the txid
> being sponsored as a sort of spiritual input to the sponsor. While the
> theoretical objection against broadening where one has to look in a txn
> to determine its dependencies is understandable, I don't see what the
> practical cost here is.
>
> Reorg complexity seems comparable if not identical, especially if we
> broaden sponsor rules to allow blocks to contain sponsor txns that are
> both for txids in the same block _or_ already included in the chain.
>
> This theoretical concession seems preferable to heaping more rules onto
> an already labyrinthine mempool policy that is difficult for both
> implementers and users to reason about practically and conceptually.
>
> A third objection that wasn't posed, IIRC, but almost certainly would
> be:
>
> 3. Transaction sponsors requires a soft-fork.
>
> Soft-forks are no fun, but I'll tell you what also isn't fun: being on
> the hook to model (and sometimes implement) a dizzying potpourri of
> mempool policies and special-cases. Expecting wallet implementers to
> abide by a maze of rules faithfully in order to ensure txn broadcast and
> fee management invites bugs for perpetuity and network behavior that is
> difficult to reason about a priori. Use of CPFP in the long-term also
> risks needless chain waste.
>
> If a soft-fork is the cost of cleaning up this essential process,
> consideration should be given to paying it as a one-time cost. This
> topic merits a separate post, but consider that in the 5 years leading
> up to the 2017 SegWit drama, we averaged about a soft-fork a year.
> Uncontroversial, "safe" changes to the consensus protocol shouldn't be
> out of the question when significant practical benefit is plain to see.
>
> ---
>
> I hope this message has added some framing to the discussion on fees,
> as well prompting other participants to go back and give the
> transaction sponsor proposal a serious look. The sponsors interface is
> about the simplest I can imagine for wallets, and it seems easy to
> reason about for implementers on Core and elsewhere.
>
> I'm not out to propose soft-forks lightly, but the current complexity
> in fee management feels untenable, and as evidenced by all the
> discussion lately, fees are an increasingly crucial part of the system.
>
>
>
> [0]:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/0198=
17.html
> [1]:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/01=
8168.html
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">Hi James,<br><br>I fully agree on the need to reframe the =
conversation around mempools/fee-bumping/L2s though please see my following=
 comments, it&#39;s far from simple!<br><br>&gt; Layering on special cases,=
 more carve-outs, and X and Y percentage<br>&gt; thresholds is going to mak=
e reasoning about the mempool harder than it<br>&gt; already is.<br><br>I t=
hink that&#39;s true with a lot of (all ?) pieces of software, there is a t=
rend towards complexification. As new Bitcoin use-cases such as LN or vault=
s appear, it&#39;s not surprising to see the base layer upper interfaces ch=
anging to support the requirements. Same with kernels, at beginning, you ca=
n have a basic memory support with paging/memory rights/kernel allocators t=
hen as you start to support more platforms/devices you might have to suppor=
t swaps/DMA/VMs management...<br><br>That we should keep the complexity rea=
sonably sane to enable human auditing, and maybe learn from the failures of=
 systems engineering, that&#39;s something to muse on.<br><br>&gt; The coun=
tervailing force here ends up being spam prevention (a la min-relay-fee)<br=
>&gt; to prevent someone from consuming bandwidth and mempool space with a =
long series of<br>&gt; infinitesimal fee-bumps.<br><br>I think here we shou=
ld dissociate a) long-chain of transactions and b) high-number of repeated =
fee-bumps.<br><br>For a) _if_ SIGHASH_ANYPREVOUT is deployed and Eltoo adop=
ted as a primary update mechanism for stateful L2s, one might envision long=
-chain of update transactions servicing as a new pinning vector, where all =
the chain elements are offering a compelling feerate/fees. It might be solv=
able with smarter mempool logic sorting the elements from the best offer to=
 the lower ones, though that issue would need more serious investigation.<b=
r><br>For b) if we bound with a hard constant the number of RBF attempts, w=
e decrease the fault-tolerance of L2 transaction issuers. Some of them migh=
t connect directly to the miners because they&#39;re offering higher number=
 of incentive-compatible RBF attempts than vanilla full-nodes. That might p=
rovoke a more or slow centralization of the transaction relay topology...<b=
r><br>&gt; Instead of prompting a rebroadcast of the original transaction f=
or<br>&gt; replacement, which contains a lot of data not new to the network=
, it<br>&gt; makes more sense to broadcast the &quot;diff&quot; which is th=
e additive<br>&gt; contribution towards some txn&#39;s feerate.<br><br>In a=
 distributed system such as the Bitcoin p2p network, you might have transac=
tion A and transaction B=C2=A0 broadcast at the same time and your peer top=
ology might fluctuate between original send and broadcast<br>of the diff, y=
ou don&#39;t know who&#39;s seen what... You might inefficiently announce d=
iff 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.<br><br>&gt; It=
&#39;s probably uncontroversial at this<br>&gt; point to say that even RBF =
itself is kind of a hack - a special<br>&gt; sequence number should not be =
necessary for post-broadcast contribution<br>&gt; toward feerate.<br><br>I =
think here we should dissociate the replace-by-fee mechanism itself from th=
e replacement signaling one. To have a functional RBF, you don&#39;t need s=
ignaling at all, just consider all received transactions as replaceable. Th=
e replacement signaling one has been historically motivated to protect the =
applications relying on zero-confs (with all the past polemics about the we=
ll-foundedness of such claims on other nodes&#39; policy).<br><br>&gt; In a=
 sane design, no structural foresight - and certainly no wasted<br>&gt;byte=
s in the form of unused anchor outputs - should be needed in order<br>&gt;t=
o add to a miner&#39;s reward for confirming a given transaction.<br><br>Ha=
ve you heard about SIGHASH_GROUP [0] ? It would move away from the transact=
ion to enable arbitrary bundles of input/outputs. You will have your pre-si=
gned bundle of inputs/outputs enforcing your LN/vaults/L2 and then at broad=
cast time, you can attach an input/output. I think it would answer your str=
uctural foresight.<br><br>&gt; One of the practical downsides of CPFP that =
I haven&#39;t seen discussed in<br>&gt; this conversation is that it requir=
es the transaction to pre-specify the<br>&gt; keys needed to sign for fee b=
umps. This is problematic if you&#39;re, for<br>&gt; example, using a vault=
 structure that makes use of pre-signed<br>&gt; transactions.<br><br>It&#39=
;s true it requires to pre-specify the fee-bumping key. Though note the fee=
-bumping key can be fully separated from the &quot;vaults&quot;/&quot;chann=
els&quot; set of main keys and hosted on replicated infrastructure such as =
watchtowers.<br><br>&gt; The interface for end-users is very straightforwar=
d: if you want to bump<br>&gt; fees, specify a transaction that contributes=
 incrementally to package<br>&gt; feerate for some txid. Simple.<br><br>As =
a L2 transaction issuer you can&#39;t be sure the transaction you wish to p=
oint to is already in the mempool, or have not been replaced by your counte=
rparty spending the same shared-utxo, either competitively or maliciously. =
So as a measure of caution, you should broadcast sponsor + target transacti=
ons in the same package, thus cancelling the bandwidth saving (I think).<br=
><br>&gt; This theoretical concession seems preferable to heaping more rule=
s onto<br>an already labyrinthine mempool policy that is difficult for both=
<br>implementers and users to reason about practically and conceptually.<br=
><br>I don&#39;t think a sponsor is a silver-bullet to solve all the L2-rel=
ated mempool issues. It won&#39;t solve the most concerning pinning attacks=
, as I think the bottleneck is replace-by-fee. Neither solve the issues enc=
umbered by the L2s by the dust limit.<br><br>&gt; If a soft-fork is the cos=
t of cleaning up this essential process,<br>&gt; consideration should be gi=
ven to paying it as a one-time cost. This<br>&gt; topic merits a separate p=
ost, but consider that in the 5 years leading<br>&gt; up to the 2017 SegWit=
 drama, we averaged about a soft-fork a year.<br>&gt; Uncontroversial, &quo=
t;safe&quot; changes to the consensus protocol shouldn&#39;t be<br>&gt; out=
 of the question when significant practical benefit is plain to see.<br><br=
>Zooming out, I think we&#39;re still early in solving those L2 issues, as =
the most major second-layers are still in a design or deployment phase. We =
might freeze our transaction propagation interface, and get short for some =
of the most interesting ones like channel factories and payment pools. Furt=
her, I think we&#39;re not entirely sure how the mining ecosystem is going =
to behave once the reward is drained and their incentives towards L2 confir=
mations.<br><br>Still, if we think we have a correct picture of the fee-bum=
ping/mempools issues and are sufficiently confident with the stability of L=
2 designs, I think the next step would be to come with quantitative modelli=
ng of each resources consumed by fee-bumping (CPU validation/bandwidth/sign=
ing interactivity for the L2s...) and then score the &quot;next-gen&quot; f=
ee-bumping primitives.<br><br>&gt; I&#39;m not out to propose soft-forks li=
ghtly, but the current complexity<br>&gt; in fee management feels untenable=
, and as evidenced by all the<br>&gt; discussion lately, fees are an increa=
singly crucial part of the system.<br><br>Overall, I think that&#39;s a rel=
evant discussion to have ecosystem-wise. Though there is a lot of context a=
nd I don&#39;t think there is a simple way forward. Maybe better to stick t=
o an evolutionary development process with those mempool/fee-bumping issues=
. We might envision two-or-three steps ahead though unlikely more.<br><br>C=
heers,<br>Antoine<br><br>[0] SIGHASH_GROUP described here <a href=3D"https:=
//lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/019031.html">htt=
ps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/019031.html</=
a><br>and roughly roughly implemented here : <a href=3D"https://github.com/=
ariard/bitcoin/pull/1">https://github.com/ariard/bitcoin/pull/1</a><br></di=
v><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=
=C2=A0jeu. 10 f=C3=A9vr. 2022 =C3=A0=C2=A014:48, James O&#39;Beirne via bit=
coin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitco=
in-dev@lists.linuxfoundation.org</a>&gt; a =C3=A9crit=C2=A0:<br></div><bloc=
kquote 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"><div>There&#3=
9;s been much talk about fee-bumping lately, and for good reason -<br>dynam=
ic fee management is going to be a central part of bitcoin use as<br>the me=
mpool fills up (lord willing) and right now fee-bumping is<br>fraught with =
difficulty and pinning peril.<br><br>Gloria&#39;s recent post on the topic[=
0] was very lucid and highlights a<br>lot of the current issues, as well as=
 some proposals to improve the<br>situation.<br><br>As others have noted, t=
he post was great. But throughout the course<br>of reading it and the ensui=
ng discussion, I became troubled by the<br>increasing complexity of both th=
e status quo and some of the <br></div><div>proposed remedies. <br></div><d=
iv><br>Layering on special cases, more carve-outs, and X and Y percentage<b=
r>thresholds is going to make reasoning about the mempool harder than it<br=
>already is. Special consideration for &quot;what should be in the next<br>=
block&quot; and/or the caching of block templates seems like an imposing<br=
>dependency, dragging in a bunch of state and infrastructure to a<br>questi=
on that should be solely limited to mempool feerate aggregates<br>and the f=
eerate of the particular txn package a wallet is concerned<br>with. <br><br=
>This is bad enough for protocol designers and Core developers, but<br>maki=
ng the situation any more intractable for &quot;end-users&quot; and wallet<=
br>developers feels wrong.<br><br>I thought it might be useful to step back=
 and reframe. Here are a few<br>aims that are motivated chiefly by the qual=
ity of end-user experience,<br>constrained to obey incentive compatibility =
(i.e. miner reward, DoS<br>avoidance). Forgive the abstract dalliance for a=
 moment; I&#39;ll talk<br>through concretes afterwards.<br><br><br># Purely=
 additive feerate bumps should never be impossible<br><br>Any user should a=
lways be able to add to the incentive to mine any<br>transaction in a purel=
y additive way. The countervailing force here<br>ends up being spam prevent=
ion (a la min-relay-fee) to prevent someone<br>from consuming bandwidth and=
 mempool space with a long series of<br>infinitesimal fee-bumps. <br><br>A =
fee bump, naturally, should be given the same per-byte consideration<br>as =
a normal Bitcoin transaction in terms of relay and block space,<br>although=
 it would be nice to come up with a more succinct<br>representation. This l=
eads to another design principle:<br><br><br># The bandwidth and chain spac=
e consumed by a fee-bump should be minimal<br><br>Instead of prompting a re=
broadcast of the original transaction for<br>replacement, which contains a =
lot of data not new to the network, it<br>makes more sense to broadcast the=
 &quot;diff&quot; which is the additive<br>contribution towards some txn&#3=
9;s feerate. <br><br>This dovetails with the idea that...<br><br><br># Spec=
ial transaction structure should not be required to bump fees<br><br>In an =
ideal design, special structural foresight would not be needed <br>in order=
 for a txn&#39;s feerate to be improved after broadcast.<br><br>Anchor outp=
uts specified solely for CPFP, which amount to many bytes of<br>wasted chai=
nspace, are a hack. It&#39;s probably uncontroversial at this<br>point to s=
ay that even RBF itself is kind of a hack - a special<br>sequence number sh=
ould not be necessary for post-broadcast contribution<br>toward feerate. No=
t to mention RBF&#39;s seemingly wasteful consumption of<br>bandwidth due t=
o the rebroadcast of data the network has already seen.<br><br>In a sane de=
sign, no structural foresight - and certainly no wasted<br>bytes in the for=
m of unused anchor outputs - should be needed in order<br>to add to a miner=
&#39;s reward for confirming a given transaction.<br><br>Planning for fee-b=
umps explicitly in transaction structure also often<br>winds up locking in =
which keys are required to bump fees, at odds<br>with the idea that...<br><=
br><br># Feerate bumps should be able to come from anywhere<br><br>One of t=
he practical downsides of CPFP that I haven&#39;t seen discussed in<br>this=
 conversation is that it requires the transaction to pre-specify the<br>key=
s needed to sign for fee bumps. This is problematic if you&#39;re, for<br>e=
xample, using a vault structure that makes use of pre-signed<br>transaction=
s. <br><br>What if the key you specified n the anchor outputs for a bunch o=
f<br>pre-signed txns is compromised? What if you&#39;d like to be able to<b=
r>dynamically select the wallet that bumps fees? CPFP does you no favors<br=
>here.<br><br>There is of course a tension between allowing fee bumps to co=
me from<br>anywhere and the threat of pinning-like attacks. So we should ve=
nture<br>to remove pinning as a possibility, in line with the first design<=
br>principle I discuss.<br><br><br>---<br><br>Coming down to earth, the &qu=
ot;tabula rasa&quot; thought experiment above has led<br>me to favor an app=
roach like the transaction sponsors design that Jeremy<br>proposed in a pri=
or discussion back in 2020[1].<br><br>Transaction sponsors allow feerates t=
o be bumped after a transaction&#39;s<br>broadcast, regardless of the struc=
ture of the original transaction.<br>No rebroadcast (wasted bandwidth) is r=
equired for the original txn data.<br>No wasted chainspace on only-maybe-us=
ed prophylactic anchor outputs. <br><br>The interface for end-users is very=
 straightforward: if you want to bump<br>fees, specify a transaction that c=
ontributes incrementally to package<br>feerate for some txid. Simple.<br><b=
r>In the original discussion, there were a few main objections that I noted=
:<br><br>1. In Jeremy&#39;s original proposal, only one sponsor txn per txi=
d is<br>=C2=A0 =C2=A0allowed by policy. A malicious actor could execute a p=
inning-like <br>=C2=A0 =C2=A0attack by specifying an only-slightly-helpful =
feerate sponsor that <br>=C2=A0 =C2=A0then precludes other larger bumps.<br=
><br>I think there are some ways around this shortcoming. For example: what=
<br>if, by policy, sponsor txns had additional constraints that <br><br>=C2=
=A0 - each input must be signed {SIGHASH_SINGLE,SIGHASH_NONE}|ANYONECANPAY,=
<br>=C2=A0 - the txn must be specified RBFable,<br>=C2=A0 - a replacement f=
or the sponsor txn must raise the sponsor feerate, <br>=C2=A0 =C2=A0 includ=
ing ancestors (maybe this is inherent in &quot;is RBFable,&quot; but <br>=
=C2=A0 =C2=A0 I don&#39;t want to conflate absolute feerates into this).<br=
><br>That way, there is still at most a single sponsor txn per txid in the<=
br>mempool, but anyone can &quot;mix in&quot; inputs which bump the effecti=
ve<br>feerate of the sponsor.<br><br>This may not be the exact solution we =
want, but I think it demonstrates<br>that the sponsors design has some flex=
ibility and merits some thinking.<br><br>The second objection about sponsor=
s was<br><br>2. (from Suhas) sponsors break the classic invariant: &quot;on=
ce a valid<br>=C2=A0 =C2=A0transaction is created, it should not become inv=
alid later on unless <br>=C2=A0 =C2=A0the inputs are double-spent.&quot;<br=
><br>This doesn&#39;t seem like a huge concern to me if you consider the tx=
id<br>being sponsored as a sort of spiritual input to the sponsor. While th=
e<br>theoretical objection against broadening where one has to look in a tx=
n<br>to determine its dependencies is understandable, I don&#39;t see what =
the<br>practical cost here is. <br><br>Reorg complexity seems comparable if=
 not identical, especially if we<br>broaden sponsor rules to allow blocks t=
o contain sponsor txns that are<br>both for txids in the same block _or_ al=
ready included in the chain.<br><br>This theoretical concession seems prefe=
rable to heaping more rules onto<br>an already labyrinthine mempool policy =
that is difficult for both<br>implementers and users to reason about practi=
cally and conceptually.<br><br>A third objection that wasn&#39;t posed, IIR=
C, but almost certainly would<br>be:<br><br>3. Transaction sponsors require=
s a soft-fork.<br><br>Soft-forks are no fun, but I&#39;ll tell you what als=
o isn&#39;t fun: being on<br>the hook to model (and sometimes implement) a =
dizzying potpourri of<br>mempool policies and special-cases. Expecting wall=
et implementers to<br>abide by a maze of rules faithfully in order to ensur=
e txn broadcast and<br>fee management invites bugs for perpetuity and netwo=
rk behavior that is<br>difficult to reason about a priori. Use of CPFP in t=
he long-term also<br>risks needless chain waste.<br><br>If a soft-fork is t=
he cost of cleaning up this essential process,<br>consideration should be g=
iven to paying it as a one-time cost. This<br>topic merits a separate post,=
 but consider that in the 5 years leading<br>up to the 2017 SegWit drama, w=
e averaged about a soft-fork a year.<br>Uncontroversial, &quot;safe&quot; c=
hanges to the consensus protocol shouldn&#39;t be<br>out of the question wh=
en significant practical benefit is plain to see.<br><br>---<br><br>I hope =
this message has added some framing to the discussion on fees,<br>as well p=
rompting other participants to go back and give the<br>transaction sponsor =
proposal a serious look. The sponsors interface is<br>about the simplest I =
can imagine for wallets, and it seems easy to<br>reason about for implement=
ers on Core and elsewhere. =C2=A0 =C2=A0 =C2=A0 =C2=A0<br><br>I&#39;m not o=
ut to propose soft-forks lightly, but the current complexity<br>in fee mana=
gement feels untenable, and as evidenced by all the<br>discussion lately, f=
ees are an increasingly crucial part of the system. <br><br><br><br>[0]: <a=
 href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-Janua=
ry/019817.html" target=3D"_blank">https://lists.linuxfoundation.org/piperma=
il/bitcoin-dev/2022-January/019817.html</a><br>[1]: <a href=3D"https://list=
s.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html" tar=
get=3D"_blank">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020=
-September/018168.html</a><br></div></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>

--00000000000046865005d7b75109--