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
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
|
Return-Path: <email@yancy.lol>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id EA435C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 31 Oct 2022 17:21:15 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id B41214034E
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 31 Oct 2022 17:21:15 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org B41214034E
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7,
RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 98vaUpYUeQny
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 31 Oct 2022 17:21:12 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 0D107402BC
Received: from relay9-d.mail.gandi.net (relay9-d.mail.gandi.net
[217.70.183.199])
by smtp4.osuosl.org (Postfix) with ESMTPS id 0D107402BC
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 31 Oct 2022 17:21:11 +0000 (UTC)
Received: (Authenticated sender: email@yancy.lol)
by mail.gandi.net (Postfix) with ESMTPA id DB2ECFF805;
Mon, 31 Oct 2022 17:21:08 +0000 (UTC)
MIME-Version: 1.0
Date: Mon, 31 Oct 2022 18:21:08 +0100
From: email@yancy.lol
To: Greg Sanders <gsanders87@gmail.com>, Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <CAB3F3Dt=2hDXXw6Jz9QwnotkNLyGdZn9GZLHFXu0Dnyz3tsc0w@mail.gmail.com>
References: <Y1nIKjQC3DkiSGyw@erisian.com.au>
<CAFp6fsFm06J2G1=3ojQvcL9gbEbQ41C4rmf3=Jkm9Qm0VBhhKw@mail.gmail.com>
<CAB3F3Dt=2hDXXw6Jz9QwnotkNLyGdZn9GZLHFXu0Dnyz3tsc0w@mail.gmail.com>
Message-ID: <23dac89d36c356b9266db07e09c2de8e@yancy.lol>
X-Sender: email@yancy.lol
Content-Type: multipart/alternative;
boundary="=_4372f650f906433ddfa64efff7ea1ba1"
X-Mailman-Approved-At: Mon, 31 Oct 2022 17:29:58 +0000
Subject: Re: [bitcoin-dev] On mempool policy consistency
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Oct 2022 17:21:16 -0000
--=_4372f650f906433ddfa64efff7ea1ba1
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII;
format=flowed
Protocol Devs,
After reading through this email thread and BIP125, I'm curious if
non-rbf nodes will relay full-rbf transactions and vice versa. That is
to say, if only one non-rbf node exists on the network, however, every
other node implements full-rbf, will the transaction still be
propagated? IE can we always guarantee a path through the network for
either transaction type no matter what the combination of network
policies are?
> Does fullrbf offer any benefits other than breaking zeroconf
> business practices? If so, what are they?
I think AJ mentioned this earlier, but adding more configuration options
always increases code complexity, and with that, there is likely more
unforeseen bugs. However, there is a section of network participants
that rely on both types of transaction policy, so from my limited
view-point, it seems worth accommodating if possible.
Cheers,
-Yancy
On 2022-10-31 17:25, Greg Sanders via bitcoin-dev wrote:
> Thanks for your full thoughts Suhas,
>
> The idea of V3 is that we're currently leaving fees on the table by
> allowing use-cases to be pinned, not that we like Lightning and we
> think miners should stop being profit maximizing somehow to enable
> safer/better layer 2 systems.
>
> If someone wants to bump fees for V3 transactions(or replace them!),
> there's a much simpler "API" to do so than in legacy policy land. The
> fact that it disallows more idiotic ways to add more total fees means
> wallets "shouldn't do that". If it ends up that V3 is disallowing too
> many "natural" ways to fee bump, that's a strike against the V3 idea
> and should be discussed. For 0-conf services we have potential thieves
> who are willing to *out-bid themselves* to have funds come back to
> themselves. It's not a "legitimate" use-case, but a rational one.
>
> I have mostly come around to not pushing for fullrbf due to the issues
> you mentioned, except taking away the option. Removing a
> quite-likely-incentive-compatible option from the software just
> encourages miners to adopt an additional patch if they ever deem it
> necessary to increase their revenue, even if that revenue is from
> hurting 0-conf businesses.
>
> Maybe putting/leaving in a default-false flag for disabling these
> "carve outs" is the least bad option. V3 usage patterns shouldn't
> crumble if a large majority of miners opt out, but 0-conf use cases
> crumble after a small percentage of adoption.
>
> To recap my thoughts:
>
> 1) I have put away my fullrbf hats, I will not advocate anyone running
> it as I think it doesn't really do anything useful for users who
> aren't trying to double-spend merchants.
>
> 2) Forcing miners to honor fees left on the table with respect to
> 0-conf, or forcing them to run a custom patchset to go around it, is a
> step backwards.
>
> Greg
>
> On Mon, Oct 31, 2022 at 11:03 AM Suhas Daftuar via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> AJ,
>>
>> Thanks for the thoughtful post. I think your observations about how
>> we view mempool policy in the Bitcoin Core project, and how that
>> seems to be changing in the discussions around `-mempoolfullrbf`,
>> are on-point and provide a helpful baseline for considering future
>> policy changes.
>>
>> For a long time I viewed fullrbf as an eventuality and I considered
>> myself to be philosophically supportive of the idea. However, after
>> giving this issue some thought in the past few weeks, I am reversing
>> my thinking on this. Concretely, I will argue that we should
>> continue to maintain a relay policy where replacements are rejected
>> for transactions that don't opt-in to RBF (as described in BIP 125),
>> and moreover, that we should remove the `-mempoolfullrbf` flag from
>> Bitcoin Core's latest release candidate and not plan to release
>> software with that flag, unless (or until) circumstances change on
>> the network, which I'll discuss below.
>>
>> This is, of course, a nuanced topic, and among the considerations is
>> a philosophy of how to think about the relay policy and
>> configuration options that we make available in Bitcoin Core (a
>> consideration that is perhaps unique to that project, but I think
>> relevant for this mailing list).
>>
>> I'll start with some technical issues regarding the benefits of
>> enabling fullrbf on the network. In the current BIP 125 regime,
>> every time a transaction is created, a choice is made whether to
>> subject the transaction to BIP 125's RBF rules or not (based on
>> the sequence values of the inputs). So given that users can already
>> opt-in to RBF, the benefit of a "fullrbf" network policy would
>> be if, somehow, RBF users were still denied the benefits of RBF due
>> to the existence of other transactions that don't opt-in.
>>
>> Along those lines, Antoine Riard brought up[1] a DoS vector that is
>> available to someone who wants to interfere with multi-party funded
>> transactions, and suggested that fullrbf would eliminate the
>> problem. After exploring that question again in this thread (thanks
>> to Greg Sanders for clarifying this to me), I understand that the
>> issue is around ensuring that a multiparty (coinjoin-type) protocol
>> is able to make eventual progress, by having a candidate multiparty
>> transaction either eventually confirm or become conflicted with
>> something that has been confirmed, in which case the double-spend
>> information could be used to start a new coinjoin round with fewer
>> participants. The concern Antoine and Greg have brought up is that
>> non-rbf transactions can persist in the mempool ~indefinitely (at a
>> low feerate and not subject to replacement) and interfere with
>> progress being made in a coinjoin protocol.
>>
>> However, it seems to me that similar problems exist for such a
>> protocol even in a fullrbf world, as we understand that term today.
>> I mentioned the ability for rbf "pinning" to interfere with
>> relay of the multiparty transaction (even if the conflicting
>> transaction signals for RBF - a set of large but low feerate
>> conflicting transactions can persist in the mempool and make it
>> difficult for the coinjoin transaction from confirming, at least
>> without attaching a very large fee); and as Greg mentioned in a
>> followup, the BIP 125 rule to only permit 100 transactions to be
>> removed from the mempool at a time during a replacement can also be
>> used to pin a coinjoin protocol in the same way as a non-rbf
>> transaction today. It seems to me that what these multiparty
>> protocols actually need is some sort of "maximal rbf" network
>> policy: a way to guarantee that a transaction which should be
>> desirable for a miner to mine would always get to a miner and
>> considered for inclusion in a block, no matter what the state of
>> node's mempools on the network.
>>
>> While that sounds like a reasonable thing to want on its face (and
>> worth working on), it's not how opt-in RBF works today, nor is it
>> how transaction relay has ever conceptually worked. We have not,
>> thus far, been able to come up with a total ordering on transaction
>> desirability. Moreover, due to all the DoS issues that exist with
>> transaction relay, there are plenty of seemingly legitimate ways to
>> construct transactions that would not relay well on the network.
>> Relay has only ever been a best-efforts concept, where we carve out
>> a small subset of the entire transaction universe for which we try
>> to optimize propagation. The idea behind this approach is that if
>> every use case we can come up with has some way to achieve its goals
>> using transactions that should (eventually) be able to relay, then
>> users wouldn't have much demand for transactions that would
>> deviate from the supported policies, and we therefore shouldn't
>> need to worry too much about incentive compatibility concerns when
>> it comes to transaction types that wouldn't relay at all, even if
>> they are high feerate. (And when those situations arise where the
>> standard transactions do not accommodate some needed use case,
>> developers typically work to define a policy that is compatible with
>> our anti-DoS goals to support such use cases, such as with the
>> recent proposal for version=3 transactions [2].)
>>
>> BIP 125's RBF rules themselves were an effort to carve out just a
>> subset of situations where a transaction should evict conflicting
>> ones -- it was not a design that anyone thought would ensure that
>> all replacements which "should" be mined would always propagate.
>> And I don't believe that we know how to design policy rules that
>> would achieve the goals of this kind of multiparty protocol in a DoS
>> resistant way, today. Along those lines, I would point out that
>> even the BIP 125 design itself is not entirely incentive compatible,
>> in that it is possible to construct a replacement transaction that
>> would evict transactions which would be preferable to be included in
>> a block! [3] (This has been known for years, but fixing this has
>> proven difficult, and the only way to fix it that I'm aware of
>> would be to make BIP 125 RBF even more restrictive than it is today.
>> I do think this is something that needs to be worked on.)
>>
>> Given the limitations of RBF as we have it today, it appears to be
>> incorrect that a fullrbf network policy would solve the problems
>> Antoine raised. And so absent any other examples, it does not seem
>> to me that fullrbf solves any problems for RBF users, who are
>> already free to choose to subject their transactions to BIP 125's
>> RBF policy. From this perspective, "enabling fullrbf" is really
>> just taking away user choice to opt a transaction into a
>> non-replacement policy regime.
>>
>> I think we should ask, then, whether it is reasonable on its face
>> that users might want to opt-in to a non-replacement policy? Or in
>> other words, is it reasonable for a user to mark a transaction as
>> non-replaceable and have that indication be enforced by the network?
>> Note that these are two different questions: you could imagine a
>> world where fullrbf is a dominant policy, but users still use the
>> BIP 125 signaling method to indicate, in an unenforced way, their
>> intention to not replace a transaction. This might give useful
>> information to the network or the recipient for how to interact with
>> such a transaction.
>>
>> And I think that it's entirely possible that users would continue to
>> use the BIP 125 signaling to indicate that they do not intend to
>> replace a transaction. For better or worse, this might be because
>> zeroconf services continue to differentiate their behavior based on
>> such a signal (possibly in conjunction with other factors), or it
>> could be because there are other behaviors that could be utilized
>> more effectively if the transaction originator has made such a
>> signal, such as the recipient chaining an unconfirmed transaction as
>> a way to bump the fee (CPFP) [4].
>>
>> If it were to be the case that users continued to use BIP 125-style
>> signaling to indicate that they do not plan to replace a
>> transaction, would that be harmful to the network? This is not
>> something we can stop in our policy rules (short of censoring such
>> transactions, an obviously bad idea). I think network actors can
>> always do things that we might think are harmful for the network,
>> but that doesn't mean that there are no legitimate use cases for
>> the tools that such actors might be using. Just because someone
>> might use some policy to adopt a zeroconf model, doesn't mean that
>> others aren't using the same policy to achieve benign ends (such
>> as better CPFP behavior).
>>
>> Moreover, while users might attempt to exploit services that offer
>> zeroconf or other differentiated behavior to non-replacement
>> signaling transactions, they also might not -- I think predicting
>> user behavior in this way (and specifically predicting the
>> complexities of what a business might do and whether users might try
>> to subvert it) is beyond the scope of what we can do as protocol
>> developers. Instead, I think we can try to answer a different
>> question: if a group of users were to want the ability to opt-in to
>> a non-replacement policy regime, is that a technically sound option
>> for us to have on the network and enforce in software?
>> Specifically, does that interfere with having a sensible anti-DoS
>> mempool acceptance algorithm, or interfere with other protocols on
>> the network, or necessarily run counter to the interests of miners
>> or node operators?
>>
>> And I think the answer to that question, in looking at the
>> difference between opt-in RBF and fullrbf, is no: offering the
>> ability to opt-in to a non-replacement regime for transactions
>> doesn't introduce any fundamental issues with software or network
>> policy or other protocols. In a world where we only had fullrbf, I
>> could imagine at some point down the road proposing a
>> non-replacement signal myself, because the complexities around
>> transaction chains (and pinning) are more complex for the RBF case
>> than for the non-RBF case (and BIP 125 is not always incentive
>> compatible to begin with!). Conceptually, this is no different to
>> me than the version=3 transaction policy proposal that has been
>> advancing, if we think of it as a special set of restrictions on
>> transactions designed to accommodate a particular use case.
>>
>> Philosophically, I think we should be looking to add non-interfering
>> use cases to what the network supports.
>>
>> To those who argue for making fullrbf a default policy on the
>> network (or even just offering a flag for users to enable fullrbf),
>> I pose this hypothetical: suppose we deploy the v3 transaction
>> policy proposal (which I hope will happen in the near future). That
>> policy would restrict the ways that outputs of a v3 transaction can
>> be spent while the transaction is unconfirmed, including by limiting
>> the number and size of descendants that such a transaction can have,
>> and limiting the types of unconfirmed ancestors that can be
>> included. Suppose in a few years someone proposes that we add a
>> "-disable_v3_transaction_enforcement" flag to our software, to let
>> users decide to turn off those policy restrictions and treat v3
>> transactions the same as v2, for all the same reasons that could be
>> argued today with fullrbf: miners might earn more revenue if we
>> allowed multiple descendant v3 transactions; it's illogical for the
>> recipient of a v3 transaction to believe what is a fundamentally
>> unenforceable promise of a sender to not issue more high value
>> children that descend from an unconfirmed transaction; it's
>> inappropriate for Bitcoin Core to dictate policy on the network and
>> we should honor user choice to turn off that flag if that's what
>> users want; if users are relying on v3's policy restrictions for
>> security then that is an unstable model and we should assume it will
>> get broken[5].
>>
>> It's obvious to me that adding a flag to disable v3 policy would
>> be subversive to making the lightning use case for v3 transactions
>> work. And so my response to such a hypothetical proposal would be
>> to argue that no, we should not enable users to disable this policy,
>> because as long as that policy is just optional and working for
>> those who want it, it shouldn't harm anyone that we offer a
>> tighter set of rules for a particular use case. Adding a way to
>> bypass those rules is just trying to break someone else's use
>> case, not trying to add a new one. We should not wield "incentive
>> compatibility" as a bludgeon for breaking things that appear to be
>> working and not causing others harm.
>>
>> I think this is exactly what is happening with fullrbf.
>>
>> In comparing v3 transaction policy with opting out of transaction
>> replacement, there is of course one significant difference that I
>> have ignored thus far: I think the real difference is an opinion
>> about whether non-replacement transactions that are being used today
>> are, overall, bad for Bitcoin, and whether lightning's use of v3
>> transactions in the future would be bad for Bitcoin. If you think
>> that zeroconf is unequivocally bad, and that no one will be able to
>> plausibly construct a case that lightning is bad, then that
>> qualitative judgment might sway you to not worrying about the
>> philosophical issues I've raised above, because these situations can
>> be distinguished.
>>
>> However I am not personally willing to say that I think, overall,
>> non-rbf-signaling transactions in use on the network today are bad
>> for Bitcoin (or that fullrbf is definitely good - BIP 125's rbf
>> rules are something we've been trying to improve upon for years,
>> with little success). Nor am I convinced that someone couldn't
>> put together a cogent argument for lightning being bad for Bitcoin,
>> because of its reliance on relay policies that are difficult to
>> design and impossible to guarantee as part of its security model.
>> So I choose instead to merely make a judgment that seems more
>> factually verifiable, which is that non-replacement is a policy
>> widely in use on the network today, and we largely don't have reason
>> to think (as far as I know!) that the network is seeing a lot of
>> transactions that would violate that policy.
>>
>> If it did turn out that users were commonly signaling
>> non-replacement, but then signing and trying to relay doublespends,
>> then I think that would be a very good reason for Bitcoin Core to
>> adopt fullrbf to reflect the reality of what is happening. In the
>> meantime, I think it makes more sense to say that because we have
>> BIP 125, there seems to be no need for users to signal one way and
>> behave another, and therefore there is no need to offer software
>> that might break a policy that is working well for some users.
>> Other software projects might choose differently, and it is after
>> all a permissionless network, so if this is in fact an unstable
>> equilibrium that will not last, then presumably someday it will be
>> apparent it is not working and we'll abandon it. But I think the
>> philosophy of transaction relay policy in Bitcoin Core should be to
>> support disparate use cases in order to try to make everything work
>> better, rather than break things prematurely because we guess others
>> will break them eventually anyway.
>>
>> For those that have read this long email and still favor a fullrbf
>> network policy (or even just the ability for users to be able to
>> turn on fullrbf for themselves), I'd ask for thoughts on the
>> following questions, which have guided my thinking on this:
>>
>> Does fullrbf offer any benefits other than breaking zeroconf
>> business practices? If so, what are they?
>>
>> Is it reasonable to enforce BIP 125's rbf rules on all transactions,
>> if those rules themselves are not always incentive compatible?
>>
>> If someone were to propose a command line option that breaks v3
>> transaction relay in the future, is there a logical basis for
>> opposing that which is consistent with moving towards fullrbf now?
>>
>> Cheers,
>> Suhas
>>
>> [1]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
>
>> [2]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020937.html
>
>> [3] This is because under the BIP 125 rules, the feerate of the
>> replacement transaction is not compared to the individual feerates
>> of all transactions being evicted - we just compare feerates with
>> the transactions that are directly in conflict (and not their
>> descendants). So it's possible for a transaction that would evict
>> 2 or more transactions to have a higher feerate than the direct
>> conflicts, and higher total fee than the set being evicted, but have
>> a lower feerate (eg if it is larger) than that of some subset of the
>> set of transactions being evicted.
>>
>> [4] Chaining unconfirmed transactions when the sender might RBF the
>> parent is far riskier than if the sender indicates they don't plan
>> to do so (chaining onto an RBF transaction creates pinning issues
>> for the sender, and risks having the child wiped out if the parent
>> is replaced), so I think this is a concrete reason why signaling
>> that a transaction won't be replaced could be useful.
>>
>> [5] This is a subtle point. I don't think v3 transactions create
>> an unreasonable security assumption for the use case it is being
>> designed for. However, I don't think anyone could rule out the
>> possibility that someone could adopt a usage pattern for v3
>> transactions that subverts the intent of this policy. For example,
>> if users started using v3 transactions for all their payments, then
>> the limitations on the number of descendants could directly
>> interfere with CPFP by a recipient, and someone could argue that we
>> should break the policy in order to allow for this hypothetical
>> behavior. I think this is a similar form of argument as saying that
>> zeroconf practices + BIP 125 create an incentive to double-spend
>> non-rbf signaling transactions.
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--=_4372f650f906433ddfa64efff7ea1ba1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=
=3DUTF-8" /></head><body style=3D'font-size: 10pt; font-family: Verdana,Gen=
eva,sans-serif'>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
Protocol Devs,</div>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
</div>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
After reading through this email thread and BIP125, I'm curious if non-rbf =
nodes will relay full-rbf transactions and vice versa. That is to say=
, if only one non-rbf node exists on the network, however, every other node=
implements full-rbf, will the transaction still be propagated? IE ca=
n we always guarantee a path through the network for either transaction typ=
e no matter what the combination of network policies are?</div>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
</div>
<blockquote type=3D"cite" style=3D"padding: 0 0.4em; border-left: #1010ff 2=
px solid; margin: 0">
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
Does fullrbf offer any benefits other than breaking zeroconf<br />business =
practices? If so, what are they?</div>
</blockquote>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
</div>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
I think AJ mentioned this earlier, but adding more configuration options al=
ways increases code complexity, and with that, there is likely more unfores=
een bugs. However, there is a section of network participants that re=
ly on both types of transaction policy, so from my limited view-point, it s=
eems worth accommodating if possible.</div>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
</div>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
Cheers,</div>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
-Yancy</div>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
</div>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
On 2022-10-31 17:25, Greg Sanders via bitcoin-dev wrote:
<blockquote type=3D"cite" style=3D"padding: 0 0.4em; border-left: #1010ff 2=
px solid; margin: 0">Thanks for your full thoughts Suhas,<br /><br />The id=
ea of V3 is that we're currently leaving fees on the table by<br />allowing=
use-cases to be pinned, not that we like Lightning and we<br />think miner=
s should stop being profit maximizing somehow to enable<br />safer/better l=
ayer 2 systems.<br /><br />If someone wants to bump fees for V3 transaction=
s(or replace them!),<br />there's a much simpler "API" to do so than in leg=
acy policy land. The<br />fact that it disallows more idiotic ways to add m=
ore total fees means<br />wallets "shouldn't do that". If it ends up that V=
3 is disallowing too<br />many "natural" ways to fee bump, that's a strike =
against the V3 idea<br />and should be discussed. For 0-conf services we ha=
ve potential thieves<br />who are willing to *out-bid themselves* to have f=
unds come back to<br />themselves. It's not a "legitimate" use-case, but a =
rational one.<br /><br />I have mostly come around to not pushing for fullr=
bf due to the issues<br />you mentioned, except taking away the option. Rem=
oving a<br />quite-likely-incentive-compatible option from the software jus=
t<br />encourages miners to adopt an additional patch if they ever deem it<=
br />necessary to increase their revenue, even if that revenue is from<br /=
>hurting 0-conf businesses.<br /><br />Maybe putting/leaving in a default-f=
alse flag for disabling these<br />"carve outs" is the least bad option. V3=
usage patterns shouldn't<br />crumble if a large majority of miners opt ou=
t, but 0-conf use cases<br />crumble after a small percentage of adoption.<=
br /><br />To recap my thoughts:<br /><br />1) I have put away my fullrbf h=
ats, I will not advocate anyone running<br />it as I think it doesn't reall=
y do anything useful for users who<br />aren't trying to double-spend merch=
ants.<br /><br />2) Forcing miners to honor fees left on the table with res=
pect to<br />0-conf, or forcing them to run a custom patchset to go around =
it, is a<br />step backwards.<br /><br />Greg<br /><br />On Mon, Oct 31, 20=
22 at 11:03 AM Suhas Daftuar via bitcoin-dev<br /><<a href=3D"mailto:bit=
coin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</=
a>> wrote:<br /><br />
<blockquote type=3D"cite" style=3D"padding: 0 0.4em; border-left: #1010ff 2=
px solid; margin: 0">AJ,<br /><br />Thanks for the thoughtful post. I think=
your observations about how<br />we view mempool policy in the Bitcoin Cor=
e project, and how that<br />seems to be changing in the discussions around=
`-mempoolfullrbf`,<br />are on-point and provide a helpful baseline for co=
nsidering future<br />policy changes.<br /><br />For a long time I viewed f=
ullrbf as an eventuality and I considered<br />myself to be philosophically=
supportive of the idea. However, after<br />giving this issue some t=
hought in the past few weeks, I am reversing<br />my thinking on this. &nbs=
p;Concretely, I will argue that we should<br />continue to maintain a relay=
policy where replacements are rejected<br />for transactions that don't op=
t-in to RBF (as described in BIP 125),<br />and moreover, that we should re=
move the `-mempoolfullrbf` flag from<br />Bitcoin Core’s latest relea=
se candidate and not plan to release<br />software with that flag, unless (=
or until) circumstances change on<br />the network, which I'll discuss belo=
w.<br /><br />This is, of course, a nuanced topic, and among the considerat=
ions is<br />a philosophy of how to think about the relay policy and<br />c=
onfiguration options that we make available in Bitcoin Core (a<br />conside=
ration that is perhaps unique to that project, but I think<br />relevant fo=
r this mailing list).<br /><br />I'll start with some technical issues rega=
rding the benefits of<br />enabling fullrbf on the network. In the cu=
rrent BIP 125 regime,<br />every time a transaction is created, a choice is=
made whether to<br />subject the transaction to BIP 125’s RBF rules =
or not (based on<br />the sequence values of the inputs). So given th=
at users can already<br />opt-in to RBF, the benefit of a “fullrbf&rd=
quo; network policy would<br />be if, somehow, RBF users were still denied =
the benefits of RBF due<br />to the existence of other transactions that do=
n’t opt-in.<br /><br />Along those lines, Antoine Riard brought up[1]=
a DoS vector that is<br />available to someone who wants to interfere with=
multi-party funded<br />transactions, and suggested that fullrbf would eli=
minate the<br />problem. After exploring that question again in this =
thread (thanks<br />to Greg Sanders for clarifying this to me), I understan=
d that the<br />issue is around ensuring that a multiparty (coinjoin-type) =
protocol<br />is able to make eventual progress, by having a candidate mult=
iparty<br />transaction either eventually confirm or become conflicted with=
<br />something that has been confirmed, in which case the double-spend<br =
/>information could be used to start a new coinjoin round with fewer<br />p=
articipants. The concern Antoine and Greg have brought up is that<br =
/>non-rbf transactions can persist in the mempool ~indefinitely (at a<br />=
low feerate and not subject to replacement) and interfere with<br />progres=
s being made in a coinjoin protocol.<br /><br />However, it seems to me tha=
t similar problems exist for such a<br />protocol even in a fullrbf world, =
as we understand that term today.<br />I mentioned the ability for rbf &ldq=
uo;pinning” to interfere with<br />relay of the multiparty transactio=
n (even if the conflicting<br />transaction signals for RBF – a set o=
f large but low feerate<br />conflicting transactions can persist in the me=
mpool and make it<br />difficult for the coinjoin transaction from confirmi=
ng, at least<br />without attaching a very large fee); and as Greg mentione=
d in a<br />followup, the BIP 125 rule to only permit 100 transactions to b=
e<br />removed from the mempool at a time during a replacement can also be<=
br />used to pin a coinjoin protocol in the same way as a non-rbf<br />tran=
saction today. It seems to me that what these multiparty<br />protoco=
ls actually need is some sort of "maximal rbf" network<br />policy: a way t=
o guarantee that a transaction which should be<br />desirable for a miner t=
o mine would always get to a miner and<br />considered for inclusion in a b=
lock, no matter what the state of<br />node’s mempools on the network=
=2E<br /><br />While that sounds like a reasonable thing to want on its fac=
e (and<br />worth working on), it's not how opt-in RBF works today, nor is =
it<br />how transaction relay has ever conceptually worked. We have n=
ot,<br />thus far, been able to come up with a total ordering on transactio=
n<br />desirability. Moreover, due to all the DoS issues that exist w=
ith<br />transaction relay, there are plenty of seemingly legitimate ways t=
o<br />construct transactions that would not relay well on the network.<br =
/>Relay has only ever been a best-efforts concept, where we carve out<br />=
a small subset of the entire transaction universe for which we try<br />to =
optimize propagation. The idea behind this approach is that if<br />e=
very use case we can come up with has some way to achieve its goals<br />us=
ing transactions that should (eventually) be able to relay, then<br />users=
wouldn’t have much demand for transactions that would<br />deviate f=
rom the supported policies, and we therefore shouldn’t<br />need to w=
orry too much about incentive compatibility concerns when<br />it comes to =
transaction types that wouldn’t relay at all, even if<br />they are h=
igh feerate. (And when those situations arise where the<br />standard=
transactions do not accommodate some needed use case,<br />developers typi=
cally work to define a policy that is compatible with<br />our anti-DoS goa=
ls to support such use cases, such as with the<br />recent proposal for ver=
sion=3D3 transactions [2].)<br /><br />BIP 125's RBF rules themselves were =
an effort to carve out just a<br />subset of situations where a transaction=
should evict conflicting<br />ones -- it was not a design that anyone thou=
ght would ensure that<br />all replacements which "should" be mined would a=
lways propagate.<br />And I don't believe that we know how to design policy=
rules that<br />would achieve the goals of this kind of multiparty protoco=
l in a DoS<br />resistant way, today. Along those lines, I would poin=
t out that<br />even the BIP 125 design itself is not entirely incentive co=
mpatible,<br />in that it is possible to construct a replacement transactio=
n that<br />would evict transactions which would be preferable to be includ=
ed in<br />a block! [3] (This has been known for years, but fixing th=
is has<br />proven difficult, and the only way to fix it that I’m awa=
re of<br />would be to make BIP 125 RBF even more restrictive than it is to=
day.<br />I do think this is something that needs to be worked on.)<br /><b=
r />Given the limitations of RBF as we have it today, it appears to be<br /=
>incorrect that a fullrbf network policy would solve the problems<br />Anto=
ine raised. And so absent any other examples, it does not seem<br />t=
o me that fullrbf solves any problems for RBF users, who are<br />already f=
ree to choose to subject their transactions to BIP 125’s<br />RBF pol=
icy. From this perspective, "enabling fullrbf" is really<br />just ta=
king away user choice to opt a transaction into a<br />non-replacement poli=
cy regime.<br /><br />I think we should ask, then, whether it is reasonable=
on its face<br />that users might want to opt-in to a non-replacement poli=
cy? Or in<br />other words, is it reasonable for a user to mark a tra=
nsaction as<br />non-replaceable and have that indication be enforced by th=
e network?<br />Note that these are two different questions: you could imag=
ine a<br />world where fullrbf is a dominant policy, but users still use th=
e<br />BIP 125 signaling method to indicate, in an unenforced way, their<br=
/>intention to not replace a transaction. This might give useful<br =
/>information to the network or the recipient for how to interact with<br /=
>such a transaction.<br /><br />And I think that it's entirely possible tha=
t users would continue to<br />use the BIP 125 signaling to indicate that t=
hey do not intend to<br />replace a transaction. For better or worse,=
this might be because<br />zeroconf services continue to differentiate the=
ir behavior based on<br />such a signal (possibly in conjunction with other=
factors), or it<br />could be because there are other behaviors that could=
be utilized<br />more effectively if the transaction originator has made s=
uch a<br />signal, such as the recipient chaining an unconfirmed transactio=
n as<br />a way to bump the fee (CPFP) [4].<br /><br />If it were to be the=
case that users continued to use BIP 125-style<br />signaling to indicate =
that they do not plan to replace a<br />transaction, would that be harmful =
to the network? This is not<br />something we can stop in our policy =
rules (short of censoring such<br />transactions, an obviously bad idea). &=
nbsp;I think network actors can<br />always do things that we might think a=
re harmful for the network,<br />but that doesn’t mean that there are=
no legitimate use cases for<br />the tools that such actors might be using=
=2E Just because someone<br />might use some policy to adopt a zeroco=
nf model, doesn’t mean that<br />others aren’t using the same p=
olicy to achieve benign ends (such<br />as better CPFP behavior).<br /><br =
/>Moreover, while users might attempt to exploit services that offer<br />z=
eroconf or other differentiated behavior to non-replacement<br />signaling =
transactions, they also might not -- I think predicting<br />user behavior =
in this way (and specifically predicting the<br />complexities of what a bu=
siness might do and whether users might try<br />to subvert it) is beyond t=
he scope of what we can do as protocol<br />developers. Instead, I th=
ink we can try to answer a different<br />question: if a group of users wer=
e to want the ability to opt-in to<br />a non-replacement policy regime, is=
that a technically sound option<br />for us to have on the network and enf=
orce in software?<br />Specifically, does that interfere with having a sens=
ible anti-DoS<br />mempool acceptance algorithm, or interfere with other pr=
otocols on<br />the network, or necessarily run counter to the interests of=
miners<br />or node operators?<br /><br />And I think the answer to that q=
uestion, in looking at the<br />difference between opt-in RBF and fullrbf, =
is no: offering the<br />ability to opt-in to a non-replacement regime for =
transactions<br />doesn't introduce any fundamental issues with software or=
network<br />policy or other protocols. In a world where we only had=
fullrbf, I<br />could imagine at some point down the road proposing a<br /=
>non-replacement signal myself, because the complexities around<br />transa=
ction chains (and pinning) are more complex for the RBF case<br />than for =
the non-RBF case (and BIP 125 is not always incentive<br />compatible to be=
gin with!). Conceptually, this is no different to<br />me than the ve=
rsion=3D3 transaction policy proposal that has been<br />advancing, if we t=
hink of it as a special set of restrictions on<br />transactions designed t=
o accommodate a particular use case.<br /><br />Philosophically, I think we=
should be looking to add non-interfering<br />use cases to what the networ=
k supports.<br /><br />To those who argue for making fullrbf a default poli=
cy on the<br />network (or even just offering a flag for users to enable fu=
llrbf),<br />I pose this hypothetical: suppose we deploy the v3 transaction=
<br />policy proposal (which I hope will happen in the near future). =
That<br />policy would restrict the ways that outputs of a v3 transaction c=
an<br />be spent while the transaction is unconfirmed, including by limitin=
g<br />the number and size of descendants that such a transaction can have,=
<br />and limiting the types of unconfirmed ancestors that can be<br />incl=
uded. Suppose in a few years someone proposes that we add a<br />"-di=
sable_v3_transaction_enforcement" flag to our software, to let<br />users d=
ecide to turn off those policy restrictions and treat v3<br />transactions =
the same as v2, for all the same reasons that could be<br />argued today wi=
th fullrbf: miners might earn more revenue if we<br />allowed multiple desc=
endant v3 transactions; it's illogical for the<br />recipient of a v3 trans=
action to believe what is a fundamentally<br />unenforceable promise of a s=
ender to not issue more high value<br />children that descend from an uncon=
firmed transaction; it's<br />inappropriate for Bitcoin Core to dictate pol=
icy on the network and<br />we should honor user choice to turn off that fl=
ag if that’s what<br />users want; if users are relying on v3’s=
policy restrictions for<br />security then that is an unstable model and w=
e should assume it will<br />get broken[5].<br /><br />It’s obvious t=
o me that adding a flag to disable v3 policy would<br />be subversive to ma=
king the lightning use case for v3 transactions<br />work. And so my =
response to such a hypothetical proposal would be<br />to argue that no, we=
should not enable users to disable this policy,<br />because as long as th=
at policy is just optional and working for<br />those who want it, it shoul=
dn’t harm anyone that we offer a<br />tighter set of rules for a part=
icular use case. Adding a way to<br />bypass those rules is just tryi=
ng to break someone else’s use<br />case, not trying to add a new one=
=2E We should not wield "incentive<br />compatibility" as a bludgeon =
for breaking things that appear to be<br />working and not causing others h=
arm.<br /><br />I think this is exactly what is happening with fullrbf.<br =
/><br />In comparing v3 transaction policy with opting out of transaction<b=
r />replacement, there is of course one significant difference that I<br />=
have ignored thus far: I think the real difference is an opinion<br />about=
whether non-replacement transactions that are being used today<br />are, o=
verall, bad for Bitcoin, and whether lightning’s use of v3<br />trans=
actions in the future would be bad for Bitcoin. If you think<br />that zero=
conf is unequivocally bad, and that no one will be able to<br />plausibly c=
onstruct a case that lightning is bad, then that<br />qualitative judgment =
might sway you to not worrying about the<br />philosophical issues I've rai=
sed above, because these situations can<br />be distinguished.<br /><br />H=
owever I am not personally willing to say that I think, overall,<br />non-r=
bf-signaling transactions in use on the network today are bad<br />for Bitc=
oin (or that fullrbf is definitely good – BIP 125’s rbf<br />ru=
les are something we’ve been trying to improve upon for years,<br />w=
ith little success). Nor am I convinced that someone couldn’t<b=
r />put together a cogent argument for lightning being bad for Bitcoin,<br =
/>because of its reliance on relay policies that are difficult to<br />desi=
gn and impossible to guarantee as part of its security model.<br />So I cho=
ose instead to merely make a judgment that seems more<br />factually verifi=
able, which is that non-replacement is a policy<br />widely in use on the n=
etwork today, and we largely don't have reason<br />to think (as far as I k=
now!) that the network is seeing a lot of<br />transactions that would viol=
ate that policy.<br /><br />If it did turn out that users were commonly sig=
naling<br />non-replacement, but then signing and trying to relay doublespe=
nds,<br />then I think that would be a very good reason for Bitcoin Core to=
<br />adopt fullrbf to reflect the reality of what is happening. In t=
he<br />meantime, I think it makes more sense to say that because we have<b=
r />BIP 125, there seems to be no need for users to signal one way and<br /=
>behave another, and therefore there is no need to offer software<br />that=
might break a policy that is working well for some users.<br />Other softw=
are projects might choose differently, and it is after<br />all a permissio=
nless network, so if this is in fact an unstable<br />equilibrium that will=
not last, then presumably someday it will be<br />apparent it is not worki=
ng and we’ll abandon it. But I think the<br />philosophy of tra=
nsaction relay policy in Bitcoin Core should be to<br />support disparate u=
se cases in order to try to make everything work<br />better, rather than b=
reak things prematurely because we guess others<br />will break them eventu=
ally anyway.<br /><br />For those that have read this long email and still =
favor a fullrbf<br />network policy (or even just the ability for users to =
be able to<br />turn on fullrbf for themselves), I’d ask for thoughts=
on the<br />following questions, which have guided my thinking on this:<br=
/><br />Does fullrbf offer any benefits other than breaking zeroconf<br />=
business practices? If so, what are they?<br /><br />Is it reasonable=
to enforce BIP 125's rbf rules on all transactions,<br />if those rules th=
emselves are not always incentive compatible?<br /><br />If someone were to=
propose a command line option that breaks v3<br />transaction relay in the=
future, is there a logical basis for<br />opposing that which is consisten=
t with moving towards fullrbf now?<br /><br />Cheers,<br />Suhas<br /><br /=
>[1]<br /><br /></blockquote>
<a href=3D"https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-M=
ay/003033.html" target=3D"_blank" rel=3D"noopener noreferrer">https://lists=
=2Elinuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html</a>
<blockquote type=3D"cite" style=3D"padding: 0 0.4em; border-left: #1010ff 2=
px solid; margin: 0"><br />[2]<br /><br /></blockquote>
<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-Sep=
tember/020937.html" target=3D"_blank" rel=3D"noopener noreferrer">https://l=
ists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020937.html</=
a>
<blockquote type=3D"cite" style=3D"padding: 0 0.4em; border-left: #1010ff 2=
px solid; margin: 0"><br />[3] This is because under the BIP 125 rules, the=
feerate of the<br />replacement transaction is not compared to the individ=
ual feerates<br />of all transactions being evicted – we just compare=
feerates with<br />the transactions that are directly in conflict (and not=
their<br />descendants). So it’s possible for a transaction that wou=
ld evict<br />2 or more transactions to have a higher feerate than the dire=
ct<br />conflicts, and higher total fee than the set being evicted, but hav=
e<br />a lower feerate (eg if it is larger) than that of some subset of the=
<br />set of transactions being evicted.<br /><br />[4] Chaining unco=
nfirmed transactions when the sender might RBF the<br />parent is far riski=
er than if the sender indicates they don't plan<br />to do so (chaining ont=
o an RBF transaction creates pinning issues<br />for the sender, and risks =
having the child wiped out if the parent<br />is replaced), so I think this=
is a concrete reason why signaling<br />that a transaction won’t be =
replaced could be useful.<br /><br />[5] This is a subtle point. I don&rsqu=
o;t think v3 transactions create<br />an unreasonable security assumption f=
or the use case it is being<br />designed for. However, I don’t think=
anyone could rule out the<br />possibility that someone could adopt a usag=
e pattern for v3<br />transactions that subverts the intent of this policy.=
For example,<br />if users started using v3 transactions for all the=
ir payments, then<br />the limitations on the number of descendants could d=
irectly<br />interfere with CPFP by a recipient, and someone could argue th=
at we<br />should break the policy in order to allow for this hypothetical<=
br />behavior. I think this is a similar form of argument as saying that<br=
/>zeroconf practices + BIP 125 create an incentive to double-spend<br />no=
n-rbf signaling transactions.<br />________________________________________=
_______<br />bitcoin-dev mailing list<br /><a href=3D"mailto:bitcoin-dev@li=
sts.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a><br /><a =
href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" tar=
get=3D"_blank" rel=3D"noopener noreferrer">https://lists.linuxfoundation.or=
g/mailman/listinfo/bitcoin-dev</a></blockquote>
_______________________________________________<br />bitcoin-dev mailing li=
st<br /><a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-de=
v@lists.linuxfoundation.org</a><br /><a href=3D"https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev" target=3D"_blank" rel=3D"noopener nore=
ferrer">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><=
/blockquote>
</div>
</body></html>
--=_4372f650f906433ddfa64efff7ea1ba1--
|