Re: [bitcoin-dev] On mempool policy consistency

From: email@yancy•lol
To: Greg Sanders <gsanders87@gmail•com>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] On mempool policy consistency
Date: Mon, 31 Oct 2022 18:21:08 +0100	[thread overview]
Message-ID: <23dac89d36c356b9266db07e09c2de8e@yancy.lol> (raw)
In-Reply-To: <CAB3F3Dt=2hDXXw6Jz9QwnotkNLyGdZn9GZLHFXu0Dnyz3tsc0w@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 21618 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 25152 bytes --]