path: root/2d/b824f303e75ba18cdd9845ba540b5bccb41fcb

Return-Path: <gsanders87@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id AE340C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 31 Oct 2022 16:26:03 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 8833B81760
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 31 Oct 2022 16:26:03 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 8833B81760
Authentication-Results: smtp1.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=dVw4lZYK
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level: 
X-Spam-Status: No, score=-1.848 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_ENVFROM_END_DIGIT=0.25, 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 smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 034LSouT1xPo
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 31 Oct 2022 16:26:01 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 86FBD8175B
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com
 [IPv6:2a00:1450:4864:20::632])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 86FBD8175B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 31 Oct 2022 16:26:00 +0000 (UTC)
Received: by mail-ej1-x632.google.com with SMTP id kt23so30701874ejc.7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 31 Oct 2022 09:26:00 -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=/tDUVKLvpfDYvvZjbTH5xswaxDxO3XRzhkO52wZZfpk=;
 b=dVw4lZYKRq58izrhbhXqSjS0xKR4SnDgIxUYcXS9r80knneJEJOVP7dAYfYQ4PMSfr
 c8zjIk+NTZpSDx5zjcRNHXr+sXYvviBGyBUShMtcRCSrlJpkiKhxTFVrBd8WtI6CJL6b
 c3Y+t09W0fRuRfMIHVEAU1wMFHgYmvGGHW0T511Ofo0P8FX9zeneGLlkvcWfV5XQBl7p
 r+/w151IpAO8uFy7dvgf7ThewUfaHgL/XL2oeAvUrn4ajWoA3Dhb7SsY4aN+F4sNCtrS
 Tt6iudmQbgR0dfLkGIZNELQpHY+BA15Ck9ejDG8gO+dUiwHlrOSJ8tT/682G+hDomTTZ
 xsgA==
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=/tDUVKLvpfDYvvZjbTH5xswaxDxO3XRzhkO52wZZfpk=;
 b=agUbzYouuwN5vPO1SG1rrp0qSGFzV9VvxasdhjWU/Tkdx6pOUZ+gV5CBh8MhWzlbjb
 pJtz9H+I+nm4TMTM8txpYqwJAACUbyfBiu3mBsZ6AaefAuWYCo9IHdg6RluE6Gk+Vk/A
 bsYhi4vBOgiaPesr0i9Y6GnLm/vxpGdeJLcHnKVLclXxgryF5aw5aElJgXcRRH6pReBF
 qX5k6BSgEQcCLNAQ9ZtVwKF9NPfoMPvH0jPShA5yWDLVcoTSkDUSt6lVOAZP/metmdCn
 Ma8Kxjlld06HkYYxy2/1UIatgLwKNIkKYV6ASW5WU/MBQ8OJ5Aw1MPGzBX7h1d3Kpcih
 14Og==
X-Gm-Message-State: ACrzQf0A5VCoYRPy6ANzGwHxa1ruvpNoY/fMUQIKSAQBZbVRdUFKmga9
 ZxUnK6vzIbew/IJnnys7pGYDrzN18dSJ3UJVJ0lQ4uoBRHo=
X-Google-Smtp-Source: AMsMyM7apSdxQ6a15byVwcaeamyXA/ou/7rB8xj3puVCz17YYhPvc8L59CAt2SWL7t25gooG1Kvg8u6kNLCd3Wdkq8s=
X-Received: by 2002:a17:907:2e0b:b0:7a7:d37e:4650 with SMTP id
 ig11-20020a1709072e0b00b007a7d37e4650mr14033610ejc.261.1667233558374; Mon, 31
 Oct 2022 09:25:58 -0700 (PDT)
MIME-Version: 1.0
References: <Y1nIKjQC3DkiSGyw@erisian.com.au>
 <CAFp6fsFm06J2G1=3ojQvcL9gbEbQ41C4rmf3=Jkm9Qm0VBhhKw@mail.gmail.com>
In-Reply-To: <CAFp6fsFm06J2G1=3ojQvcL9gbEbQ41C4rmf3=Jkm9Qm0VBhhKw@mail.gmail.com>
From: Greg Sanders <gsanders87@gmail.com>
Date: Mon, 31 Oct 2022 12:25:46 -0400
Message-ID: <CAB3F3Dt=2hDXXw6Jz9QwnotkNLyGdZn9GZLHFXu0Dnyz3tsc0w@mail.gmail.com>
To: Suhas Daftuar <sdaftuar@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000012c6805ec57103e"
X-Mailman-Approved-At: Mon, 31 Oct 2022 16:27:54 +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 16:26:03 -0000

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

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 mysel=
f
> 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 rel=
ay
> 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 candida=
te 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 optio=
ns
> 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 transacti=
on
> to BIP 125=E2=80=99s RBF rules or not (based on the sequence values of th=
e
> 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 =
were 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 Sander=
s
> for clarifying this to me), I understand that the issue is around ensurin=
g
> 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 hav=
e
> 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 t=
he
> ability for rbf =E2=80=9Cpinning=E2=80=9D to interfere with relay of the =
multiparty
> 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 see=
ms
> 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 transacti=
on
> 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 rel=
ay
> 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 devia=
te from
> the supported policies, and we therefore shouldn=E2=80=99t need 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 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 wit=
h
> 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 kn=
ow
> 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 o=
f would be
> to make BIP 125 RBF even more restrictive than it is today. I do think th=
is
> 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 word=
s,
> 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 dominan=
t
> 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 intera=
ct
> 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 service=
s
> continue to differentiate their behavior based on such a signal (possibly
> in conjunction with other factors), or it could be because there are othe=
r
> 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, wou=
ld
> 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 a=
re
> harmful for the network, but that doesn=E2=80=99t 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=E2=80=99t =
mean 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 o=
f
> 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, o=
r
> 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 aroun=
d
> transaction chains (and pinning) are more complex for the RBF case than f=
or
> 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 way=
s
> that outputs of a v3 transaction can be spent while the transaction is
> unconfirmed, including by limiting the number and size of descendants tha=
t
> 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 argue=
d
> 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 fl=
ag
> if that=E2=80=99s what users want; if users are relying on v3=E2=80=99s p=
olicy 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.  An=
d
> 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 tha=
t
> 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 wiel=
d
> "incentive compatibility" as a bludgeon for breaking things that appear t=
o
> 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 th=
e 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 abo=
ut
> 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 r=
bf rules are
> something we=E2=80=99ve been trying to improve upon for years, with littl=
e
> 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 a=
s
> part of its security model.  So I choose instead to merely make a judgmen=
t
> 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 reas=
on
> 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, bu=
t
> 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 sa=
y
> that because we have BIP 125, there seems to be no need for users to sign=
al
> 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 tha=
t
> 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 tran=
saction
> 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 networ=
k
> 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,=
 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 th=
at
> 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/02=
0937.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 tr=
ansactions
> that are directly in conflict (and not their descendants). So it=E2=80=99=
s possible
> for a transaction that would evict 2 or more transactions to have a highe=
r
> feerate than the direct conflicts, and higher total fee than the set bein=
g
> 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 thi=
nk
> 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 fo=
r.
> However, I don=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.  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
>

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

<div dir=3D"ltr"><div>Thanks for your full thoughts Suhas,<br></div><div><b=
r></div><div>The idea of V3 is that we&#39;re currently leaving fees on the=
 table by allowing use-cases to be pinned, not that we like Lightning and w=
e think miners should stop being profit maximizing somehow to enable safer/=
better layer=C2=A02 systems.<br></div><div><br></div><div>If someone wants =
to bump fees for V3 transactions(or replace them!), there&#39;s a much simp=
ler &quot;API&quot; to do so than in legacy policy land. The fact that it d=
isallows more idiotic ways to add more total fees means wallets &quot;shoul=
dn&#39;t do that&quot;. If it ends up that V3 is disallowing too many &quot=
;natural&quot; ways to fee bump, that&#39;s a strike against the V3 idea an=
d should be discussed. For 0-conf services we have potential thieves who ar=
e willing to *out-bid themselves* to have funds come back to themselves. It=
&#39;s not a &quot;legitimate&quot; use-case, but a rational one.</div><div=
><br></div><div>I have mostly come around to not pushing for fullrbf=C2=A0d=
ue to the issues you mentioned, except taking away the option. Removing a q=
uite-likely-incentive-compatible option from the software just encourages m=
iners to adopt an additional patch if they ever deem it necessary to increa=
se their revenue, even if that revenue is from hurting 0-conf businesses.<b=
r></div><div><br></div><div>Maybe putting/leaving in a default-false flag f=
or disabling these &quot;carve outs&quot; is the least bad option. V3 usage=
 patterns shouldn&#39;t crumble if a large majority of miners opt out, but =
0-conf use cases crumble after a small percentage of adoption.<br></div><di=
v><br></div><div>To recap my thoughts:</div><div><br></div><div>1) I have p=
ut away my fullrbf=C2=A0hats, I will not advocate anyone running it as I th=
ink it doesn&#39;t really do anything useful for users who aren&#39;t tryin=
g to double-spend merchants.<br></div><div>2) Forcing miners to honor fees =
left on the table with respect to 0-conf, or forcing them to run a custom p=
atchset to go around it, is a step backwards.</div><div><br></div><div>Greg=
<br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gm=
ail_attr">On Mon, Oct 31, 2022 at 11:03 AM Suhas Daftuar via bitcoin-dev &l=
t;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@list=
s.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr">AJ,<br><br>Thanks fo=
r 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 th=
e discussions around `-mempoolfullrbf`, are on-point and provide a helpful =
baseline for considering future policy changes.<br><br>For a long time I vi=
ewed fullrbf as an eventuality and I considered myself to be philosophicall=
y supportive of the idea.=C2=A0 However, after giving this issue some thoug=
ht in the past few weeks, I am reversing my thinking on this.=C2=A0 Concret=
ely, I will argue that we should continue to maintain a relay policy where =
replacements are rejected for transactions that don&#39;t opt-in to RBF (as=
 described in BIP 125), and moreover, that we should remove the `-mempoolfu=
llrbf` flag from Bitcoin Core=E2=80=99s latest release candidate and not pl=
an to release software with that flag, unless (or until) circumstances chan=
ge on the network, which I&#39;ll discuss below.<br><br>This is, of course,=
 a nuanced topic, and among the considerations is a philosophy of how to th=
ink about the relay policy and configuration options that we make available=
 in Bitcoin Core (a consideration that is perhaps unique to that project, b=
ut I think relevant for this mailing list).<br><br>I&#39;ll start with some=
 technical issues regarding the benefits of enabling fullrbf on the network=
.=C2=A0 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 R=
BF rules or not (based on the sequence values of the inputs).=C2=A0 So give=
n 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 were still denied =
the benefits of RBF due to the existence of other transactions that don=E2=
=80=99t opt-in.<br><br>Along those lines, Antoine Riard brought up[1] a DoS=
 vector that is available to someone who wants to interfere with multi-part=
y funded transactions, and suggested that fullrbf would eliminate the probl=
em.=C2=A0 After exploring that question again in this thread (thanks to Gre=
g Sanders for clarifying this to me), I understand that the issue is around=
 ensuring that a multiparty (coinjoin-type) protocol is able to make eventu=
al progress, by having a candidate multiparty transaction either eventually=
 confirm or become conflicted with something that has been confirmed, in wh=
ich case the double-spend information could be used to start a new coinjoin=
 round with fewer participants.=C2=A0 The concern Antoine and Greg have bro=
ught up is that non-rbf transactions can persist in the mempool ~indefinite=
ly (at a low feerate and not subject to replacement) and interfere with pro=
gress being made in a coinjoin protocol.<br><br>However, it seems to me tha=
t similar problems exist for such a protocol even in a fullrbf world, as we=
 understand that term today.=C2=A0 I mentioned the ability for rbf =E2=80=
=9Cpinning=E2=80=9D to interfere with relay of the multiparty transaction (=
even if the conflicting transaction signals for RBF =E2=80=93 a set of larg=
e but low feerate conflicting transactions can persist in the mempool and m=
ake it difficult for the coinjoin transaction from confirming, at least wit=
hout 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.=C2=A0 It seems to me that =
what these multiparty protocols actually need is some sort of &quot;maximal=
 rbf&quot; network policy: a way to guarantee that a transaction which shou=
ld be desirable for a miner to mine would always get to a miner and conside=
red for inclusion in a block, no matter what the state of node=E2=80=99s me=
mpools on the network.<br><br>While that sounds like a reasonable thing to =
want on its face (and worth working on), it&#39;s not how opt-in RBF works =
today, nor is it how transaction relay has ever conceptually worked.=C2=A0 =
We have not, thus far, been able to come up with a total ordering on transa=
ction desirability.=C2=A0 Moreover, due to all the DoS issues that exist wi=
th transaction relay, there are plenty of seemingly legitimate ways to cons=
truct transactions that would not relay well on the network.=C2=A0 Relay ha=
s 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=
.=C2=A0 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 the=
refore shouldn=E2=80=99t need to worry too much about incentive compatibili=
ty concerns when it comes to transaction types that wouldn=E2=80=99t relay =
at all, even if they are high feerate. =C2=A0(And when those situations ari=
se where the standard transactions do not accommodate some needed use case,=
 developers typically work to define a policy that is compatible with our a=
nti-DoS goals to support such use cases, such as with the recent proposal f=
or version=3D3 transactions [2].)<br><br>BIP 125&#39;s RBF rules themselves=
 were an effort to carve out just a subset of situations where a transactio=
n should evict conflicting ones -- it was not a design that anyone thought =
would ensure that all replacements which &quot;should&quot; be mined would =
always propagate.=C2=A0 And I don&#39;t believe that we know how to design =
policy rules that would achieve the goals of this kind of multiparty protoc=
ol in a DoS resistant way, today.=C2=A0 Along those lines, I would point ou=
t that even the BIP 125 design itself is not entirely incentive compatible,=
 in that it is possible to construct a replacement transaction that would e=
vict transactions which would 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 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 somethin=
g that needs to be worked on.)<br><br>Given the limitations of RBF as we ha=
ve it today, it appears to be incorrect that a fullrbf network policy would=
 solve the problems Antoine raised.=C2=A0 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.=C2=A0 From this perspective, &quot;enabling fullrbf&quot; =
is really just taking away user choice to opt a transaction into a non-repl=
acement policy regime.<br><br>I think we should ask, then, whether it is re=
asonable on its face that users might want to opt-in to a non-replacement p=
olicy?=C2=A0 Or in other words, is it reasonable for a user to mark a trans=
action as non-replaceable and have that indication be enforced by the netwo=
rk? 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 signali=
ng method to indicate, in an 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 interact with such a transaction.<br><br>And I thi=
nk that it&#39;s entirely possible 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 contin=
ue to differentiate their behavior based on such a signal (possibly in conj=
unction with other factors), or it could be because there are other behavio=
rs that could be utilized more effectively if the transaction originator ha=
s made such a signal, such as the recipient chaining an unconfirmed transac=
tion as 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 signaling to indicate that they =
do not plan to replace a transaction, would that be harmful to the network?=
=C2=A0 This is not something we can stop in our policy rules (short of cens=
oring such transactions, an obviously bad idea).=C2=A0 I think network acto=
rs can always do things that we might think are harmful for the network, bu=
t that doesn=E2=80=99t mean that there are no legitimate use cases for the =
tools that such actors might be using.=C2=A0 Just because someone might use=
 some policy to adopt a zeroconf model, doesn=E2=80=99t mean that others ar=
en=E2=80=99t using the same policy to achieve benign ends (such as better C=
PFP behavior).<br><br>Moreover, while users might attempt to exploit servic=
es that offer zeroconf or other differentiated behavior to non-replacement =
signaling transactions, they also might not -- I think predicting user beha=
vior in this way (and specifically predicting the complexities of what a bu=
siness might do and whether users might try to subvert it) is beyond the sc=
ope of what we can do as protocol developers.=C2=A0 Instead, I think we can=
 try to answer a different question: if a group of users were to want the a=
bility 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?=C2=A0 S=
pecifically, does that interfere with having a sensible anti-DoS mempool ac=
ceptance algorithm, or interfere with other protocols on the network, or ne=
cessarily run counter to the interests of miners or node operators?<br><br>=
And I think the answer to that question, in looking at the difference betwe=
en opt-in RBF and fullrbf, is no: offering the ability to opt-in to a non-r=
eplacement regime for transactions doesn&#39;t introduce any fundamental is=
sues with software or network policy or other protocols.=C2=A0 In a world w=
here we only had fullrbf, I could imagine at some point down the road propo=
sing a non-replacement signal myself, because the complexities around trans=
action 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!=
).=C2=A0 Conceptually, this is no different to me than the version=3D3 tran=
saction policy proposal that has been advancing, if we think of it as a spe=
cial set of restrictions on transactions designed to accommodate a particul=
ar use case. =C2=A0<br><br>Philosophically, I think we should be looking to=
 add non-interfering use cases to what the network supports. =C2=A0<br><br>=
To those who argue for making fullrbf a default policy on the network (or e=
ven just offering a flag for users to enable fullrbf), I pose this hypothet=
ical: suppose we deploy the v3 transaction policy proposal (which I hope wi=
ll happen in the near future).=C2=A0 That policy would restrict the ways th=
at outputs of a v3 transaction can be spent while the transaction is unconf=
irmed, 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.=C2=A0 Suppose in a few years someone proposes that we add=
 a &quot;-disable_v3_transaction_enforcement&quot; flag to our software, to=
 let users decide to turn off those policy restrictions and treat v3 transa=
ctions 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 descend=
ant v3 transactions; it&#39;s illogical for the recipient of a v3 transacti=
on to believe what is a fundamentally unenforceable promise of a sender to =
not issue more high value children that descend from an unconfirmed transac=
tion; it&#39;s inappropriate for Bitcoin Core to dictate policy on the netw=
ork 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 policy restrictions =
for security then that is an unstable model and we should assume it will ge=
t 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 prop=
osal 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 tho=
se who want it, it shouldn=E2=80=99t harm anyone that we offer a tighter se=
t of rules for a particular use case.=C2=A0 Adding a way to bypass those ru=
les is just trying to break someone else=E2=80=99s use case, not trying to =
add a new one.=C2=A0 We should not wield &quot;incentive compatibility&quot=
; as a bludgeon for breaking things that appear to be working and not causi=
ng others harm.<br><br>I think this is exactly what is happening with fullr=
bf.<br><br>In comparing v3 transaction policy with opting out of transactio=
n replacement, there is of course one significant difference that I have ig=
nored thus far: I think the real difference is an opinion about whether non=
-replacement transactions that are being used today are, overall, bad for B=
itcoin, and whether lightning=E2=80=99s use of v3 transactions in the futur=
e 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 abou=
t the philosophical issues I&#39;ve raised above, because these situations =
can be distinguished.<br><br>However I am not personally willing to say tha=
t I think, overall, non-rbf-signaling transactions in use on the network to=
day are bad for Bitcoin (or that fullrbf is definitely good =E2=80=93 BIP 1=
25=E2=80=99s rbf rules are something we=E2=80=99ve been trying to improve u=
pon for years, with little success).=C2=A0 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 d=
esign and impossible to guarantee as part of its security model.=C2=A0 So I=
 choose instead to merely make a judgment that seems more factually verifia=
ble, which is that non-replacement is a policy widely in use on the network=
 today, and we largely don&#39;t have reason to think (as far as I know!) t=
hat the network is seeing a lot of transactions that would violate that pol=
icy.<br><br>If it did turn out that users were commonly signaling non-repla=
cement, but then signing and trying to relay doublespends, then I think tha=
t would be a very good reason for Bitcoin Core to adopt fullrbf to reflect =
the reality of what is happening.=C2=A0 In the meantime, I think it makes m=
ore sense to say that because we have BIP 125, there seems to be no need fo=
r users to signal one way and behave another, and therefore there is no nee=
d to offer software that might break a policy that is working well for some=
 users.=C2=A0 Other software projects might choose differently, and it is a=
fter all a permissionless network, so if this is in fact an unstable equili=
brium 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 policy in Bitcoin Core should be to support disparate=
 use cases in order to try to make everything work better, rather than brea=
k things prematurely because we guess others will break them eventually any=
way.<br><br>For those that have read this long email and still favor a full=
rbf network policy (or even just the ability for users to be able to turn o=
n fullrbf for themselves), I=E2=80=99d ask for thoughts on the following qu=
estions, which have guided my thinking on this:<br><br>Does fullrbf offer a=
ny benefits other than breaking zeroconf business practices?=C2=A0 If so, w=
hat are they?<br><br>Is it reasonable to enforce BIP 125&#39;s rbf rules on=
 all transactions, if those rules themselves are not always incentive compa=
tible?<br><br>If someone were to propose a command line option that breaks =
v3 transaction relay in the future, is there a logical basis for opposing t=
hat which is consistent with moving towards fullrbf now?</div><div dir=3D"l=
tr"><br></div><div dir=3D"ltr">Cheers,<br>Suhas<br><br><br>[1] <a href=3D"h=
ttps://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.ht=
ml" target=3D"_blank">https://lists.linuxfoundation.org/pipermail/lightning=
-dev/2021-May/003033.html</a><div><br>[2] <a href=3D"https://lists.linuxfou=
ndation.org/pipermail/bitcoin-dev/2022-September/020937.html" target=3D"_bl=
ank">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September=
/020937.html</a><br><br></div><div>[3] This is because under the BIP 125 ru=
les, the feerate of the replacement transaction is not compared to the indi=
vidual feerates of all transactions being evicted =E2=80=93 we just compare=
 feerates with the transactions that are directly in conflict (and not thei=
r 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=
=C2=A0(eg if it is larger) than that of some subset of the set of transacti=
ons being evicted.<br><br></div><div>[4] =C2=A0Chaining unconfirmed transac=
tions when the sender might RBF the parent is far riskier than if the sende=
r indicates they don&#39;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 signa=
ling that a transaction won=E2=80=99t be replaced could be useful.<br><br><=
/div><div>[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 de=
signed for. However, I don=E2=80=99t think anyone could rule out the possib=
ility that someone could adopt a usage pattern for v3 transactions that sub=
verts the intent of this policy.=C2=A0 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 someo=
ne could argue that we should break the policy in order to allow for this h=
ypothetical behavior. I think this is a similar form of argument as saying =
that zeroconf practices + BIP 125 create an incentive to double-spend non-r=
bf signaling transactions.</div></div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000012c6805ec57103e--