The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Code Coverage

For detailed information about the code coverage, see the test coverage report.

Reviews

See the guideline for information on the review process.

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

Conflicts

Reviewers, this pull request conflicts with the following ones:

• #28676 ([WIP] Cluster mempool implementation by sdaftuar)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

mempoolfullrbf should be removed, and RBF is a redundant unenforceable feature. If we believe miners only care about the the largest fee/rate then simply providing them with all txns is good enough. Miners can choose how to sort themselves.

ACK

Concept ACK

Given the majority of the hashrate using mempoolfullrbf, Bitcoin Core should adapt its default behavior to match its expectations to the blocks being published.

Thanks @reardencode for the review and ACK as its obvious full-rbf should be default. There is some politics involved in it which I wanted to highlight:

Sorry for the confusion. To clarify, I had deleted my own comment. I wanted to think a bit more about it before commenting again.

@1440000bytes hello from your friendly neighborhood moderator. This is just a reminder to keep all discussions technical. Pull request comments should be focused on the code in question. Discussions about personal opinions, moderator or maintainer actions (including responses to this comment) can be opened here

Concept ACK.

For the same vector of DoS attack about contracting protocols and multi-party explained in my
post on the mailing list in 2021 ("Mempool Funny Games against Multi-Party Funded Transactions).

I believe one of the best long-term solution to avoid new use-case conflict (in the present "0
conf tx acceptance versus multi-party built transaction like coinjoin") is to minimize the scope
of the transaction-relay policy in the bitcoin core codebase, while this cannot be always followed
when it's mitigating a DoS vector (e.g MIN_STANDARD_TX_NONWITNESS_SIZE). I made such more or
less experiment to have this approach of having transaction-relay policy rules signaled among
transaction issuers and miners with #29448 and similarly transaction-flags user-defined has been
discussed on the mailing list here.

Historically, there has been some attempt to have the policy rules validated in an external
module with a set of patch proposed by jtimon (e.g see 6416, 6420, 6424 and other PRs around
the same period). See e.g https://github.com/jtimon/bitcoin/commits/policy-replacement-alt for
example of abstractions for "alternative replacement policies".

FWIW, I had some friends running nodes either do nothing or turn this on. In the last 144 blocks, a default node sees only 64.58% blocks reconstructed with zero round trips which, in my view, means compact blocks is significantly broken for its latency reducing purpose. A node with this enabled sees 94.44% reconstruct without a roundtrip, which is maybe a little low but not broken.

I imagine that if more of the network were running enabled that number might increase further, as it may still be held down due to transactions that fail to propagate well (consistent with that, it seems most nodes with no inbound have low rates regardless of the setting, which presumably wouldn't be so if most nodes had this setting).

I shared my concerns with another bitcoiner who likes to monitor network health, they replicated, and got similar results (which I presume they'll share eventually).

concept ack given the above data from @gmaxwell.

If we believe miners only care about the the largest fee/rate then simply providing them with all txns is good enough.

That would be a reason to support this PR, as full-RBF simply provides miners with all txns. Without full RBF enabled by relays, miners would typically only see the "first" transaction.

FWIW, I had some friends running nodes either do nothing or turn this on. In the last 144 blocks, a default node sees only 64.58% blocks reconstructed with zero round trips which, in my view, means compact blocks is significantly broken for its latency reducing purpose. A node with this enabled sees 94.44% reconstruct without a roundtrip, which is maybe a little low but not broken.

This behaviour was originally intended to put pressure on miners to match node policies; it's not supposed to be an excuse to pressure nodes to adapt to miner policies.

(Personally, I'm ~0 on whether this actually gets merged or not; Knots has had full RBF by default for years, and "first seen" doesn't really make sense as a policy)

@luke-jr I don't know that I'd say 'intended', particularly since poor propagation either helps or hurts miners depend on their hashrate-- it benefits sufficiently large centralized miners when other miners take more time to get their blocks-- but regardless of intent it works the way it works.

I would say that to the extent someone is ambivalent with respect to the policy, as you just expressed, it's preferable to improve block propagation latency since higher latency is a centralization pressure. The existence of the extrapool is intended to decouple policy from block propagation-- allowing nodes to keep around some txn they wouldn't prefer to mine/relay for the benefit of reconstructing blocks, but it only goes so far.

Ultimately it would be best if block relay latency were less fragile-- methods have been implemented (the FEC reconstruction of fibre, for example) but never incorporated in widely deployed node software. And even those work particularly well if only a few transactions are missing relative to the node's mempool and extrapool. So even if more robust block relay was in use, it's preferable to do whatever lowers the discrepancy, all other things equal (and they're not always equal, for sure).

I say "intended" because policy centralization was a concern I had and raised about compact blocks before they were merged, and @sipa explicitly justified CB's behaviour in this regard as a way for nodes to exert influence on miners in this respect.

I shared my concerns with another bitcoiner who likes to monitor network health, they replicated, and got similar results (which I presume they'll share eventually).

Correct, I too found enabling mempoolfullrbf to be helpful for compact block reconstruction without requesting transactions.

By analyzing compact block reconstructions in the debug.logs (with debug=cmpctblock enabled) of my monitoring nodes, I noticed that many block reconstructions need an additional round-trip to fetch unknown transactions. While this situation has slightly improved over the last weeks (~50% -> 70+%) as mempool activity died down, this still clearly shows a divergence in policy.

I suspected that the divergence might originate from nearly all pools mining with mempoolfullrbf. I enabled -mempoolfullrbf=1 on the monitoring node/host erin on 2024-07-26. Since then, this node needed request transactions during significantly fewer blocks reconstructions than the other nodes.

Concept ACK

_{(note that while 75% or so might show up as light green here, doesn't necessarily mean that 75% is "good". Ideally, we want this to be close to 100% of blocks reconstructions needing no transaction requests)}

If the conclusion is that it's now better for a node to have this "on", rather than "off", and this is merged for 28.x, then I think we should also:

• Backport the default change to the relevant release branches.
• Ultimately just remove the option (doesn't have to be done here).

reACK 590456e

reACK 590456e

ACK 590456e

I did my own testing a few weeks ago where I made transactions that did not signal and replaced them to see how many were mined. The methodology was to create a transaction and replace it after 2 minutes. A total of 122 transactions were created, with 118 of the replacements being accepted. This took place on July 10th to 11th over the course of about 30 hours. With a 96.7% success rate, I think that's pretty good evidence that miners have enabled mempoolfullrbf.

This gist contains the script that I used as well as a log of all of the transactions that were created.

Concept NACK: Opposition to Full-RBF by Default Without Broad Consensus
I have several critical concerns regarding the default implementation of Full Replace-By-Fee (RBF):

1. Deviation from the First-Seen Rule: Bitcoin's game theory initially hinged on the "first-seen" rule, which is fundamental in preventing malicious double spends by confirming the first transaction broadcast. Moving away from this to a model where transactions can be outbid by higher fees undermines both the security and predictability of transactions, which are essential for maintaining user trust and the overall integrity of the Bitcoin network.

2. Increased Centralization of Block Production: The last decade has seen a notable increase in the centralization of block production, concentrated among a few large pools. This trend jeopardizes Bitcoin's democratic and decentralized principles. Implementing changes like RBF, which could be exploited by these centralized entities, further aggravates this problem.

3. RBF as a Temporary Scaling Measure: Introduced as a stopgap for handling network congestion and scaling issues, RBF falls short as a long-term solution. It overshadows more sustainable approaches such as implementing larger blocks or enhancements like OP_CHECKTEMPLATEVERIFY (OP_CTV). RBF's temporary nature could potentially obstruct the broader vision of scaling Bitcoin into a viable peer-to-peer currency.

4. Lack of Broad Social Consensus: The decision to implement a significant protocol change such as RBF without widespread community consensus is deeply concerning. This practice is misaligned with Bitcoin’s governance principles, where substantial changes should be thoroughly debated and agreed upon by the community.

5. Implications for Bitcoin’s Role as P2P Money: The ongoing reliance on and expansion of RBF features could impede Bitcoin’s ability to scale effectively as practical, peer-to-peer money. It pivots the system towards a competitive fee market, moving away from fostering user empowerment and accessibility—both of which are crucial for Bitcoin's adoption and functionality as a currency.

Given these points, I strongly recommend a reevaluation of RBF's role and its implementation strategy. We need to consider more robust and decentralized scaling solutions that adhere to Bitcoin's original intentions, supporting its development into a reliable and universally accessible digital currency.

Backported for 27.x in #30558.