path: root/48/d7bf241846af78a8a10dbddad4d431c282e5b2

Return-Path: <gloriajzhao@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 38A06C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 27 Oct 2022 12:37:04 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 0C9D380B8C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 27 Oct 2022 12:37:04 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 0C9D380B8C
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=EaEv7QBx
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id G1nVWOxdhbzX
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 27 Oct 2022 12:37:00 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 702F480B56
Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com
 [IPv6:2607:f8b0:4864:20::102b])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 702F480B56
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 27 Oct 2022 12:37:00 +0000 (UTC)
Received: by mail-pj1-x102b.google.com with SMTP id m2so1388236pjr.3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 27 Oct 2022 05:37: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=3/yIkVla6MEv6XNR9F1W3OsL5yPvNtg7uCX+kf2UnMs=;
 b=EaEv7QBxaCqoEIZKLbMXkctRdIaDHaMJGQ4VgxoKn6J5Kd/8Wr33ROX4Vi+Wikcnxo
 UT0DBp+uFX2MtCJ3FNaPohogNA+e2huvG7vb6V9c9fa9aw7bTIeJZLjvnMS+n6kTf42T
 LI/ISGugdjnz0Ai1KIWxzAVu928Arehy2aOvCpaDVbGi2zcxX3JCrnZum34gxom8cP5u
 +qckWMJWAI5juMLKHreAySUIc/lNswjplDsuY/ybvxbm964vAq+r11/OgbSpepO5CES8
 PAP/v3NOwsskISPg6iWTk41h3pe9IQf6gRjWbFmc+zQay+U49Dn72CDWJkuzG3mBPAYL
 r19Q==
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=3/yIkVla6MEv6XNR9F1W3OsL5yPvNtg7uCX+kf2UnMs=;
 b=0TtB+Bvo9bWWtb4wUpmZjuycXFNEwMupe2j/DSuRmctwmYsyt/rHMbygDX3i1sDe4E
 FyHbkvWiTzyu/B2V04a+iwt4rQ2HWflC6RM07LmOnaCCrvF0YsX9xtqPdeEYm7x4O9Ar
 eDnJB+OKICGqaaprZGDDXW8SzlwPi213Et9MpnVngLpZ1Z7XieevKnL29uYFmIAS+JEL
 Pt6QujyH3DkxJMlmsIMezUfZOt4rXGYYzZa7/aKmjCLIszp2bdMAfHixr9BuNJ2Ma6iA
 liyGyp4V8mzyUS2OIIYN0FtdiajVAi66A1GO9KCL3O8wBj+2CxyhN/mHFvfPbzXMnm6W
 +lJg==
X-Gm-Message-State: ACrzQf0VYRHn5D94P5F6Uwo9TbufzYAn2kRXrnV+oFEyf6t5Nd6ysXXT
 I2UvdwkF4+t1P/4mlUQNI1gvPkG8y4imUwJctn5jmsnB7n0=
X-Google-Smtp-Source: AMsMyM4g7HbtKEBL0jlnGA4+F2ZfBj/SZlde0Ut6wD+qGIGnMHJrDSOvf7Ry2ATF3uQIvhzldVk9l35jbyDxgYhL8+A=
X-Received: by 2002:a17:90b:1e46:b0:20a:c49f:9929 with SMTP id
 pi6-20020a17090b1e4600b0020ac49f9929mr9819972pjb.221.1666874219235; Thu, 27
 Oct 2022 05:36:59 -0700 (PDT)
MIME-Version: 1.0
References: <Y1nIKjQC3DkiSGyw@erisian.com.au>
In-Reply-To: <Y1nIKjQC3DkiSGyw@erisian.com.au>
From: Gloria Zhao <gloriajzhao@gmail.com>
Date: Thu, 27 Oct 2022 13:36:47 +0100
Message-ID: <CAFXO6=+Bjr_nuy+24VZR-zE3=Heii_NJxWPdiJTJW6ZgWbZ8rA@mail.gmail.com>
To: Anthony Towns <aj@erisian.com.au>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000b90fe905ec0365cc"
X-Mailman-Approved-At: Thu, 27 Oct 2022 12:45:16 +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 12:37:04 -0000

--000000000000b90fe905ec0365cc
Content-Type: text/plain; charset="UTF-8"

Hi AJ,

Not going to comment on what Bitcoin Core's philosophy on mempol policy is
or should be. I want to note that I think this:

> 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

is true.

> 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=0, -datacarrier=0), that's easy for you (though
> 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.

Yes, in most cases, whether Bitcoin Core is restricting or loosening
policy, the user in question is fine as long as they have a path from their
node to a miner that will accept it. This is the case for something like
-datacarriersize if the use case is putting stuff into OP_RETURN outputs,
or if they're LN and using CPFP carveout, v3, package relay, etc. But
replacement is not only a question of "will my transaction propagate" but
also, "will someone else's transaction propagate, invalidating mine" or, in
other words, "can I prevent someone else's transaction from propagating." A
zeroconf user relies on there *not* being a path from someone else's full
RBF node to a full RBF miner. This is why I think RBF is so controversial
in general, why -mempoolfullrbf on someone else's node is considered more
significant than another policy option, and why full RBF shouldn't be
compared with something like datacarriersize. I don't think past patterns
can be easily applied here, and I don't think this necessarily shows a
different "direction" in thinking about mempool policy in general.

Best,
Gloria

On Thu, Oct 27, 2022 at 12:52 AM Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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 sounds
> > 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 folks
> 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-transactions-in-mempool-are-conflicting
>
> Up until now, the differences between node policies supported by different
> 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 is
>   (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-1274949400
>
>   NACK. This is a default false option.
>    - achow101
>      https://github.com/bitcoin/bitcoin/pull/26287#issuecomment-1274953204
>
>   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-1290721905
>
>   I'm in general against removing options.
>    - instagibbs
>      https://github.com/bitcoin/bitcoin/pull/26287#issuecomment-1292030700
>
> 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=0 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=true 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=0, -datacarrier=0), that's easy for you (though
> 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 preferred
> 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 nodes
> already have a gossip network, and might want to help their own ecosystem
> by ensuring unilateral channel closes and justice transactions are quickly
> 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 as
> 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=c++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 way
>    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 everyone
> (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
>

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

<div dir=3D"ltr"><div dir=3D"ltr"><div>Hi AJ,</div><div><br></div><div>Not =
going to comment on what Bitcoin Core&#39;s philosophy on mempol policy is =
or should be. I want to note that I think this:</div><div><br></div><div>&g=
t; It&#39;s also possible that this is something of a one time thing: full =
rbf<br>
&gt; has been controversial for ages, but widely liked by devs, and other<b=
r>
&gt; attempts (eg making it available in knots) haven&#39;t actually achiev=
ed<br>
&gt; much of a result in practice. So maybe this is just a special case <br=
></div><div><br></div><div>is true.<br></div><div><br></div><div>&gt; The s=
econd thing is that whatever your relay policy is, you still<br>
&gt; need a path all the way to miners through nodes that will accept your<=
br>
&gt; transaction at every step. If you&#39;re making your mempool more rest=
rictive<br>
&gt; (eg -permitbaremultisig=3D0, -datacarrier=3D0), that&#39;s easy for yo=
u (though<br>
&gt; you&#39;re making life more difficult for people who do create those s=
orts<br>
&gt; of txs); but if you want a more permissive policy (package relay,<br>
&gt; version-3-rbf, full-rbf), you might need to do some work.</div><div><b=
r>
</div><div>&gt; The cutoff for that is probably something like &quot;do 30%=
 of listening<br>
&gt; nodes have a compatible policy&quot;? If they do, then you&#39;ll have=
 about a<br>
&gt; 95% chance of having at least one of your outbound peers accept your t=
x,<br>
&gt; just by random chance.</div><div><br></div><div>Yes, in most cases, wh=
ether Bitcoin Core is restricting or loosening policy, the user in question=
 is fine as long as they have a path from their node to a miner that will a=
ccept it. This is the case for something like -datacarriersize if the use c=
ase is putting stuff into OP_RETURN outputs, or if they&#39;re LN and using=
 CPFP carveout, v3, package relay, etc. But replacement is not only a quest=
ion of &quot;will my transaction propagate&quot; but also, &quot;will someo=
ne else&#39;s transaction propagate, invalidating mine&quot; or, in other w=
ords, &quot;can I prevent someone else&#39;s transaction from propagating.&=
quot; A zeroconf user relies on there *not* being a path from someone else&=
#39;s full RBF node to a full RBF miner. This is why I think RBF is so cont=
roversial in general, why -mempoolfullrbf on someone else&#39;s node is con=
sidered more significant than another policy option, and why full RBF shoul=
dn&#39;t be compared with something like datacarriersize. I don&#39;t think=
 past patterns can be easily applied here, and I don&#39;t think this neces=
sarily shows a different &quot;direction&quot; in thinking about mempool po=
licy in general.<br></div><div><br></div></div><div>Best,</div><div>Gloria<=
/div><div><br></div><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gm=
ail_attr">On Thu, Oct 27, 2022 at 12:52 AM Anthony Towns 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">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></div>

--000000000000b90fe905ec0365cc--