path: root/c5/b1d6e2af99bf9ae50c426cdf4ecf460731e8c3

Return-Path: <sdaftuar@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 80FC3C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 31 Oct 2022 15:02:22 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 4746C40493
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 31 Oct 2022 15:02:22 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 4746C40493
Authentication-Results: smtp2.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=TIKl/WeP
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 7J5aWSbU22lz
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 31 Oct 2022 15:02:19 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 6D69240414
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com
 [IPv6:2a00:1450:4864:20::535])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 6D69240414
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 31 Oct 2022 15:02:19 +0000 (UTC)
Received: by mail-ed1-x535.google.com with SMTP id r14so17856974edc.7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 31 Oct 2022 08:02:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :from:to:cc:subject:date:message-id:reply-to;
 bh=6Y+Aw7A9Dgq33O0hMRGS9yMtae9QCLsXdubg1huegEw=;
 b=TIKl/WePPwYRbu21IWffaLIcd4NARpP8FR4goTbmvGXSscEkC44JvuV5EY0t1alD36
 ydR3WAudxbj2fPAXfkF9zAdOXJ3HqmjlKp7rhFHdUh38xWIqYJbsVFk5ogrUKww9Sx5C
 KyTUW+WF6zeLxMZkfQp1SlIF0f4tLFqkrkWhShmSUCcGX/HM9gsw8lxISi/KCZltKeS3
 kUM/p0Q+BpQ8j7lu7PXGCXk+MqxxSUf1MWUo/Y0Lo5XJ320VfFGB7E8uCYWsCSGI5Jbm
 tLBpJHKB+DnDwTfbxekW8ldIGhAoI3jfMcBLZcwrfEpebVxX36sWT/jK31aYoWZZQ2hw
 7tHw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
 bh=6Y+Aw7A9Dgq33O0hMRGS9yMtae9QCLsXdubg1huegEw=;
 b=vwoCacLgLYZgAfwtjq42zBi4jQJ8VxbSVQyVCNzuTykf7sieDEDxkoxX1UFmi/JByL
 MAjtWA5mxmUfQ46lQBAh+XEGIwQfM6jHk1QHbPaQZkb4MRgbOhlvGreDLRPGclaSIqQg
 LsMvUTQFmCc9ffAxFHhHQIZeypzBOD74LdcWsQ1+PUN2NpijS4wxsEsNpw8kaP/fUWbB
 NwseyNo5IbADFKm5QebsWsghNLIM3GHbN4jt65qvBdQSXIaQhtwcS7BmuY4FT1naV2Hr
 f+aGIjtppykG3rXnIJ9OEeElG+to06KSMudyQ2obJJ+veBkhYzRF+GaGI8mrGpxSGi4r
 iZtA==
X-Gm-Message-State: ACrzQf1X7nq4+zdQs+ViJ6Nhm+4Jry944awEpMX/97p3N+oDLkcpuB9x
 JB+Lfi6zZmDSrRBJ03EyKNORHNUXQMiDuRGD10x/4F+2vQ8=
X-Google-Smtp-Source: AMsMyM52WxGuZIQqapDcQ6eIVzXadqgVDULTKFvCqIedwjcg0ZXp2NlaTKau3pmmoMGjfhGBOZBOjJkZ6hgKs2+HogE=
X-Received: by 2002:a2e:a106:0:b0:277:3d6:a751 with SMTP id
 s6-20020a2ea106000000b0027703d6a751mr5349659ljl.201.1667221334215; Mon, 31
 Oct 2022 06:02:14 -0700 (PDT)
MIME-Version: 1.0
References: <Y1nIKjQC3DkiSGyw@erisian.com.au>
In-Reply-To: <Y1nIKjQC3DkiSGyw@erisian.com.au>
From: Suhas Daftuar <sdaftuar@gmail.com>
Date: Mon, 31 Oct 2022 09:02:02 -0400
Message-ID: <CAFp6fsFm06J2G1=3ojQvcL9gbEbQ41C4rmf3=Jkm9Qm0VBhhKw@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000063503505ec5437a1"
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 15:02:22 -0000

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

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=E2=80=99s 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=E2=80=99s 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
=E2=80=9Cfullrbf=E2=80=9D network policy would be if, somehow, RBF users we=
re still denied
the benefits of RBF due to the existence of other transactions that don=E2=
=80=99t
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 =E2=80=9Cpinning=E2=80=9D to interfere with relay of the mu=
ltiparty
transaction (even if the conflicting transaction signals for RBF =E2=80=93 =
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=E2=80=
=99s
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=E2=80=99t have much demand for transactions that would deviate=
 from
the supported policies, and we therefore shouldn=E2=80=99t need to worry to=
o much
about incentive compatibility concerns when it comes to transaction types
that wouldn=E2=80=99t relay at all, even if they are high feerate.  (And wh=
en 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=3D3 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=E2=80=99m 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=E2=80=99s 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=E2=80=99t mean that there are no le=
gitimate
use cases for the tools that such actors might be using.  Just because
someone might use some policy to adopt a zeroconf model, doesn=E2=80=99t me=
an that
others aren=E2=80=99t 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=3D3
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=E2=80=99s what users want; if users are relying on v3=E2=80=99s pol=
icy restrictions
for security then that is an unstable model and we should assume it will
get broken[5].

It=E2=80=99s 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=E2=80=
=99t
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=E2=80=99s 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=E2=80=99s 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 =E2=80=93 BIP 125=E2=80=99s rbf=
 rules are
something we=E2=80=99ve been trying to improve upon for years, with little
success).  Nor am I convinced that someone couldn=E2=80=99t 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=E2=80=99ll abandon it.  But I think the philosophy of transa=
ction
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=E2=80=99d ask for thoughts on the following questions, w=
hich
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.h=
tml

[2]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/0209=
37.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 =E2=80=93 we just compare feerates with the transactions that=
 are
directly in conflict (and not their descendants). So it=E2=80=99s 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=E2=80=99t be
replaced could be useful.

[5] This is a subtle point. I don=E2=80=99t think v3 transactions create an
unreasonable security assumption for the use case it is being designed for.
However, I don=E2=80=99t think anyone could rule out the possibility that s=
omeone
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.

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

<div dir=3D"ltr"><div dir=3D"ltr">AJ,<br><br>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 consider=
ing future policy changes.<br><br>For a long time I viewed fullrbf as an ev=
entuality and I considered myself to be philosophically supportive of the i=
dea.=C2=A0 However, after giving this issue some thought in the past few we=
eks, I am reversing my thinking on this.=C2=A0 Concretely, I will argue tha=
t we should continue to maintain a relay policy where replacements are reje=
cted for transactions that don&#39;t opt-in to RBF (as described in BIP 125=
), and moreover, that we should remove the `-mempoolfullrbf` flag from Bitc=
oin Core=E2=80=99s latest release candidate and not plan to release softwar=
e with that flag, unless (or until) circumstances change on the network, wh=
ich I&#39;ll discuss below.<br><br>This is, of course, a nuanced topic, and=
 among the considerations is a philosophy of how to think about the relay p=
olicy and configuration options that we make available in Bitcoin Core (a c=
onsideration that is perhaps unique to that project, but I think relevant f=
or this mailing list).<br><br>I&#39;ll start with some technical issues reg=
arding the benefits of enabling fullrbf on the network.=C2=A0 In the curren=
t BIP 125 regime, every time a transaction is created, a choice is made whe=
ther to subject the transaction to BIP 125=E2=80=99s RBF rules or not (base=
d on the sequence values of the inputs).=C2=A0 So given that users can alre=
ady opt-in to RBF, the benefit of a =E2=80=9Cfullrbf=E2=80=9D network polic=
y would be if, somehow, RBF users were still denied the benefits of RBF due=
 to the existence of other transactions that don=E2=80=99t opt-in.<br><br>A=
long those lines, Antoine Riard brought up[1] a DoS vector that is availabl=
e to someone who wants to interfere with multi-party funded transactions, a=
nd suggested that fullrbf would eliminate the problem.=C2=A0 After explorin=
g 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 multipa=
rty (coinjoin-type) protocol is able to make eventual progress, by having a=
 candidate multiparty transaction either eventually confirm or become confl=
icted with something that has been confirmed, in which case the double-spen=
d information could be used to start a new coinjoin round with fewer partic=
ipants.=C2=A0 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 co=
injoin protocol.<br><br>However, it seems to me that similar problems exist=
 for such a protocol even in a fullrbf world, as we understand that term to=
day.=C2=A0 I mentioned the ability for rbf =E2=80=9Cpinning=E2=80=9D to int=
erfere with relay of the multiparty transaction (even if the conflicting tr=
ansaction signals for RBF =E2=80=93 a set of large but low feerate conflict=
ing transactions can persist in the mempool and make it difficult for the c=
oinjoin transaction from confirming, at least without attaching a very larg=
e fee); and as Greg mentioned in a followup, the BIP 125 rule to only permi=
t 100 transactions to be removed from the mempool at a time during a replac=
ement can also be used to pin a coinjoin protocol in the same way as a non-=
rbf transaction today.=C2=A0 It seems to me that what these multiparty prot=
ocols actually need is some sort of &quot;maximal rbf&quot; network policy:=
 a way to guarantee that a transaction which should be desirable for a mine=
r to mine would always get to a miner and considered for inclusion in a blo=
ck, no matter what the state of node=E2=80=99s mempools on the network.<br>=
<br>While that sounds like a reasonable thing to want on its face (and wort=
h working on), it&#39;s not how opt-in RBF works today, nor is it how trans=
action relay has ever conceptually worked.=C2=A0 We have not, thus far, bee=
n able to come up with a total ordering on transaction desirability.=C2=A0 =
Moreover, due to all the DoS issues that exist with transaction relay, ther=
e are plenty of seemingly legitimate ways to construct transactions that wo=
uld not relay well on the network.=C2=A0 Relay has only ever been a best-ef=
forts concept, where we carve out a small subset of the entire transaction =
universe for which we try to optimize propagation.=C2=A0 The idea behind th=
is approach is that if every use case we can come up with has some way to a=
chieve its goals using transactions that should (eventually) be able to rel=
ay, then users wouldn=E2=80=99t have much demand for transactions that woul=
d deviate from the supported policies, and we therefore shouldn=E2=80=99t n=
eed to worry too much about incentive compatibility concerns when it comes =
to transaction types that wouldn=E2=80=99t relay at all, even if they are h=
igh feerate. =C2=A0(And when those situations arise where the standard tran=
sactions do not accommodate some needed use case, developers typically work=
 to define a policy that is compatible with our anti-DoS goals to support s=
uch use cases, such as with the recent proposal for version=3D3 transaction=
s [2].)<br><br>BIP 125&#39;s RBF rules themselves were an effort to carve o=
ut just a subset of situations where a transaction should evict conflicting=
 ones -- it was not a design that anyone thought would ensure that all repl=
acements which &quot;should&quot; be mined would always propagate.=C2=A0 An=
d I don&#39;t believe that we know how to design policy rules that would ac=
hieve the goals of this kind of multiparty protocol in a DoS resistant way,=
 today.=C2=A0 Along those lines, I would point out that even the BIP 125 de=
sign itself is not entirely incentive compatible, in that it is possible to=
 construct a replacement transaction that would evict transactions which wo=
uld be preferable to be included in a block! [3] =C2=A0(This has been known=
 for years, but fixing this has proven difficult, and the only way to fix i=
t that I=E2=80=99m aware of would be to make BIP 125 RBF even more restrict=
ive than it is today. I do think this is something that needs to be worked =
on.)<br><br>Given the limitations of RBF as we have it today, it appears to=
 be incorrect that a fullrbf network policy would solve the problems Antoin=
e raised.=C2=A0 And so absent any other examples, it does not seem to me th=
at fullrbf solves any problems for RBF users, who are already free to choos=
e to subject their transactions to BIP 125=E2=80=99s RBF policy.=C2=A0 From=
 this perspective, &quot;enabling fullrbf&quot; is really just taking away =
user choice to opt a transaction into a non-replacement policy regime.<br><=
br>I think we should ask, then, whether it is reasonable on its face that u=
sers might want to opt-in to a non-replacement policy?=C2=A0 Or in other wo=
rds, is it reasonable for a user to mark a transaction as non-replaceable a=
nd 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 a=
n unenforced way, their intention to not replace a transaction.=C2=A0 This =
might give useful information to the network or the recipient for how to in=
teract with such a transaction.<br><br>And I think that it&#39;s entirely p=
ossible that users would continue to use the BIP 125 signaling to indicate =
that they do not intend to replace a transaction.=C2=A0 For better or worse=
, this might be because zeroconf services continue to differentiate their b=
ehavior based on such a signal (possibly in conjunction with other factors)=
, or it could be because there are other behaviors that could be utilized m=
ore effectively if the transaction originator has made such a signal, such =
as the recipient chaining an unconfirmed transaction as a way to bump the f=
ee (CPFP) [4]. <br><br>If it were to be the case that users continued to us=
e BIP 125-style signaling to indicate that they do not plan to replace a tr=
ansaction, would that be harmful to the network?=C2=A0 This is not somethin=
g we can stop in our policy rules (short of censoring such transactions, an=
 obviously bad idea).=C2=A0 I think network actors can always do things tha=
t we might think are harmful for the network, but that doesn=E2=80=99t mean=
 that there are no legitimate use cases for the tools that such actors migh=
t be using.=C2=A0 Just because someone might use some policy to adopt a zer=
oconf model, doesn=E2=80=99t mean that others aren=E2=80=99t using the same=
 policy to achieve benign ends (such as better CPFP behavior).<br><br>Moreo=
ver, while users might attempt to exploit services that offer zeroconf or o=
ther differentiated behavior to non-replacement signaling transactions, the=
y also might not -- I think predicting user behavior in this way (and speci=
fically 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 pr=
otocol developers.=C2=A0 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-r=
eplacement policy regime, is that a technically sound option for us to have=
 on the network and enforce in software?=C2=A0 Specifically, does that inte=
rfere with having a sensible anti-DoS mempool acceptance algorithm, or inte=
rfere with other protocols on the network, or necessarily run counter to th=
e interests of miners or node operators?<br><br>And I think the answer to t=
hat 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 trans=
actions doesn&#39;t introduce any fundamental issues with software or netwo=
rk policy or other protocols.=C2=A0 In a world where we only had fullrbf, I=
 could imagine at some point down the road proposing a non-replacement sign=
al 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 i=
s not always incentive compatible to begin with!).=C2=A0 Conceptually, this=
 is no different to me than the version=3D3 transaction policy proposal tha=
t has been advancing, if we think of it as a special set of restrictions on=
 transactions designed to accommodate a particular use case. =C2=A0<br><br>=
Philosophically, I think we should be looking to add non-interfering use ca=
ses to what the network supports. =C2=A0<br><br>To those who argue for maki=
ng fullrbf a default policy on the network (or even just offering a flag fo=
r users to enable fullrbf), I pose this hypothetical: suppose we deploy the=
 v3 transaction policy proposal (which I hope will happen in the near futur=
e).=C2=A0 That policy would restrict the ways that outputs of a v3 transact=
ion can be spent while the transaction is unconfirmed, including by limitin=
g the number and size of descendants that such a transaction can have, and =
limiting the types of unconfirmed ancestors that can be included.=C2=A0 Sup=
pose in a few years someone proposes that we add a &quot;-disable_v3_transa=
ction_enforcement&quot; flag to our software, to let users decide to turn o=
ff 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&#39=
;s illogical for the recipient of a v3 transaction to believe what is a fun=
damentally unenforceable promise of a sender to not issue more high value c=
hildren that descend from an unconfirmed transaction; it&#39;s inappropriat=
e for Bitcoin Core to dictate policy on the network and we should honor use=
r choice to turn off that flag if that=E2=80=99s what users want; if users =
are relying on v3=E2=80=99s policy restrictions for security then that is a=
n unstable model and we should assume it will get broken[5]. =C2=A0<br><br>=
It=E2=80=99s obvious to me that adding a flag to disable v3 policy would be=
 subversive to making the lightning use case for v3 transactions work.=C2=
=A0 And so my response to such a hypothetical proposal would be to argue th=
at no, we should not enable users to disable this policy, because as long a=
s that policy is just optional and working for those who want it, it should=
n=E2=80=99t harm anyone that we offer a tighter set of rules for a particul=
ar use case.=C2=A0 Adding a way to bypass those rules is just trying to bre=
ak someone else=E2=80=99s use case, not trying to add a new one.=C2=A0 We s=
hould not wield &quot;incentive compatibility&quot; as a bludgeon for break=
ing things that appear to be working and not causing others harm.<br><br>I =
think this is exactly what is happening with fullrbf.<br><br>In comparing v=
3 transaction policy with opting out of transaction replacement, there is o=
f course one significant difference that I have ignored thus far: I think t=
he real difference is an opinion about whether non-replacement transactions=
 that are being used today are, overall, bad for Bitcoin, and whether light=
ning=E2=80=99s use of v3 transactions in the future would be bad for Bitcoi=
n. 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 qualit=
ative judgment might sway you to not worrying about the philosophical issue=
s I&#39;ve raised above, because these situations can be distinguished.<br>=
<br>However I am not personally willing to say that I think, overall, non-r=
bf-signaling transactions in use on the network today are bad for Bitcoin (=
or that fullrbf is definitely good =E2=80=93 BIP 125=E2=80=99s rbf rules ar=
e something we=E2=80=99ve been trying to improve upon for years, with littl=
e success).=C2=A0 Nor am I convinced that someone couldn=E2=80=99t put toge=
ther a cogent argument for lightning being bad for Bitcoin, because of its =
reliance on relay policies that are difficult to design and impossible to g=
uarantee as part of its security model.=C2=A0 So I choose instead to merely=
 make a judgment that seems more factually verifiable, which is that non-re=
placement is a policy widely in use on the network today, and we largely do=
n&#39;t have reason to think (as far as I know!) that the network is seeing=
 a lot of transactions that would violate that policy.<br><br>If it did tur=
n 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 re=
ason for Bitcoin Core to adopt fullrbf to reflect the reality of what is ha=
ppening.=C2=A0 In the meantime, I think it makes more sense to say that bec=
ause 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.=C2=A0 Other softw=
are 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=E2=80=
=99ll abandon it.=C2=A0 But I think the philosophy of transaction relay pol=
icy in Bitcoin Core should be to support disparate use cases in order to tr=
y to make everything work better, rather than break things prematurely beca=
use we guess others will break them eventually anyway.<br><br>For those tha=
t have read this long email and still favor a fullrbf network policy (or ev=
en just the ability for users to be able to turn on fullrbf for themselves)=
, I=E2=80=99d ask for thoughts on the following questions, which have guide=
d my thinking on this:<br><br>Does fullrbf offer any benefits other than br=
eaking zeroconf business practices?=C2=A0 If so, what are they?<br><br>Is i=
t reasonable to enforce BIP 125&#39;s rbf rules on all transactions, if tho=
se rules themselves are not always incentive compatible?<br><br>If someone =
were to propose a command line option that breaks v3 transaction relay in t=
he future, is there a logical basis for opposing that which is consistent w=
ith moving towards fullrbf now?</div><div dir=3D"ltr"><br></div><div dir=3D=
"ltr">Cheers,<br>Suhas<br><br><br>[1] <a href=3D"https://lists.linuxfoundat=
ion.org/pipermail/lightning-dev/2021-May/003033.html" target=3D"_blank">htt=
ps://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html=
</a><div><br>[2] <a href=3D"https://lists.linuxfoundation.org/pipermail/bit=
coin-dev/2022-September/020937.html" target=3D"_blank">https://lists.linuxf=
oundation.org/pipermail/bitcoin-dev/2022-September/020937.html</a><br><br><=
/div><div>[3] This is because under the BIP 125 rules, the feerate of the r=
eplacement transaction is not compared to the individual feerates of all tr=
ansactions being evicted =E2=80=93 we just compare feerates with the transa=
ctions that are directly in conflict (and not their descendants). So it=E2=
=80=99s possible for a transaction that would evict 2 or more transactions =
to have a higher feerate than the direct conflicts, and higher total fee th=
an the set being evicted, but have a lower feerate=C2=A0(eg if it is larger=
) than that of some subset of the set of transactions being evicted.<br><br=
></div><div>[4] =C2=A0Chaining unconfirmed transactions when the sender mig=
ht RBF the parent is far riskier than if the sender indicates they don&#39;=
t plan to do so (chaining onto an RBF transaction creates pinning issues fo=
r the sender, and risks having the child wiped out if the parent is replace=
d), so I think this is a concrete reason why signaling that a transaction w=
on=E2=80=99t be replaced could be useful.<br><br></div><div>[5] This is a s=
ubtle point. I don=E2=80=99t think v3 transactions create an unreasonable s=
ecurity assumption for the use case it is being designed for. However, I do=
n=E2=80=99t think anyone could rule out the possibility that someone could =
adopt a usage pattern for v3 transactions that subverts the intent of this =
policy.=C2=A0 For example, if users started using v3 transactions for all t=
heir payments, then the limitations on the number of descendants could dire=
ctly interfere with CPFP by a recipient, and someone could argue that we sh=
ould break the policy in order to allow for this hypothetical behavior. I t=
hink this is a similar form of argument as saying that zeroconf practices +=
 BIP 125 create an incentive to double-spend non-rbf signaling transactions=
.</div></div></div>

--00000000000063503505ec5437a1--