This issue will be edited frequently to reflect the current status of the project.
What is ready for review now?
:point_down: :point_down: :point_down: :point_down: :point_down: :point_down: :point_down: p2p: #30111 followups: #30295, #30272 :point_up: :point_up: :point_up: :point_up: :point_up: :point_up: :point_up:
Why does the roadmap include cluster mempool?
Handling arbitrary ancestor packages (i.e. beyond 1p1c or child-with-parents-tree) is very complex. There are various higher-priority issues with mempool that make accepting packages more difficult to reason about, and that we should fix before adding ancestor package relay. We are building the full feature set (package relay, package RBF, bumping 0-fee parents, etc.) for 1p1c packages as we know that is very useful and it is a topology that we can easily handle without cluster mempool.
Why does the roadmap include TRUCs (aka v3 aka BIP 431)?
TRUCs helps deliver some of the 1p1c package relay features like bumping 0-fee parents, and is generally more robust for applications that would seek to use 1p1c package relay. Also see #29319 for its role in cluster mempool.
Tasks and PRs
(1) multi-parent-1-child package validation
What we get: the ability to validate multiple transactions, including CPFP of transactions below the mempool minimum feerate. An RPC to submit things locally.
- Enable validation of multiple transactions in MemPoolAccept
- Enable package CPFP
- RPC access
- Fuzzing and bug fixes
(2a) Topologically Restricted Until Confirmation (v3) transaction policy
What we get: an opt-in policy for anti-pinning in single transaction or 1-parent-1-child package scenarios. Also, package CPFP of 0-fee parent and package RBF for restricted topologies prior to cluster mempool.
- Topologically Restricted Until Confirmation (v3) transaction policy
- (in later release): wallet signaling
- Also see: #29427
- Also see: Ephemeral Anchors,
(2b) Package RBF for cluster size 2
- Enable Package RBF for 1-parent-1-child situations
(3) 1-parent-1-child package relay
What we get: package relay of 1-parent-1-child packages. Protocols like LN can use this to create 0-fee presigned transactions with a single, 0-value anchor output; 0-fee commitment transactions can replace each other using the fees of the child attached to the anchor. This should provide an adequate replacement for CPFP carve out, which is helpful for the next step (see #29319).
- Opportunistically submit 1-parent-1-child packages
- Modularize TxDownloadManager + testing
- Make orphanage more robust
(4) cluster mempool
What we get: the ability to quickly assess the incentive compatibility of transactions, safer eviction, more incentive-compatible RBF rules in general. More general package validation can be built more safely on top.
See #30289
(5) more general package relay
Goals: propagate incentive-compatible packages that are more compelx than 1p1c, safely evaluate replacements within packages, handle orphans better.
- Package RBF with less restrictive topologies
- Package validation of less restrictive topologies
- BIP 331 ancestor package relay for orphan-handling
- BIP: bitcoin/bips/pull/1382
- Implementation: #27742
- ancestor set + prefix?
- sender-initiated package relay protocol using chunks (?)
Superseded/Deferred Work
Prehistory