path: root/e4/5e599690c430e6feaf95066fba1cb5c7bd8a47

Return-Path: <antoine.riard@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 401A1C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 27 Oct 2022 20:30:03 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 055B040105
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 27 Oct 2022 20:30:03 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 055B040105
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=f/ezXC2D
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.101
X-Spam-Level: 
X-Spam-Status: No, score=0.101 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, MANY_SPAN_IN_TEXT=2.199,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
 autolearn=no 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 1LYf3c5PWK3y
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 27 Oct 2022 20:29:59 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 566CC400C4
Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com
 [IPv6:2607:f8b0:4864:20::d2f])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 566CC400C4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 27 Oct 2022 20:29:59 +0000 (UTC)
Received: by mail-io1-xd2f.google.com with SMTP id b79so2774114iof.5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 27 Oct 2022 13:29:59 -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=RC+aQRR++H7gSngMBv76hBLp59fibCH4UO6/eSSVyQU=;
 b=f/ezXC2DRogHL2K8rM731QZLEjaikUjoWRmlg8gERMhAH8MrZgUzjQwj5B9xP82a92
 Po+K4J9XMrdRoeYTBzel3xTBJueKurq7zqddE0ljEctojtumvO82WcOe384RsR/dvP/9
 W4v7JfeF1VLhVIsEMBMDfjF2UfKeJmVKXGk8HkiLANwkgC/e3kR5r4bkygcBtL8w4r7v
 L8nLQ4ZX6DOFAka/S2TcWKMTkGPF7ctngDtFFtx/QQAOHlGhbeD6KLFfAMPv9euf2FB1
 FB5NydQ1WgRXLlZ/qGVLmC3titpDdRlb1fY1gNAizIx1byi2FuewRhelgMnov8dYOF3c
 H1gQ==
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=RC+aQRR++H7gSngMBv76hBLp59fibCH4UO6/eSSVyQU=;
 b=TFvwArJiPNxjRfm0oJfhjsY0+NA6Lpy6Nk9+3NanEkJhYPJmGyB4u4WmMc88krtR+J
 nKG9y9CYnAwhM5ckTj+ERBOyx41bcL92FGhFOQyrxrbcgwOKTO+kpSM5vYqHFgUtU1hs
 eQIgkXvdTtJ9L9H2U9+Q0zc4aFF1YZUB+D+a/k7Nekq/r7r4IMKmF/t5mj4QqCzXfQQA
 Yb24lw46yErrBCtCSsjZ/huXRs8+ZBLWFMCCL2I50rlUbAjbPJ+Q0g1yUdsx8GHlXEn1
 +Qnhv28ztbP5JPIi59Akumw8/IrqodheTgG2Sjo+A2839dF7ARpP9dvwY9uD6wS7YECL
 7UoQ==
X-Gm-Message-State: ACrzQf1B5Xo+c3nRbaF6x+4WoeIpCMXUVBBFF4UlkCtl44HaeNE3ogQU
 P7ri3+MsIBTvObAml11oZMki6Y/18JgDs3HMxFpZV1bYM/A=
X-Google-Smtp-Source: AMsMyM5v8mJrsdmmBfxtfgjvnEiWmyMP2RN/u5NRnoJvcuHYDGyFa3qzpk3FQB5aP3bazhzSE2ZyLwIFh/qBXmQbG98=
X-Received: by 2002:a05:6638:164c:b0:365:c390:3eb5 with SMTP id
 a12-20020a056638164c00b00365c3903eb5mr33313161jat.302.1666902598071; Thu, 27
 Oct 2022 13:29:58 -0700 (PDT)
MIME-Version: 1.0
References: <Y1nIKjQC3DkiSGyw@erisian.com.au>
In-Reply-To: <Y1nIKjQC3DkiSGyw@erisian.com.au>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Thu, 27 Oct 2022 21:29:47 +0100
Message-ID: <CALZpt+EyeL5JjE_bctrcqsRBQkZhu0X1=ChGbyekeqbms1GWtQ@mail.gmail.com>
To: Anthony Towns <aj@erisian.com.au>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000003bbb3605ec0a01c2"
X-Mailman-Approved-At: Thu, 27 Oct 2022 20:32:46 +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: Thu, 27 Oct 2022 20:30:03 -0000

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

Hi AJ,


Let's take the contra.


I would say the current post describes the state of Bitcoin Core and
beyond policy
rules with a high-degree of exhaustivity and completeness, though itt what
is, mostly a description. While I think it ends with a set of
recommendations on what could be the relations between miners, devs and
node operators w.r.t adopting policy rules, to me it doesn't explore enough
the hard part of the subject. What should be actually the design goals and
principles of Core's transaction-relay propagation rules

of which mempool accepts ones is a subset ? By such design goals, I'm
thinking either, a qualitative framework, like attacks game for a concrete
application ("Can

we prevent pinning against multi-party Coinjoin ?"). Or a quantitative
approach, e.g how fast should be transaction-relay throughput for a given
topology, or how much accurate is the block template against usual blocks
[0]


Assuming we would have technical principles and goals guiding our
development process, of which the discussion and revision should be an
inherent part of the process itself,  I believe we would come up with a
second-order observation. That we might not be able to satisfy every
use-case with the standard set of policy rules. E.g, a contracting protocol
could look for package size beyond the upper bound anti-Dos limit. Or even =
the
global ressources offered by the network of full-nodes are not high enough
to handle some application event. E.g a Lightning Service Provider doing a
liquidity maintenance round of all its counterparties, and as such
force-closing and broadcasting more transactions than can be handled at the
transaction-relay layer due to default MAX_PEER_TX_ANNOUNCEMENTS value.


My personal take on those subjects, we might have to realize we're facing
an heterogeneity of Bitcoin applications and use-cases [1]. And this sounds
like a long-term upward trend, akin to the history of the Internet: mail
clients, web browser, streaming applications, etc, all with different
service-level requirements in terms of latency, jitters and bandwidth. We m=
ight
observe that Bitcoin actors might adopt individual strategies for the
consumption of it. E.g a multi-party contracting protocol with asymmetric
states, a counterparty could "front-run" the others at the
transaction-relay to avoid encumbering the RBF penalty in case of
concurrent broadcast. Or they could deploy an additive layer of
communication channels, like private transaction-relay to miners, e.g a LN
node broadcasting a HTLC-preimage and restraining the odds of mapping to an
off-chain payment path. Those additive layers of communication can be also
seen as mitigations against components failure risks, e.g a
transaction-relay

censorship vector in the p2p stack. To put it simply, some advanced Bitcoin
applications might have to outgrow the "mempool policy rules" game, as
we're currently defining it to satisfy to a higher degree their security
and operational models. I think this has been historically the case with
some miners deciding to join FIBER, to improve their view of mined blocks.


While I still think we can come up with clear policy rules for some ideal
or reasonable use-case (let's say the Bitcoin hobbyist aiming to strong
censorship-resistance of its

payment). And I hold the belief we can improve on that front, as we've done
during the past years by formalizing a subset of policy rules in Bitcoin
Core documentation. In

parallel, we might acknowledge the heterogeneity of use-cases, and that we
cannot offer the same level of censorship-resistance, privacy or
cost-effectiveness (And that might be okay if we remember that e.g
censorship-resistance between a simple Bitcoin payment and a Lightning HTLC
isn't defined the same, due to the usage of timelocks by the latter).


What I'm expressing is a long-term perspective, and we might be too early
in the evolutionary process that is Bitcoin Core development to abandon yet
the "one-size-fits-all"

policy rules conception that I understand from your post. Though to me, as
we progress on modularity and flexibility of the Core codebase, we might
have to envision a Bitcoin ecosystem where configuring a client is on the
same bar as the kernel Kconfig (hopefully not because no drivers/ but
still..). Of course, you can have "blessed" config to avoid the complexity
turning away node operators and users, though at the price of increasing
the trust in your vendors.


More concretely, about the issue of today, full-rbf, I think the lack of
design heuristic in the sense of what should be the reasonable or average
use-case

supported by the Bitcoin base-layer transaction-relay rules. Should we
favor the historical ones (0confs) or the new incumbent (contracting
protocols) ? There is always the "First, do not harm" principle in lack of
clear guidelines in any area of Bitcoin protocol development. Though when
we're facing risk arbitrage like the current one, I don't think as protocol
devs we have any strong reasoning framework. Deferring the decision to the
node operators as the approach is with #25353 + #25000, did acknowledge the
uncharted territory we're in with policy rules deprecation or novation.
Qualifying the gradual approach of "worst" sounds to me that every policy
rule will ever have to design or deploy will suffer from the same trade-off=
 of
full-rbf. A gradual approach could be a really realistic way to move forwar=
d
with some experimental package formats or Dandelion-like transaction
dissemination strategy. Such gradual approach of full-rbf deployment was
also aiming to set the precedent that in a situation of risk arbitrage,
with irreconcilable views between class of use-cases operators, the
decision shouldn't be in the scope of Bitcoin Core.


Hopefully, with a renewed effort of communication in the case of full-rbf,
we can accommodate the maximum of use-cases risks model and move towards a
coordinated approach, offering a visible and predictable timeline. Though
if we fail to reach "consensus" there, we might have to fallback on the
"gradual" approach, stating the full-rbf case is beyond the responsibility =
of
scope of Bitcoin Core.


Overall, many thanks for this thoughtful post. Good for me to uplift the
level of the discussion when we're hitting some bottleneck in our
development process.


Best,

Antoine


[0] https://github.com/bitcoin/bitcoin/issues/19820


[1] To be clear, this the opposite view I did express in :
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-July/018063.ht=
ml

After exposure and exploration of more Bitcoin use-cases and applications,
and even among the different requirement among types of use-cases nodes
(e.g LN mobile vs LSP), I believe more heterogeneity in the policy rules
usage makes more sense


Le jeu. 27 oct. 2022 =C3=A0 00:52, Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit :

> Hi *,
>
> TLDR: Yes, this post is too long, and there's no TLDR. If it's any
> consolation, it took longer to write than it does to read?
>
> On Tue, Jun 15, 2021 at 12:55:14PM -0400, Antoine Riard via bitcoin-dev
> wrote:
> > Subject: Re: [bitcoin-dev] Proposal: Full-RBF in Bitcoin Core 24.0
> > I'm writing to propose deprecation of opt-in RBF in favor of full-RBF
>
> > If there is ecosystem agreement on switching to full-RBF, but 0.24 soun=
ds
> > too early, let's defer it to 0.25 or 0.26. I don't think Core has a
> > consistent deprecation process w.r.t to policy rules heavily relied-on =
by
> > Bitcoin users, if we do so let sets a precedent satisfying as many folk=
s
> as
> > we can.
>
> One precedent that seems to be being set here, which to me seems fairly
> novel for bitcoin core, is that we're about to start supporting and
> encouraging nodes to have meaningfully different mempool policies. From
> what I've seen, the baseline expectation has always been that while
> certainly mempools can and will differ, policies will be largely the same=
:
>
>   Firstly, there is no "the mempool". There is no global mempool. Rather
>   each node maintains its own mempool and accepts and rejects transaction
>   to that mempool using their own internal policies. Most nodes have
>   the same policies, but due to different start times, relay delays,
>   and other factors, not every node has the same mempool, although they
>   may be very similar.
>
>   -
> https://bitcoin.stackexchange.com/questions/98585/how-to-find-if-two-tran=
sactions-in-mempool-are-conflicting
>
> Up until now, the differences between node policies supported by differen=
t
> nodes running core have been quite small, with essentially the following
> options available:
>
>  -minrelaytxfee, -maxmempool - changes the lowest fee rate you'll accept
>
>  -mempoolexpiry - how long to keep txs in the mempool
>
>  -datacarrier - reject txs creating OP_RETURN outputs
>
>  -datacarriersize - maximum size of OP_RETURN data
>
>  -permitbaremultisig - prevent relay of bare multisig
>
>  -bytespersigop - changes how SIGOP accounting works for relay and
>  mining prioritisation
>
> as well as these, marked as "debug only" options (only shown with
> -help-debug):
>
>  -incrementalrelayfee - make it easier/harder to spam txs by only
>  slightly bumping the fee; marked as a "debug only" option
>
>  -dustrelayfee - make it easier/harder to create uneconomic utxos;
>  marked as a "debug only" option
>
>  -limit{descendant,ancestor}{count,size} - changes how large the
>  transaction chains can be; marked as a "debug only" option
>
> and in theory, but not available on mainnet:
>
>  -acceptnonstdtxn - relay/mine non standard transactions
>
> There's also the "prioritisetransaction" rpc, which can cause you to keep
> a low feerate transaction in your mempool longer than you might otherwise=
.
>
> I think that -minrelaytxfee, -maxmempool and -mempoolexpiry are the only
> ones of those options commonly set, and those only rarely result in any
> differences in the txs at the top of the mempool.
>
> There are also quite a few parameters that aren't even runtime
> configurable:
>
>  - MAX_STANDARD_TX_WEIGHT
>  - MIN_STANDARD_TX_NONWITNESS_SIZE (see also #26265)
>  - MAX_P2SH_SIGOPS (see also #26348)
>  - MAX_STANDARD_TX_SIGOPS_COST
>  - MAX_STANDARD_P2WSH_STACK_ITEMS
>  - MAX_STANDARD_P2WSH_STACK_ITEM_SIZE
>  - MAX_STANDARD_TAPSCRIPT_STACK_ITEM_SIZE
>  - MAX_STANDARD_P2WSH_SCRIPT_SIZE
>  - MAX_STANDARD_SCRIPTSIG_SIZE
>  - EXTRA_DESCENDANT_TX_SIZE_LIMIT
>  - MAX_REPLACEMENT_CANDIDATES
>
> And other plausible options aren't configurable even at compile time
> -- eg, core doesn't implement BIP 125's inherited signalling rule so
> there's no way to enable it; core doesn't allow opting out of BIP 125
> rule 3 ratchet on absolute fee; core doesn't allow CPFP carveout with
> more than 1 ancestor; core doesn't allow opting out of LOW_S checks
> (even via -acceptnonstdtxn); etc.
>
> We also naturally have different mempool policies between different
> releases: eg, expansions of policy, such as allowing OP_RETURN or
> expanding it from 40 to 80 bytes or new soft forks where old nodes won't
> relay transactions that use the new; and also occassional restrictions
> in policy, such as the LOW_S requirement.
>
>
> While supporting and encouraging different mempool polices might be new
> for core, it's not new for knots: knots changes some of these defaults
> (-permitbaremultisig defaults to false, -datacarriersize is reduced to
> 42), allows the use of -acceptnonstdtxn on mainnet, and introduces new
> options including -spkreuse and -mempoolreplacement (giving the latter
> full rbf behaviour by default). Knots also includes a `-corepolicy`
> option to make it easy to get a configuration matching core's defaults.
>
>
> I think gmaxwell's take from Feb 2015 (in the context of how restrictive
> policy on OP_RETURN data should be) was a reasonable description for
> core's approach up until now:
>
>   There is also a matter of driving competent design rather than lazy
>   first thing that works. E.g. In stealth addresses the early proposals
>   use highly inefficient single ECDH point per output instead of simply
>   pooling them. Network behavior is one of the few bits of friction
>   driving good technical design rather than "move fast, break things, and
>   force everyone else onto my way of doing thing rather than discussing
>   the design in public". No one wants to be an outright gatekeeper,
>   but the network is a shared resource and it's perfectly reasonable
>   node behavior to be stingy about the perpetual storage impact of the
>   transactions they're willing to process, especially when it comes to
>   neutral technical criteria like the amount of network irrelevant data
>   stuffed in transactions.
>
>   There is also a very clear pattern we've seen in the past where
>   people take anything the system lets them do as strong evidence that
>   they have a irrevocable right to use the system in that way, and that
>   their only responsibility-- and if their usage harms the system it's
>   the responsibility of the system to not permit it. [...
>   ...] For mitigating these risks it's optimal if transactions
>   seem as uniform and indistinguishable as reasonably possible.
>
>   - https://github.com/bitcoin/bitcoin/pull/5286#issuecomment-72564175
>
> Perhaps see also sdaftuar in Nov 2015,
>
>   To me the most important question is, is priority something that miners
>   want to use?
>
>   If a non-negligible amount of hashpower intends to use it in their
>   transaction selection, then I think it makes sense for nodes to use it
>   too, because it's generally helpful to have your mempool predict the
>   UTXO as much as possible, and for nodes to be able to have reasonable
>   fee and priority estimates (which won't happen unless they track the
>   priority transactions somehow -- I'm presuming that miners run with
>   much bigger mempools than regular nodes).
>
>   If the answer is no, then that's fine and I don't see a reason to push
>   in this direction. I sort of assumed there was enough hashpower mining
>   with priority, since last time I checked estimatepriority was still
>   giving meaningful results for low-ish blockheights, but I haven't done
>   any kind of real analysis.
>
>   - https://github.com/bitcoin/bitcoin/pull/6992#issuecomment-155969455
>
> or in June 2019,
>
>   What this PR is proposing is to get rid of a command-line option that i=
s
>   (a) a footgun for users and (b) does not reflect what I believe to be
>   the understanding most users have, which is that [X txs] are expected
>   to propagate well on the network.
>
>   ..
>
>   I don't think this rises to the level that Luke is concerned about,
>   namely a prelude to forcing a common relay policy on all nodes. In
>   particular I do agree it makes sense that we offer some ways of
>   customizing policy parameters (eg the mempool size, min relay fee,
>   etc). Instead, I think the justification for this change is that we
>   should not support behaviors we think are harmful to the ecosystem
>   overall and have no legitimate use-case, and we should eliminate ways
>   that users might inadvertently shoot themselves in the foot.
>
>   - https://github.com/bitcoin/bitcoin/pull/16171#issuecomment-500393271
>
> (or see discussion in https://github.com/bitcoin/bitcoin/pull/7219)
>
> I don't mean to imply the above are saying "there's one way to do
> things and it's this way", or that the old way of doing things should
> necessarily be the way we keep doing things. Just that previously core
> has tended towards designing a single policy that works as well as it
> can for everyone and the ecosystem as a whole. (I'm also not saying that
> fullrbf can't work well for everyone or the ecosystem as a whole)
>
>
> By contrast, I think the most common response to pushback against the
> full rbf option has been along the lines of "it's just an option, we
> don't want to force people", eg:
>
>   Blaming the default false -mempoolfullrbf option for a full RBF network
>   would be holding Bitcoin Core developers responsible for the decisions
>   of individual node operators and miners. I don't think having the
>   option (again, default false) can directly cause a full RBF network,
>   and likewise, I don't think removing this option removes the "risk"
>   of a full RBF network.
>    - glozow
>      https://github.com/bitcoin/bitcoin/pull/26287#issuecomment-127494940=
0
>
>   NACK. This is a default false option.
>    - achow101
>      https://github.com/bitcoin/bitcoin/pull/26287#issuecomment-127495320=
4
>
>   Erecting artificial barriers to prevent or make it difficult for users
>   to do what they want to do, is not appropriate behaviour.
>    - luke-jr
>      https://github.com/bitcoin/bitcoin/pull/26287#issuecomment-129072190=
5
>
>   I'm in general against removing options.
>    - instagibbs
>      https://github.com/bitcoin/bitcoin/pull/26287#issuecomment-129203070=
0
>
> I think this differs from what core has done in the past, in that
> previously we've tried to ensure a new policy is good for everyone (or as
> nearly as it can be), and then enabled it as soon as it's implemented.
> Any options that have been added have either been to control resource
> usage in ways that don't significantly effect tx propagation, to
> allow people to revert to the old behaviour when the new behaviour is
> controversial (eg the -mempoolreplacement=3D0 option from 0.12 to 0.18),
> and to make it easier to test/debug the implementation.
>
> Giving people a new relay behaviour they can opt-in to when we aren't
> confident enough to turn on by default doesn't match the approach I've
> seen core take in the past.
>
>
> If this is going to be an ongoing shift in how core sees relay/mempool
> policy, I think that's significant and worth paying attention to.
>
> I don't think it's necessary to have that shift to roll out full rbf.
> The other approach would be either:
>
>  * set -mempoolfullrbf=3Dtrue as the default for 24.0, and just have the
>    command line param there in case people want to do a
>    "UserRejectedMempoolPolicy" campaign to get everyone to opt-out
>
>  * revert it for now because we don't think mainnet is ready for fullrbf
>    yet, and introduce it as default true for 25.0 or 26.0 or 27.0 or
>    to activate at some scheduled date in that timeframe (potentially
>    backporting it to previous releases to help with adoption too,
>    whatever). same effect as the previous option, just with a bit more
>    advanced notice and time to prepare
>
> I don't think anyone's proposed the first (which I interpret as "most of
> us don't think mainnet is ready for fullrbf today"), but the comments
> above are all pushback by people arguing against (the first step of)
> the second approach, and they seem to be winning the day.
>
> It's also possible that this is something of a one time thing: full rbf
> has been controversial for ages, but widely liked by devs, and other
> attempts (eg making it available in knots) haven't actually achieved
> much of a result in practice. So maybe this is just a special case and
> not a precedent, and when people propose other default false options,
> there will be substantially more resistance to them being merged,
> despite all the talk about users having options that's going on right now=
.
>
>
> Assuming it is the change of direction it appears to be -- and all of
> the above is really just justification for that assumption -- then like
> I said, I think it's worth seriously considering what it means for people
> to choose their own relay/mempool policies and for you to expect to have
> different mempool policies to many or most of your potential peers.
>
>
> One thing maybe worth noting is that is that you can still only choose
> your policy from options that people write code for -- if it wasn't
> something you could get by running knots or compiling a rejected PR
> yourself, it won't magically become more possible now.  Presumably it
> would mean that once a PR is written, it might get better review (rather
> than being dismissed as not suitable for everyone), and there would be
> less maintenance burden than if it had to be manually rebased every
> release, though (or at least the maintenance burden would be shared
> across everyone working on the codebase).
>
>
> The second thing is that whatever your relay policy is, you still
> need a path all the way to miners through nodes that will accept your
> transaction at every step. If you're making your mempool more restrictive
> (eg -permitbaremultisig=3D0, -datacarrier=3D0), that's easy for you (thou=
gh
> you're making life more difficult for people who do create those sorts
> of txs); but if you want a more permissive policy (package relay,
> version-3-rbf, full-rbf), you might need to do some work.
>
> The cutoff for that is probably something like "do 30% of listening
> nodes have a compatible policy"? If they do, then you'll have about a
> 95% chance of having at least one of your outbound peers accept your tx,
> just by random chance. If erlay allows increasing your outbound count to
> 12 connections instead of 8; that might reduce down to needing just 20%
> of listening nodes (~93%).
>
> But for cases where less than 30% (20%) of network supports your preferre=
d
> policy, you probably need to do something cleverer.
>
> One approach is to set a service bit and preferentially peer with other
> nodes that advertise that service bit; knots does the first half of this
> for fullrbf, and both halves have been proposed for core in #25600.
> Preferential peering was previously done for the segwit deployment,
> though in that case it was necessary not just for tx propogation but
> also for ensuring block propogation, making it effectively a consensus
> critical issue.
>
> Another approach is having a separate relay network -- eg, lightning node=
s
> already have a gossip network, and might want to help their own ecosystem
> by ensuring unilateral channel closes and justice transactions are quickl=
y
> relayed. Using their own gossip network to relay the transaction around,
> and each lightning node adding it to their local bitcoind's mempool and
> allowing it to propogate (or not) from there as normal, would also be a
> way of allowing transactions to propogate well. It does mean that miners
> would either need to also participate in lightning gossip directly, or
> that miners would need to connect to *many* peers to be confident of
> seeing those transactions (eg, if only 2% of the network would see a
> tx, you'd need to make 228 connections to have a 99% chance of seeing
> the tx). You can't currently do something like this, because all the
> relay policies are also applied when adding txs to the mempool via RPC,
> and there's no convenient way to remove txs from the mempool.
>
> A case where something like that might occur is in preventing L2
> transactions from pinning attacks -- so you might have a high-fee,
> low-feerate transaction that's been widely propogated, sitting in the
> bottom of people's mempools, and you want to replace it with a smaller,
> higher-feerate transaction, but don't want to pay a higher absolute fee,
> and are thus blocked by BIP 125 rule 3. Perhaps 98% of the network is
> unwilling to deviate from BIP 125 rule 3 for you; because that would
> make it easy for random griefers to spam their mempool with large txs
> then delete them while only paying a small fee; but your L2 peers may be
> able to decode your replacement transaction and be sure that you aren't
> going to spam them, and thus will happily relay it.
>
> From a technical point-of-view, that's largely fine; the downside is it
> increases the centralisation pressure on mining: whether that's by having
> to connect to substantially more nodes, or having to parse through more
> spam, you can't just run your mining operation off a standard install
> of bitcoin core anymore, but need to actively opt-in to find all the
> weird unusual ways people are sending transactions around in order to
> actually collect as much in fees as your competitors are.
>
> That's probably moderately bad for privacy as well -- if lightning or
> coinjoins need special relay rules that most nodes haven't opted into,
> it's potentially easy to use that to find the bitcoin nodes on the
> network that are participating in those protocols, and from there to
> either identify the operator, or run a DoS attack to make it hard for you
> to keep doing what you want. Obviously if you're setting a service bit to
> get better routing, you've given up that privacy already. Likewise if the
> government or random vandals are opposed to bitcoin mining, and miners
> have to have special configuration on their nodes that distinguish them
> from regular users, then perhaps that makes it easier to find or shut
> down their operations.
>
> There are a few efficiencies to be gained from similar mempool policies a=
s
> well: more reliable compact block reconstruction (if you're not missing
> any transactions, you avoid a round-trip) and presumably more efficient
> set reconstruction with erlay. You'll also waste less bandwidth sending
> transactions that the other node is only going to reject. Both those
> depend on how many transactions are going to rely on unusual mempool
> policies in the first place though.
>
> ariard wrote:
>
>   I know I've advocated in the past to turn RBF support by default in
>   the past. Though after gathering a lot of feedbacks, this approach
>   of offering the policy flexiblity to the interested users only and
>   favoring a full-rbf gradual deployment sounds better to me.
>
>   - https://github.com/bitcoin/bitcoin/pull/25353#issuecomment-1157137026
>
> I guess all the above leads me to think that gradual deployments of
> mempool policies are likely the worse approach: even when they're not
> hurting anyone, it makes them hard to use during the gradual phase,
> and getting around that comes with worrying compromises on privacy and
> centralisation; and when they are problematic for some, the indeterminate
> nature of a gradual deployment means it's hard to plan for when that
> risk is going to eventuate.
>
>
> Theoretically, one way to recover the good parts of core deciding on
> what's good for the network might be for people outside of core to
> recommend a mempool configuration; then core can just have an option
> to make that easy, similar to "-std=3Dc++17" for a C++ compiler, and much
> the same as knots' "-corepolicy" option.
>
> Presuming anyone actually wants to take on that job, and listen to the
> concerns of zeroconf businesses, lightning and coinjoin devs, miners, etc=
;
> and can come up with something that keeps most of them happy, and that
> 70% or 90% of the network ends up just following those recommendations
> because it's easy, it works, and it's recommended by all the apps they
> want to use, then that could work great:
>
>  * miners don't need to do anything special, so there's no new
>    mining centralisation pressure
>  * miners and users don't reveal what they're doing with bitcoin by the w=
ay
>    they configure their nodes, so there's no privacy problems
>  * devs can be fairly confident in how they have to design their apps
>    in order to get their transactions to most hashpower
>  * devs don't have to add new p2p layers to make it happen
>  * at least there's someone to talk to when you're trying to figure out
>    how to make some new project possible when it's inhibited by current
>    relay policies and you don't have to try to convince everyone to
>    upgrade on your own
>  * core devs just provide options, and don't have to worry about being
>    seen as gatekeepers
>
> The "downside" in that scenario is that users/dev aren't making much
> actual use of all the choices core is offering by making different
> options available; but the upside is that that choice is at least readily
> available should whoever is coming up with these policy become out of
> step with what people actually want.
>
> One thing that might make an approach like that difficult is that core
> has historically been happy to remove options that don't seem useful
> anymore: eg the ability to turn of BIP 125 support (#16171), and priority
> transactions (#9602). Perhaps that's fine if you're trying to actively
> craft a single mempool/relay policy that's good enough for almost everyon=
e
> (after all, it makes the code simpler and more efficient, and reduces
> the number of footguns); all you're doing is leaving a minority of people
> who want weird things to run a fork, and that's going to happen anyway.
>
> But if people are following policy developed outside of core, core
> might well disagree with them and decide "no that's a stupid policy,
> no one should do that" and remove some feature that others thing should
> continue to be normal. Beyond the examples above, there's already talk of
> removing the ability to disable fullrbf support in #26305, for instance.
> If that happens, then the people maintaining the policy will instead
> end up maintaining an entire fork of bitcoin core, and all we've done
> is transition to people running software from a different repo, and a
> different set of maintainers.
>
> If we're really going to a world where core's eager to add new options,
> and reluctant to remove them, at least if anyone at all finds them
> interesting, that's presumably a non-issue, though.
>
> Cheers,
> aj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><p style=3D"margin:0px;font-stretch:normal;line-height:nor=
mal;color:rgb(0,0,0)"><span style=3D"font-variant-ligatures:no-common-ligat=
ures"><font face=3D"arial, sans-serif">Hi AJ,</font></span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">Let&#39;s take the contra.</font></span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">I would say the current post describes the state of =
Bitcoin Core and beyond=C2=A0</font></span><span style=3D"font-family:arial=
,sans-serif">policy rules with a high-degree of exhaustivity and completene=
ss, though it</span><span style=3D"font-family:arial,sans-serif">t what is,=
 mostly a description. While I think it ends with a set of recommendations=
=C2=A0</span><span style=3D"font-family:arial,sans-serif">on what could be =
the relations between miners, devs and node operators w.r.t=C2=A0</span><sp=
an style=3D"font-variant-ligatures:no-common-ligatures"><font face=3D"arial=
, sans-serif">adopting policy rules, to me it doesn&#39;t explore enough th=
e hard part of the subject.=C2=A0</font></span><span style=3D"font-family:a=
rial,sans-serif">What should be actually the design goals and principles of=
 Core&#39;s transaction-relay propagation rules</span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">of which mempool accepts ones is a subset ? By such =
design goals, I&#39;m thinking=C2=A0</font></span><span style=3D"font-famil=
y:arial,sans-serif">either, a qualitative framework, like attacks game for =
a concrete application (&quot;Can</span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">we prevent pinning against multi-party Coinjoin ?&qu=
ot;). Or a quantitative approach, e.g=C2=A0</font></span><span style=3D"fon=
t-family:arial,sans-serif">how fast should be transaction-relay throughput =
for a given topology, or how much=C2=A0</span><span style=3D"font-family:ar=
ial,sans-serif">accurate is the block template against usual blocks [0]</sp=
an></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><br></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">Assuming we would have technical principles and goal=
s guiding our development process, o</font></span><span style=3D"font-famil=
y:arial,sans-serif">f which the discussion and revision should be an inhere=
nt part of the process itself,</span><span class=3D"gmail-Apple-converted-s=
pace" style=3D"font-family:arial,sans-serif">=C2=A0=C2=A0</span><span style=
=3D"font-family:arial,sans-serif">I believe we would come up with a second-=
order observation. That we might not be able=C2=A0</span><span style=3D"fon=
t-family:arial,sans-serif">to satisfy every use-case with the standard set =
of </span>policy rules<span style=3D"font-family:arial,sans-serif">. E.g, a=
 contracting=C2=A0</span><span style=3D"font-family:arial,sans-serif">proto=
col could look for package size beyond the upper bound anti-Dos limit. Or e=
ven=C2=A0</span><span style=3D"font-family:arial,sans-serif">the global res=
sources offered by the network of full-nodes are not high enough to handle=
=C2=A0</span><span style=3D"font-family:arial,sans-serif">some application =
</span>event<span style=3D"font-family:arial,sans-serif">. E.g a Lightning =
Service Provider doing a liquidity maintenance=C2=A0</span><span style=3D"f=
ont-family:arial,sans-serif">round of all its counterparties, and as such f=
orce-closing and broadcasting more transactions=C2=A0</span><span style=3D"=
font-family:arial,sans-serif">than can be handled at the transaction-relay =
layer due to default MAX_PEER_TX_ANNOUNCEMENTS=C2=A0</span><span style=3D"f=
ont-family:arial,sans-serif">value.</span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">My personal take on those subjects, we might have to=
 realize we&#39;re facing an heterogeneity o</font></span><span style=3D"fo=
nt-family:arial,sans-serif">f Bitcoin applications and use-cases [1]. And t=
his sounds like a long-term upward trend, akin=C2=A0</span><span style=3D"f=
ont-family:arial,sans-serif">to the history of the Internet: mail clients, =
web browser, streaming applications, etc, all=C2=A0</span><span style=3D"fo=
nt-family:arial,sans-serif">with different service-level requirements in te=
rms of latency, jitters and bandwidth. We=C2=A0</span><span style=3D"font-f=
amily:arial,sans-serif">might observe that Bitcoin actors might adopt indiv=
idual strategies for the </span>consumption<span style=3D"font-family:arial=
,sans-serif"> of it.=C2=A0</span><span style=3D"font-family:arial,sans-seri=
f">E.g a multi-party contracting protocol with asymmetric states, a counter=
party could &quot;front-run&quot;=C2=A0</span><span style=3D"font-family:ar=
ial,sans-serif">the others at the transaction-relay to avoid encumbering th=
e RBF penalty in case of concurrent=C2=A0</span><span style=3D"font-family:=
arial,sans-serif">broadcast. Or they could deploy an additive layer of comm=
unication channels, like private=C2=A0</span><span style=3D"font-family:ari=
al,sans-serif">transaction-relay to miners, e.g a LN node broadcasting a HT=
LC-preimage and </span>restraining=C2=A0<span style=3D"font-family:arial,sa=
ns-serif">the odds of mapping to an off-chain payment path. Those additive =
layers of communication=C2=A0</span><span style=3D"font-family:arial,sans-s=
erif">can be also seen as mitigations against components failure risks, e.g=
 a transaction-relay</span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">censorship vector in the p2p stack. To put it simply=
, some advanced Bitcoin applications=C2=A0</font></span><span style=3D"font=
-family:arial,sans-serif">might have to outgrow the &quot;mempool policy ru=
les&quot; game, as we&#39;re currently defining it to=C2=A0</span><span sty=
le=3D"font-family:arial,sans-serif">satisfy to a higher degree their securi=
ty and operational models. I think this has been=C2=A0</span><span style=3D=
"font-family:arial,sans-serif">historically the case with some miners decid=
ing to join FIBER, to improve their view of=C2=A0</span><span style=3D"font=
-family:arial,sans-serif">mined blocks.</span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">While I still think we can come up with clear policy=
 rules for some ideal or reasonable=C2=A0</font></span><span style=3D"font-=
family:arial,sans-serif">use-case (let&#39;s say the Bitcoin hobbyist aimin=
g to strong censorship-resistance of its</span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">payment). And I hold the belief we can improve on th=
at front, as we&#39;ve done during the=C2=A0</font></span><span style=3D"fo=
nt-family:arial,sans-serif">past years by formalizing a subset of policy ru=
les in Bitcoin Core documentation. In</span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">parallel, we might acknowledge the heterogeneity of =
use-cases, and that we cannot offer=C2=A0</font></span><span style=3D"font-=
family:arial,sans-serif">the same level of censorship-resistance, privacy o=
r cost-effectiveness (And that might=C2=A0</span><span style=3D"font-family=
:arial,sans-serif">be okay if we remember that e.g censorship-resistance be=
tween a simple Bitcoin payment=C2=A0</span><span style=3D"font-family:arial=
,sans-serif">and a Lightning HTLC isn&#39;t defined the same, due to the us=
age of timelocks by the latter).</span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">What I&#39;m expressing is a long-term perspective, =
and we might be too early in the=C2=A0</font></span><span style=3D"font-fam=
ily:arial,sans-serif">evolutionary process that is Bitcoin Core development=
 to abandon yet the &quot;one-size-fits-all&quot;</span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">policy rules conception that I understand from your =
post. Though to me, as we progress=C2=A0</font></span><span style=3D"font-f=
amily:arial,sans-serif">on modularity and flexibility of the Core codebase,=
 we might have to envision a Bitcoin=C2=A0</span><span style=3D"font-family=
:arial,sans-serif">ecosystem where configuring a client is on the same bar =
as the kernel Kconfig (hopefully=C2=A0</span><span style=3D"font-family:ari=
al,sans-serif">not because no drivers/ but still..). Of course, you can hav=
e &quot;blessed&quot; config to=C2=A0</span><span style=3D"font-family:aria=
l,sans-serif">avoid the complexity turning away node operators and users, t=
hough at the price of=C2=A0</span><span style=3D"font-family:arial,sans-ser=
if">increasing the trust in your vendors.</span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">More concretely, about the issue of today, full-rbf,=
 I think the lack of design=C2=A0</font></span><span style=3D"font-family:a=
rial,sans-serif">heuristic in the sense of what should be the reasonable or=
 average use-case</span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">supported by the Bitcoin base-layer transaction-rela=
y rules. Should we favor the=C2=A0</font></span><span style=3D"font-family:=
arial,sans-serif">historical ones (0confs) or the new incumbent (contractin=
g protocols) ? There=C2=A0</span><span style=3D"font-family:arial,sans-seri=
f">is always the &quot;First, do not harm&quot; principle in lack of clear =
guidelines in any=C2=A0</span><span style=3D"font-family:arial,sans-serif">=
area of Bitcoin protocol development. Though when we&#39;re facing risk arb=
itrage=C2=A0</span><span style=3D"font-variant-ligatures:no-common-ligature=
s"><font face=3D"arial, sans-serif">like the current one, I don&#39;t think=
 as protocol devs we have any strong reasoning=C2=A0</font></span><span sty=
le=3D"font-family:arial,sans-serif">framework. Deferring the decision to th=
e node operators as the approach is with=C2=A0</span><span style=3D"font-fa=
mily:arial,sans-serif">#25353 + #25000, did acknowledge the uncharted terri=
tory we&#39;re in with policy rules=C2=A0</span><span style=3D"font-family:=
arial,sans-serif">deprecation or novation. Qualifying the gradual approach =
of &quot;worst&quot; sounds to me that=C2=A0</span><span style=3D"font-fami=
ly:arial,sans-serif">every policy rule will ever have to design or deploy w=
ill suffer from the same trade-off=C2=A0</span><span style=3D"font-family:a=
rial,sans-serif">of full-rbf. A gradual approach could be a really realisti=
c way to move </span>forward<span style=3D"font-family:arial,sans-serif"> w=
ith=C2=A0</span><span style=3D"font-family:arial,sans-serif">some experimen=
tal package formats or Dandelion-like transaction </span>dissemination<span=
 style=3D"font-family:arial,sans-serif"> strategy.=C2=A0</span><span style=
=3D"font-family:arial,sans-serif">Such gradual approach of full-rbf deploym=
ent was also aiming to set the </span>precedent=C2=A0<span style=3D"font-fa=
mily:arial,sans-serif">that in a situation of risk arbitrage, with </span>i=
rreconcilable<span style=3D"font-family:arial,sans-serif"> views between cl=
ass of use-cases=C2=A0</span><span style=3D"font-family:arial,sans-serif">o=
perators, the decision shouldn&#39;t be in the scope of Bitcoin Core.</span=
></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">Hopefully, with a renewed effort of communication in=
 the case of full-rbf, we can accommodate the=C2=A0</font></span><span styl=
e=3D"font-family:arial,sans-serif">maximum of use-cases risks model and mov=
e towards a coordinated approach, offering a visible=C2=A0</span>and predic=
table<span style=3D"font-family:arial,sans-serif"> timeline. Though if we f=
ail to reach &quot;consensus&quot; there, we might have to=C2=A0</span><spa=
n style=3D"font-family:arial,sans-serif">fallback on the &quot;gradual&quot=
; approach, stating the full-rbf case is beyond the responsibility=C2=A0</s=
pan>of scope<span style=3D"font-family:arial,sans-serif"> of Bitcoin Core.<=
/span></p><p style=3D"margin:0px;font-stretch:normal;line-height:normal;col=
or:rgb(0,0,0)"><span style=3D"font-family:arial,sans-serif"><br></span></p>=
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-family:arial,sans-serif">Overall, many thanks for =
this thoughtful post. Good for me to uplift the level of the discussion whe=
n we&#39;re hitting some bottleneck in our development process.</span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">Best,</font></span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">Antoine</font></span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">[0]=C2=A0</font></span><span style=3D"color:rgb(34,3=
4,34)"><a href=3D"https://github.com/bitcoin/bitcoin/issues/19820">https://=
github.com/bitcoin/bitcoin/issues/19820</a></span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">[1] To be clear, this the opposite view I did expres=
s in :=C2=A0</font></span><span style=3D"color:rgb(34,34,34)"><a href=3D"ht=
tps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-July/018063.html=
">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-July/018063.=
html</a></span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">After exposure and exploration of more Bitcoin use-c=
ases and applications, and even among=C2=A0</font></span><span style=3D"fon=
t-family:arial,sans-serif">the different requirement among types of use-cas=
es nodes (e.g LN mobile vs LSP), I believe=C2=A0</span><span style=3D"font-=
family:arial,sans-serif">more heterogeneity in the policy rules usage makes=
 more sense</span></p>
<br class=3D"gmail-Apple-interchange-newline"></div><br><div class=3D"gmail=
_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0jeu. 27 oct. 2022 =C3=
=A0=C2=A000:52, Anthony Towns via bitcoin-dev &lt;<a href=3D"mailto:bitcoin=
-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&g=
t; a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;bord=
er-left-color:rgb(204,204,204);padding-left:1ex">Hi *,<br>
<br>
TLDR: Yes, this post is too long, and there&#39;s no TLDR. If it&#39;s any<=
br>
consolation, it took longer to write than it does to read?<br>
<br>
On Tue, Jun 15, 2021 at 12:55:14PM -0400, Antoine Riard via bitcoin-dev wro=
te:<br>
&gt; Subject: Re: [bitcoin-dev] Proposal: Full-RBF in Bitcoin Core 24.0<br>
&gt; I&#39;m writing to propose deprecation of opt-in RBF in favor of full-=
RBF<br>
<br>
&gt; If there is ecosystem agreement on switching to full-RBF, but 0.24 sou=
nds<br>
&gt; too early, let&#39;s defer it to 0.25 or 0.26. I don&#39;t think Core =
has a<br>
&gt; consistent deprecation process w.r.t to policy rules heavily relied-on=
 by<br>
&gt; Bitcoin users, if we do so let sets a precedent satisfying as many fol=
ks as<br>
&gt; we can.<br>
<br>
One precedent that seems to be being set here, which to me seems fairly<br>
novel for bitcoin core, is that we&#39;re about to start supporting and<br>
encouraging nodes to have meaningfully different mempool policies. From<br>
what I&#39;ve seen, the baseline expectation has always been that while<br>
certainly mempools can and will differ, policies will be largely the same:<=
br>
<br>
=C2=A0 Firstly, there is no &quot;the mempool&quot;. There is no global mem=
pool. Rather<br>
=C2=A0 each node maintains its own mempool and accepts and rejects transact=
ion<br>
=C2=A0 to that mempool using their own internal policies. Most nodes have<b=
r>
=C2=A0 the same policies, but due to different start times, relay delays,<b=
r>
=C2=A0 and other factors, not every node has the same mempool, although the=
y<br>
=C2=A0 may be very similar.<br>
<br>
=C2=A0 - <a href=3D"https://bitcoin.stackexchange.com/questions/98585/how-t=
o-find-if-two-transactions-in-mempool-are-conflicting" rel=3D"noreferrer" t=
arget=3D"_blank">https://bitcoin.stackexchange.com/questions/98585/how-to-f=
ind-if-two-transactions-in-mempool-are-conflicting</a><br>
<br>
Up until now, the differences between node policies supported by different<=
br>
nodes running core have been quite small, with essentially the following<br=
>
options available:<br>
<br>
=C2=A0-minrelaytxfee, -maxmempool - changes the lowest fee rate you&#39;ll =
accept<br>
<br>
=C2=A0-mempoolexpiry - how long to keep txs in the mempool<br>
<br>
=C2=A0-datacarrier - reject txs creating OP_RETURN outputs<br>
<br>
=C2=A0-datacarriersize - maximum size of OP_RETURN data<br>
<br>
=C2=A0-permitbaremultisig - prevent relay of bare multisig<br>
<br>
=C2=A0-bytespersigop - changes how SIGOP accounting works for relay and<br>
=C2=A0mining prioritisation<br>
<br>
as well as these, marked as &quot;debug only&quot; options (only shown with=
<br>
-help-debug):<br>
<br>
=C2=A0-incrementalrelayfee - make it easier/harder to spam txs by only<br>
=C2=A0slightly bumping the fee; marked as a &quot;debug only&quot; option<b=
r>
<br>
=C2=A0-dustrelayfee - make it easier/harder to create uneconomic utxos;<br>
=C2=A0marked as a &quot;debug only&quot; option<br>
<br>
=C2=A0-limit{descendant,ancestor}{count,size} - changes how large the<br>
=C2=A0transaction chains can be; marked as a &quot;debug only&quot; option<=
br>
<br>
and in theory, but not available on mainnet:<br>
<br>
=C2=A0-acceptnonstdtxn - relay/mine non standard transactions<br>
<br>
There&#39;s also the &quot;prioritisetransaction&quot; rpc, which can cause=
 you to keep<br>
a low feerate transaction in your mempool longer than you might otherwise.<=
br>
<br>
I think that -minrelaytxfee, -maxmempool and -mempoolexpiry are the only<br=
>
ones of those options commonly set, and those only rarely result in any<br>
differences in the txs at the top of the mempool.<br>
<br>
There are also quite a few parameters that aren&#39;t even runtime<br>
configurable:<br>
<br>
=C2=A0- MAX_STANDARD_TX_WEIGHT<br>
=C2=A0- MIN_STANDARD_TX_NONWITNESS_SIZE (see also #26265)<br>
=C2=A0- MAX_P2SH_SIGOPS (see also #26348)<br>
=C2=A0- MAX_STANDARD_TX_SIGOPS_COST<br>
=C2=A0- MAX_STANDARD_P2WSH_STACK_ITEMS<br>
=C2=A0- MAX_STANDARD_P2WSH_STACK_ITEM_SIZE<br>
=C2=A0- MAX_STANDARD_TAPSCRIPT_STACK_ITEM_SIZE<br>
=C2=A0- MAX_STANDARD_P2WSH_SCRIPT_SIZE<br>
=C2=A0- MAX_STANDARD_SCRIPTSIG_SIZE<br>
=C2=A0- EXTRA_DESCENDANT_TX_SIZE_LIMIT<br>
=C2=A0- MAX_REPLACEMENT_CANDIDATES<br>
<br>
And other plausible options aren&#39;t configurable even at compile time<br=
>
-- eg, core doesn&#39;t implement BIP 125&#39;s inherited signalling rule s=
o<br>
there&#39;s no way to enable it; core doesn&#39;t allow opting out of BIP 1=
25<br>
rule 3 ratchet on absolute fee; core doesn&#39;t allow CPFP carveout with<b=
r>
more than 1 ancestor; core doesn&#39;t allow opting out of LOW_S checks<br>
(even via -acceptnonstdtxn); etc.<br>
<br>
We also naturally have different mempool policies between different<br>
releases: eg, expansions of policy, such as allowing OP_RETURN or<br>
expanding it from 40 to 80 bytes or new soft forks where old nodes won&#39;=
t<br>
relay transactions that use the new; and also occassional restrictions<br>
in policy, such as the LOW_S requirement.<br>
<br>
<br>
While supporting and encouraging different mempool polices might be new<br>
for core, it&#39;s not new for knots: knots changes some of these defaults<=
br>
(-permitbaremultisig defaults to false, -datacarriersize is reduced to<br>
42), allows the use of -acceptnonstdtxn on mainnet, and introduces new<br>
options including -spkreuse and -mempoolreplacement (giving the latter<br>
full rbf behaviour by default). Knots also includes a `-corepolicy`<br>
option to make it easy to get a configuration matching core&#39;s defaults.=
<br>
<br>
<br>
I think gmaxwell&#39;s take from Feb 2015 (in the context of how restrictiv=
e<br>
policy on OP_RETURN data should be) was a reasonable description for<br>
core&#39;s approach up until now:<br>
<br>
=C2=A0 There is also a matter of driving competent design rather than lazy<=
br>
=C2=A0 first thing that works. E.g. In stealth addresses the early proposal=
s<br>
=C2=A0 use highly inefficient single ECDH point per output instead of simpl=
y<br>
=C2=A0 pooling them. Network behavior is one of the few bits of friction<br=
>
=C2=A0 driving good technical design rather than &quot;move fast, break thi=
ngs, and<br>
=C2=A0 force everyone else onto my way of doing thing rather than discussin=
g<br>
=C2=A0 the design in public&quot;. No one wants to be an outright gatekeepe=
r,<br>
=C2=A0 but the network is a shared resource and it&#39;s perfectly reasonab=
le<br>
=C2=A0 node behavior to be stingy about the perpetual storage impact of the=
<br>
=C2=A0 transactions they&#39;re willing to process, especially when it come=
s to<br>
=C2=A0 neutral technical criteria like the amount of network irrelevant dat=
a<br>
=C2=A0 stuffed in transactions.<br>
<br>
=C2=A0 There is also a very clear pattern we&#39;ve seen in the past where<=
br>
=C2=A0 people take anything the system lets them do as strong evidence that=
<br>
=C2=A0 they have a irrevocable right to use the system in that way, and tha=
t<br>
=C2=A0 their only responsibility-- and if their usage harms the system it&#=
39;s<br>
=C2=A0 the responsibility of the system to not permit it. [...<br>
=C2=A0 ...] For mitigating these risks it&#39;s optimal if transactions<br>
=C2=A0 seem as uniform and indistinguishable as reasonably possible.<br>
<br>
=C2=A0 - <a href=3D"https://github.com/bitcoin/bitcoin/pull/5286#issuecomme=
nt-72564175" rel=3D"noreferrer" target=3D"_blank">https://github.com/bitcoi=
n/bitcoin/pull/5286#issuecomment-72564175</a><br>
<br>
Perhaps see also sdaftuar in Nov 2015,<br>
<br>
=C2=A0 To me the most important question is, is priority something that min=
ers<br>
=C2=A0 want to use?<br>
<br>
=C2=A0 If a non-negligible amount of hashpower intends to use it in their<b=
r>
=C2=A0 transaction selection, then I think it makes sense for nodes to use =
it<br>
=C2=A0 too, because it&#39;s generally helpful to have your mempool predict=
 the<br>
=C2=A0 UTXO as much as possible, and for nodes to be able to have reasonabl=
e<br>
=C2=A0 fee and priority estimates (which won&#39;t happen unless they track=
 the<br>
=C2=A0 priority transactions somehow -- I&#39;m presuming that miners run w=
ith<br>
=C2=A0 much bigger mempools than regular nodes).<br>
<br>
=C2=A0 If the answer is no, then that&#39;s fine and I don&#39;t see a reas=
on to push<br>
=C2=A0 in this direction. I sort of assumed there was enough hashpower mini=
ng<br>
=C2=A0 with priority, since last time I checked estimatepriority was still<=
br>
=C2=A0 giving meaningful results for low-ish blockheights, but I haven&#39;=
t done<br>
=C2=A0 any kind of real analysis.<br>
<br>
=C2=A0 - <a href=3D"https://github.com/bitcoin/bitcoin/pull/6992#issuecomme=
nt-155969455" rel=3D"noreferrer" target=3D"_blank">https://github.com/bitco=
in/bitcoin/pull/6992#issuecomment-155969455</a><br>
<br>
or in June 2019,<br>
<br>
=C2=A0 What this PR is proposing is to get rid of a command-line option tha=
t is<br>
=C2=A0 (a) a footgun for users and (b) does not reflect what I believe to b=
e<br>
=C2=A0 the understanding most users have, which is that [X txs] are expecte=
d<br>
=C2=A0 to propagate well on the network.<br>
<br>
=C2=A0 ..<br>
<br>
=C2=A0 I don&#39;t think this rises to the level that Luke is concerned abo=
ut,<br>
=C2=A0 namely a prelude to forcing a common relay policy on all nodes. In<b=
r>
=C2=A0 particular I do agree it makes sense that we offer some ways of<br>
=C2=A0 customizing policy parameters (eg the mempool size, min relay fee,<b=
r>
=C2=A0 etc). Instead, I think the justification for this change is that we<=
br>
=C2=A0 should not support behaviors we think are harmful to the ecosystem<b=
r>
=C2=A0 overall and have no legitimate use-case, and we should eliminate way=
s<br>
=C2=A0 that users might inadvertently shoot themselves in the foot.<br>
<br>
=C2=A0 - <a href=3D"https://github.com/bitcoin/bitcoin/pull/16171#issuecomm=
ent-500393271" rel=3D"noreferrer" target=3D"_blank">https://github.com/bitc=
oin/bitcoin/pull/16171#issuecomment-500393271</a><br>
<br>
(or see discussion in <a href=3D"https://github.com/bitcoin/bitcoin/pull/72=
19" rel=3D"noreferrer" target=3D"_blank">https://github.com/bitcoin/bitcoin=
/pull/7219</a>)<br>
<br>
I don&#39;t mean to imply the above are saying &quot;there&#39;s one way to=
 do<br>
things and it&#39;s this way&quot;, or that the old way of doing things sho=
uld<br>
necessarily be the way we keep doing things. Just that previously core<br>
has tended towards designing a single policy that works as well as it<br>
can for everyone and the ecosystem as a whole. (I&#39;m also not saying tha=
t<br>
fullrbf can&#39;t work well for everyone or the ecosystem as a whole)<br>
<br>
<br>
By contrast, I think the most common response to pushback against the<br>
full rbf option has been along the lines of &quot;it&#39;s just an option, =
we<br>
don&#39;t want to force people&quot;, eg:<br>
<br>
=C2=A0 Blaming the default false -mempoolfullrbf option for a full RBF netw=
ork<br>
=C2=A0 would be holding Bitcoin Core developers responsible for the decisio=
ns<br>
=C2=A0 of individual node operators and miners. I don&#39;t think having th=
e<br>
=C2=A0 option (again, default false) can directly cause a full RBF network,=
<br>
=C2=A0 and likewise, I don&#39;t think removing this option removes the &qu=
ot;risk&quot;<br>
=C2=A0 of a full RBF network.<br>
=C2=A0 =C2=A0- glozow<br>
=C2=A0 =C2=A0 =C2=A0<a href=3D"https://github.com/bitcoin/bitcoin/pull/2628=
7#issuecomment-1274949400" rel=3D"noreferrer" target=3D"_blank">https://git=
hub.com/bitcoin/bitcoin/pull/26287#issuecomment-1274949400</a><br>
<br>
=C2=A0 NACK. This is a default false option.<br>
=C2=A0 =C2=A0- achow101<br>
=C2=A0 =C2=A0 =C2=A0<a href=3D"https://github.com/bitcoin/bitcoin/pull/2628=
7#issuecomment-1274953204" rel=3D"noreferrer" target=3D"_blank">https://git=
hub.com/bitcoin/bitcoin/pull/26287#issuecomment-1274953204</a><br>
<br>
=C2=A0 Erecting artificial barriers to prevent or make it difficult for use=
rs<br>
=C2=A0 to do what they want to do, is not appropriate behaviour.<br>
=C2=A0 =C2=A0- luke-jr<br>
=C2=A0 =C2=A0 =C2=A0<a href=3D"https://github.com/bitcoin/bitcoin/pull/2628=
7#issuecomment-1290721905" rel=3D"noreferrer" target=3D"_blank">https://git=
hub.com/bitcoin/bitcoin/pull/26287#issuecomment-1290721905</a><br>
<br>
=C2=A0 I&#39;m in general against removing options.<br>
=C2=A0 =C2=A0- instagibbs<br>
=C2=A0 =C2=A0 =C2=A0<a href=3D"https://github.com/bitcoin/bitcoin/pull/2628=
7#issuecomment-1292030700" rel=3D"noreferrer" target=3D"_blank">https://git=
hub.com/bitcoin/bitcoin/pull/26287#issuecomment-1292030700</a><br>
<br>
I think this differs from what core has done in the past, in that<br>
previously we&#39;ve tried to ensure a new policy is good for everyone (or =
as<br>
nearly as it can be), and then enabled it as soon as it&#39;s implemented.<=
br>
Any options that have been added have either been to control resource<br>
usage in ways that don&#39;t significantly effect tx propagation, to<br>
allow people to revert to the old behaviour when the new behaviour is<br>
controversial (eg the -mempoolreplacement=3D0 option from 0.12 to 0.18),<br=
>
and to make it easier to test/debug the implementation.<br>
<br>
Giving people a new relay behaviour they can opt-in to when we aren&#39;t<b=
r>
confident enough to turn on by default doesn&#39;t match the approach I&#39=
;ve<br>
seen core take in the past.<br>
<br>
<br>
If this is going to be an ongoing shift in how core sees relay/mempool<br>
policy, I think that&#39;s significant and worth paying attention to.<br>
<br>
I don&#39;t think it&#39;s necessary to have that shift to roll out full rb=
f.<br>
The other approach would be either:<br>
<br>
=C2=A0* set -mempoolfullrbf=3Dtrue as the default for 24.0, and just have t=
he<br>
=C2=A0 =C2=A0command line param there in case people want to do a<br>
=C2=A0 =C2=A0&quot;UserRejectedMempoolPolicy&quot; campaign to get everyone=
 to opt-out<br>
<br>
=C2=A0* revert it for now because we don&#39;t think mainnet is ready for f=
ullrbf<br>
=C2=A0 =C2=A0yet, and introduce it as default true for 25.0 or 26.0 or 27.0=
 or<br>
=C2=A0 =C2=A0to activate at some scheduled date in that timeframe (potentia=
lly<br>
=C2=A0 =C2=A0backporting it to previous releases to help with adoption too,=
<br>
=C2=A0 =C2=A0whatever). same effect as the previous option, just with a bit=
 more<br>
=C2=A0 =C2=A0advanced notice and time to prepare<br>
<br>
I don&#39;t think anyone&#39;s proposed the first (which I interpret as &qu=
ot;most of<br>
us don&#39;t think mainnet is ready for fullrbf today&quot;), but the comme=
nts<br>
above are all pushback by people arguing against (the first step of)<br>
the second approach, and they seem to be winning the day.<br>
<br>
It&#39;s also possible that this is something of a one time thing: full rbf=
<br>
has been controversial for ages, but widely liked by devs, and other<br>
attempts (eg making it available in knots) haven&#39;t actually achieved<br=
>
much of a result in practice. So maybe this is just a special case and<br>
not a precedent, and when people propose other default false options,<br>
there will be substantially more resistance to them being merged,<br>
despite all the talk about users having options that&#39;s going on right n=
ow.<br>
<br>
<br>
Assuming it is the change of direction it appears to be -- and all of<br>
the above is really just justification for that assumption -- then like<br>
I said, I think it&#39;s worth seriously considering what it means for peop=
le<br>
to choose their own relay/mempool policies and for you to expect to have<br=
>
different mempool policies to many or most of your potential peers.<br>
<br>
<br>
One thing maybe worth noting is that is that you can still only choose<br>
your policy from options that people write code for -- if it wasn&#39;t<br>
something you could get by running knots or compiling a rejected PR<br>
yourself, it won&#39;t magically become more possible now.=C2=A0 Presumably=
 it<br>
would mean that once a PR is written, it might get better review (rather<br=
>
than being dismissed as not suitable for everyone), and there would be<br>
less maintenance burden than if it had to be manually rebased every<br>
release, though (or at least the maintenance burden would be shared<br>
across everyone working on the codebase).<br>
<br>
<br>
The second thing is that whatever your relay policy is, you still<br>
need a path all the way to miners through nodes that will accept your<br>
transaction at every step. If you&#39;re making your mempool more restricti=
ve<br>
(eg -permitbaremultisig=3D0, -datacarrier=3D0), that&#39;s easy for you (th=
ough<br>
you&#39;re making life more difficult for people who do create those sorts<=
br>
of txs); but if you want a more permissive policy (package relay,<br>
version-3-rbf, full-rbf), you might need to do some work.<br>
<br>
The cutoff for that is probably something like &quot;do 30% of listening<br=
>
nodes have a compatible policy&quot;? If they do, then you&#39;ll have abou=
t a<br>
95% chance of having at least one of your outbound peers accept your tx,<br=
>
just by random chance. If erlay allows increasing your outbound count to<br=
>
12 connections instead of 8; that might reduce down to needing just 20%<br>
of listening nodes (~93%).<br>
<br>
But for cases where less than 30% (20%) of network supports your preferred<=
br>
policy, you probably need to do something cleverer.<br>
<br>
One approach is to set a service bit and preferentially peer with other<br>
nodes that advertise that service bit; knots does the first half of this<br=
>
for fullrbf, and both halves have been proposed for core in #25600.<br>
Preferential peering was previously done for the segwit deployment,<br>
though in that case it was necessary not just for tx propogation but<br>
also for ensuring block propogation, making it effectively a consensus<br>
critical issue.<br>
<br>
Another approach is having a separate relay network -- eg, lightning nodes<=
br>
already have a gossip network, and might want to help their own ecosystem<b=
r>
by ensuring unilateral channel closes and justice transactions are quickly<=
br>
relayed. Using their own gossip network to relay the transaction around,<br=
>
and each lightning node adding it to their local bitcoind&#39;s mempool and=
<br>
allowing it to propogate (or not) from there as normal, would also be a<br>
way of allowing transactions to propogate well. It does mean that miners<br=
>
would either need to also participate in lightning gossip directly, or<br>
that miners would need to connect to *many* peers to be confident of<br>
seeing those transactions (eg, if only 2% of the network would see a<br>
tx, you&#39;d need to make 228 connections to have a 99% chance of seeing<b=
r>
the tx). You can&#39;t currently do something like this, because all the<br=
>
relay policies are also applied when adding txs to the mempool via RPC,<br>
and there&#39;s no convenient way to remove txs from the mempool.<br>
<br>
A case where something like that might occur is in preventing L2<br>
transactions from pinning attacks -- so you might have a high-fee,<br>
low-feerate transaction that&#39;s been widely propogated, sitting in the<b=
r>
bottom of people&#39;s mempools, and you want to replace it with a smaller,=
<br>
higher-feerate transaction, but don&#39;t want to pay a higher absolute fee=
,<br>
and are thus blocked by BIP 125 rule 3. Perhaps 98% of the network is<br>
unwilling to deviate from BIP 125 rule 3 for you; because that would<br>
make it easy for random griefers to spam their mempool with large txs<br>
then delete them while only paying a small fee; but your L2 peers may be<br=
>
able to decode your replacement transaction and be sure that you aren&#39;t=
<br>
going to spam them, and thus will happily relay it.<br>
<br>
From a technical point-of-view, that&#39;s largely fine; the downside is it=
<br>
increases the centralisation pressure on mining: whether that&#39;s by havi=
ng<br>
to connect to substantially more nodes, or having to parse through more<br>
spam, you can&#39;t just run your mining operation off a standard install<b=
r>
of bitcoin core anymore, but need to actively opt-in to find all the<br>
weird unusual ways people are sending transactions around in order to<br>
actually collect as much in fees as your competitors are.<br>
<br>
That&#39;s probably moderately bad for privacy as well -- if lightning or<b=
r>
coinjoins need special relay rules that most nodes haven&#39;t opted into,<=
br>
it&#39;s potentially easy to use that to find the bitcoin nodes on the<br>
network that are participating in those protocols, and from there to<br>
either identify the operator, or run a DoS attack to make it hard for you<b=
r>
to keep doing what you want. Obviously if you&#39;re setting a service bit =
to<br>
get better routing, you&#39;ve given up that privacy already. Likewise if t=
he<br>
government or random vandals are opposed to bitcoin mining, and miners<br>
have to have special configuration on their nodes that distinguish them<br>
from regular users, then perhaps that makes it easier to find or shut<br>
down their operations.<br>
<br>
There are a few efficiencies to be gained from similar mempool policies as<=
br>
well: more reliable compact block reconstruction (if you&#39;re not missing=
<br>
any transactions, you avoid a round-trip) and presumably more efficient<br>
set reconstruction with erlay. You&#39;ll also waste less bandwidth sending=
<br>
transactions that the other node is only going to reject. Both those<br>
depend on how many transactions are going to rely on unusual mempool<br>
policies in the first place though.<br>
<br>
ariard wrote:<br>
<br>
=C2=A0 I know I&#39;ve advocated in the past to turn RBF support by default=
 in<br>
=C2=A0 the past. Though after gathering a lot of feedbacks, this approach<b=
r>
=C2=A0 of offering the policy flexiblity to the interested users only and<b=
r>
=C2=A0 favoring a full-rbf gradual deployment sounds better to me.<br>
<br>
=C2=A0 - <a href=3D"https://github.com/bitcoin/bitcoin/pull/25353#issuecomm=
ent-1157137026" rel=3D"noreferrer" target=3D"_blank">https://github.com/bit=
coin/bitcoin/pull/25353#issuecomment-1157137026</a><br>
<br>
I guess all the above leads me to think that gradual deployments of<br>
mempool policies are likely the worse approach: even when they&#39;re not<b=
r>
hurting anyone, it makes them hard to use during the gradual phase,<br>
and getting around that comes with worrying compromises on privacy and<br>
centralisation; and when they are problematic for some, the indeterminate<b=
r>
nature of a gradual deployment means it&#39;s hard to plan for when that<br=
>
risk is going to eventuate.<br>
<br>
<br>
Theoretically, one way to recover the good parts of core deciding on<br>
what&#39;s good for the network might be for people outside of core to<br>
recommend a mempool configuration; then core can just have an option<br>
to make that easy, similar to &quot;-std=3Dc++17&quot; for a C++ compiler, =
and much<br>
the same as knots&#39; &quot;-corepolicy&quot; option.<br>
<br>
Presuming anyone actually wants to take on that job, and listen to the<br>
concerns of zeroconf businesses, lightning and coinjoin devs, miners, etc;<=
br>
and can come up with something that keeps most of them happy, and that<br>
70% or 90% of the network ends up just following those recommendations<br>
because it&#39;s easy, it works, and it&#39;s recommended by all the apps t=
hey<br>
want to use, then that could work great:<br>
<br>
=C2=A0* miners don&#39;t need to do anything special, so there&#39;s no new=
<br>
=C2=A0 =C2=A0mining centralisation pressure<br>
=C2=A0* miners and users don&#39;t reveal what they&#39;re doing with bitco=
in by the way<br>
=C2=A0 =C2=A0they configure their nodes, so there&#39;s no privacy problems=
<br>
=C2=A0* devs can be fairly confident in how they have to design their apps<=
br>
=C2=A0 =C2=A0in order to get their transactions to most hashpower<br>
=C2=A0* devs don&#39;t have to add new p2p layers to make it happen<br>
=C2=A0* at least there&#39;s someone to talk to when you&#39;re trying to f=
igure out<br>
=C2=A0 =C2=A0how to make some new project possible when it&#39;s inhibited =
by current<br>
=C2=A0 =C2=A0relay policies and you don&#39;t have to try to convince every=
one to<br>
=C2=A0 =C2=A0upgrade on your own<br>
=C2=A0* core devs just provide options, and don&#39;t have to worry about b=
eing<br>
=C2=A0 =C2=A0seen as gatekeepers<br>
<br>
The &quot;downside&quot; in that scenario is that users/dev aren&#39;t maki=
ng much<br>
actual use of all the choices core is offering by making different<br>
options available; but the upside is that that choice is at least readily<b=
r>
available should whoever is coming up with these policy become out of<br>
step with what people actually want.<br>
<br>
One thing that might make an approach like that difficult is that core<br>
has historically been happy to remove options that don&#39;t seem useful<br=
>
anymore: eg the ability to turn of BIP 125 support (#16171), and priority<b=
r>
transactions (#9602). Perhaps that&#39;s fine if you&#39;re trying to activ=
ely<br>
craft a single mempool/relay policy that&#39;s good enough for almost every=
one<br>
(after all, it makes the code simpler and more efficient, and reduces<br>
the number of footguns); all you&#39;re doing is leaving a minority of peop=
le<br>
who want weird things to run a fork, and that&#39;s going to happen anyway.=
<br>
<br>
But if people are following policy developed outside of core, core<br>
might well disagree with them and decide &quot;no that&#39;s a stupid polic=
y,<br>
no one should do that&quot; and remove some feature that others thing shoul=
d<br>
continue to be normal. Beyond the examples above, there&#39;s already talk =
of<br>
removing the ability to disable fullrbf support in #26305, for instance.<br=
>
If that happens, then the people maintaining the policy will instead<br>
end up maintaining an entire fork of bitcoin core, and all we&#39;ve done<b=
r>
is transition to people running software from a different repo, and a<br>
different set of maintainers.<br>
<br>
If we&#39;re really going to a world where core&#39;s eager to add new opti=
ons,<br>
and reluctant to remove them, at least if anyone at all finds them<br>
interesting, that&#39;s presumably a non-issue, though.<br>
<br>
Cheers,<br>
aj<br>
_______________________________________________<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>

--0000000000003bbb3605ec0a01c2--