Issue Details
- Number
- 27463
- Title
- Package Relay Project Tracking
- Description
- 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:
#31829
:point_up: :point_up: :point_up:
### Tasks and PRs
:ballot_box_with_check: **(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.
<details><summary>See PRs</summary>
- Enable validation of multiple transactions in MemPoolAccept
- [x] Dependency: #21062
- [x] Dependency: #23381
- [x] Main feature 1/2: #20833
- [x] Main feature 2/2: #21800
- [x] Followup: #22084
- Enable package CPFP
- [x] Main feature 1/2: #22674
- [x] Followup: #24310
- [x] Followup: #23804
- [x] Main feature 2/2: #24152
- [x] short term bug fix: avoid the risk of below-minrelaytxfee transactions hanging around forever in the mempool #26933
- RPC access
- [x] #24836
- [x] #26646
- [x] #27609
- [x] #28848
- [x] #28950
- [x] Followup: #29722
- [x] Followup: #29735
- Fuzzing and bug fixes
- [x] #28450
- [x] #28764
- [x] #28825
- [x] Bug fix: #28251
- [x] Bug fix: #28471
- [x] Bug fix: #28472
</details>
:ballot_box_with_check: **(2) Policy-Related Features: TRUC and limited package RBF**
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.
<details><summary>See PRs</summary>
:ballot_box_with_check: **(2a) Topologically Restricted Until Confirmation (v3) transaction policy**
Note: BIP 431 isn't part of package relay.
It just represents the topology for which we can build these features, i.e. bumping 0-fee parents and package RBF, without cluster mempool. It is also more robust for applications that would seek to use 1p1c package relay.
Also see #29319 for its role in cluster mempool.
- [x] Main feature: #28948
- [x] Followup: #29424
- [x] Sibling Eviction: #29306
- [x] Decrease max vsize: #29873
- [x] Enable v3 on mainnet: #29496
- [x] Followup: #30272
- [x] Docs: https://github.com/bitcoin/bips/pull/1541
:ballot_box_with_check: **(2b) Package RBF for cluster size 2**
- Enable Package RBF for 1-parent-1-child situations
- [x] Dependency: #22796
- [x] Dependency: #22675
- [x] Dependency: #22855
- [x] Dependency: #29242
- [x] Followup: #29724
- [x] #29757
- [x] Dependency: #30072
- [x] #30066
- [x] Main feature: #28984
- [x] followup: #30295
Also see: Ephemeral Dust and Pay To Anchor (P2A) aka Ephemeral Anchors
</details>
:ballot_box_with_check: **(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
- [x] Dependency: #29619
- [x] Main feature: #28970
- [x] Followup: #30012
**(4) TxDownloadManager and orphan-handling improvements**
All of this code directly contributes to package relay, whether it's BIP 331 or a different protocol.
- Modularize TxDownloadManager + testing
- [x] Dependency: #28785
- [x] Dependency: #28199
- [x] Dependency: #28364
- [x] Dependency: #30111
- [x] Followup: #30507
- [x] Main PR: #30110
- [x] Followup: #31190
- [ ] WIP: one_honest_peer fuzzer
- [ ] WIP: make internally thread-safe
- Make orphanage more robust. See [known orphanage problems](https://github.com/bitcoin-core/bitcoin-devwiki/wiki/%5BP2P%5D-known-TxOrphanage-problems).
- [x] #30000
- [x] #31397
- [x] Followup: #31666
- [x] #31810
- [ ] #31829
- [ ] WIP: make `TxDownloadManager` internally thread-safe #28031
- [ ] WIP: token bucket orphanage protection
**(5) more general package relay**
Goals: propagate incentive-compatible packages that are more compelx than 1p1c, safely evaluate replacements within packages, handle orphans better.
This is deferred until #30289 is completed.
Handling arbitrary ancestor packages (i.e. beyond 1p1c or child-with-parents-tree) is very complex. Also, there are various higher-priority issues with mempool that make accepting packages more difficult to reason about, and that we should fix before adding more general package relay.
- Package validation and package RBF with less restrictive topologies
- #26711
- https://delvingbitcoin.org/t/post-clustermempool-package-rbf-per-chunk-processing/190
- BIP 331 ancestor package relay for orphan-handling
- [x] BIP: bitcoin/bips/pull/1382
- #27742
- ancestor set + prefix?
- sender-initiated package relay protocol using chunks (?)
<details><summary>See also:</summary>
Superseded/Deferred Work
- #28758
- #28808
- #28813
- #27018
- #25038
- #26403
- #29427
- #27476
Prehistory
- [x] #16400
- #16401
- #14895
- #19621
- https://gist.github.com/sdaftuar/8756699bfcad4d3806ba9f3396d4e66a
</details>
- URL
-
https://github.com/bitcoin/bitcoin/issue/27463
- Closed by
-
Back to List