path: root/49/7520db1b840b9969d5dcbf9913ac9602bfd02f

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">=
&nbsp;</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.&nbsp; 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?&nbsp; 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">=
&nbsp;</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? &nbsp;If so, what are they?</div>
</blockquote>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
&nbsp;</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.&nbsp; 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">=
&nbsp;</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">=
&nbsp;</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 />&lt;<a href=3D"mailto:bit=
coin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</=
a>&gt; 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. &nbsp;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&rsquo;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. &nbsp;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&rsquo;s RBF rules =
or not (based on<br />the sequence values of the inputs). &nbsp;So given th=
at users can already<br />opt-in to RBF, the benefit of a &ldquo;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&rsquo;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. &nbsp;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. &nbsp;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&rdquo; to interfere with<br />relay of the multiparty transactio=
n (even if the conflicting<br />transaction signals for RBF &ndash; 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. &nbsp;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&rsquo;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. &nbsp;We have n=
ot,<br />thus far, been able to come up with a total ordering on transactio=
n<br />desirability. &nbsp;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. &nbsp;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&rsquo;t have much demand for transactions that would<br />deviate f=
rom the supported policies, and we therefore shouldn&rsquo;t<br />need to w=
orry too much about incentive compatibility concerns when<br />it comes to =
transaction types that wouldn&rsquo;t relay at all, even if<br />they are h=
igh feerate. &nbsp;(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. &nbsp;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] &nbsp;(This has been known for years, but fixing th=
is has<br />proven difficult, and the only way to fix it that I&rsquo;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. &nbsp;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&rsquo;s<br />RBF pol=
icy. &nbsp;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? &nbsp;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. &nbsp;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. &nbsp;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? &nbsp;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&rsquo;t mean that there are=
 no legitimate use cases for<br />the tools that such actors might be using=
=2E &nbsp;Just because someone<br />might use some policy to adopt a zeroco=
nf model, doesn&rsquo;t mean that<br />others aren&rsquo;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. &nbsp;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. &nbsp;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!). &nbsp;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). &nbsp;=
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. &nbsp;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&rsquo;s what<br />users want; if users are relying on v3&rsquo;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&rsquo;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. &nbsp;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&rsquo;t harm anyone that we offer a<br />tighter set of rules for a part=
icular use case. &nbsp;Adding a way to<br />bypass those rules is just tryi=
ng to break someone else&rsquo;s use<br />case, not trying to add a new one=
=2E &nbsp;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&rsquo;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 &ndash; BIP 125&rsquo;s rbf<br />ru=
les are something we&rsquo;ve been trying to improve upon for years,<br />w=
ith little success). &nbsp;Nor am I convinced that someone couldn&rsquo;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. &nbsp;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&rsquo;ll abandon it. &nbsp;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&rsquo;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? &nbsp;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 &ndash; we just compare=
 feerates with<br />the transactions that are directly in conflict (and not=
 their<br />descendants). So it&rsquo;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] &nbsp;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&rsquo;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&rsquo;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.=
 &nbsp;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--