Package Relay Project Tracking #27463

issue glozow openend this issue on April 14, 2023
  1. glozow commented at 11:14 am on April 14, 2023: member

    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.

    :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.

    :ballot_box_with_check: (2a) Topologically Restricted Until Confirmation (v3) transaction policy

    Also see #29319 for its role in cluster mempool.

    :ballot_box_with_check: (2b) Package RBF for cluster size 2

    Also see: Ephemeral Dust and Pay To Anchor (P2A) aka Ephemeral Anchors

    :ballot_box_with_check: (3) 1-parent-1-child package relay

    What we get: opportunistic acceptance of of 1-parent-1-child packages. Not quite “package relay” but similar to it. 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

    (4) TxDownloadManager and Orphan Resolution improvements

    All of this code directly contributes to package relay, whether it’s BIP 331 or a different protocol.

    (5) Further Work

    Superseded/Deferred Work

    Prehistory

  2. glozow added the label Feature on Apr 14, 2023
  3. maflcko added the label TX fees and policy on Apr 14, 2023
  4. maflcko added the label P2P on Apr 14, 2023
  5. maflcko added the label Brainstorming on Apr 14, 2023
  6. instagibbs commented at 2:26 pm on April 14, 2023: member
    Very helpful. I think this helps define “sprints” that can be achieved to hit next milestones.
  7. ariard commented at 1:30 am on April 17, 2023: none

    I think one more sub-category to track is the feedback collected on how package relay/nversion=3 are fitting multi-party applications and contracting protocols

    • Lightning: legacy channels / anchor output / taproot types
    • Peerswap: claim with preimage + refund cooperatively + refund after csv passes
    • Collaborative transaction: splicing + dual funding flows

    The 0-conf flow of Lightning can be also considered. As deployed today by some LSPs where both incoming/outgoing HTLCs are allowed during the pending confirmation period, there is a risk in case of mempool congestions of the inbound funding transaction not confirming before the timelock of the offered HTLC output expires. The current nversion=3 size is 1000 vb which might be too low if LSPs would like to do batching of 0-confs. Note, I think all the pinning risks are not the same for 0-conf funding transactions than for time-sensitive confirmation of LN commitment+HTLCs transactions.

    Mentioning 0-conf, and as raised on #27643 at some point in the development cycle of nversion=3 it might be good communication practice to publish than all 0confs users might have to upgrade their mempool monitoring stuff to reject nversion=3, or chain of transactions with them, as otherwise genuine upgrade to the version of Core with package relay might lower their security.

    For Lightning, there is the question if the p2p package format is flexible enough for the Lightning channels to apply “new mempool rules” on “old in-flight channnel type”. Like backward compatible effect of the mempools rules without off-chain channels having to cooperate on-resigning transactions. I believe that would require a Lightning node to sign the p2p package with the same pubkey than used with the channel (though I start to think we might have multiple types of backward/forward compatible application of mempools rules like the ones mentioned in #25038, like there is some matrix ?)

    For the second-layers listed, I’m just considering the ones which have a) a mature specification and b) some substantial deployment though should we consider more second-layers or multi-party applications like vaults (non-deployed) ?

    From a reviewer viewpoint, I think it could be very valuable if you can highlight the 2/3 PRs or mail posts you consider as top of the stack for reviews ? Thanks for a package-relay context-tracking meta-issue.

    (Feel free to integrate what you find relevant of this comment to ease context tracking of package relay as a project)

  8. ajtowns commented at 5:21 am on April 17, 2023: contributor

    I think at a high level, the “package relay” part looks like:

    • make package mempool acceptance available via rpc in regtest
    • fix up package acceptance/retention/mining policies to be free from DoS vectors and to behave sensibly
    • behave sensibly with arbitrary txs in a package
    • implement bip331 to expose package relay over p2p not just rpc

    And relatedly:

    • version 3 acceptance/rbf policies to limit pinnability
    • ephemeral anchors

    Particularly if #26933 is applied, is there any reason not to make submitpackage available on all chains? It should behave no differently to submitting the transactions individually with a non-full mempool, no?

  9. ajtowns commented at 7:23 am on April 17, 2023: contributor

    FWIW, I don’t think “incentive compatibility” is a good description of our goal here – I think there’s three goals we want:

    • for most normal use cases (including newly invented ones) just submitting your txs over p2p should work fine
      • (otherwise people will tend to use centralised tx submission methods, which creates a chokepoint that will attract censorship)
    • running a plain bitcoind should get you block templates within 90%-99% of optimal, depending on the resources you can allocate to your node
      • (otherwise miners will outsource block template construction to proprietary services in order to be competitive, which again creates a censorship chokepoint)
    • mempool/relay behaviour should be as simple to understand as possible – for wallet designers, bitcoin users, node operators and miners
      • (otherwise bitcoin will only be usable in theory, not in practice)

    I think most of the “incentive compatible” things above aren’t really making anything more incentive compatible (miners can just raise their mempool limits to keep the transactions; non-mining nodes aren’t receiving any incentives in the first place) but rather making mempool behaviour easier to understand (eg “we removed this tx because there was a race condition when loading the mempool” vs “we removed this tx because it wouldn’t be included in any of the next 100 optimal blocks, even if no new txs are submitted”).

  10. glozow commented at 7:42 am on April 17, 2023: member

    I think at a high level, the “package relay” part looks like:

    Yes, that is how I think of it.

    Particularly if #26933 is applied, is there any reason not to make submitpackage available on all chains? It should behave no differently to submitting the transactions individually with a non-full mempool, no?

    Somewhat. It’s still a little bit weird when you submit a child-with-parents where a parent relies on the other (grep “Check that validation isn’t quitting too early” in #26711, currently at this line). I would say it’s safe after the “submit with subpackages” changes.

    Also, mempools are full on mainnet (great for testing but means there is a difference), and we’ll definitely want to warn them that the transactions are not necessarily relayed etc.

  11. ajtowns commented at 3:09 pm on April 19, 2023: contributor

    Also, mempools are full on mainnet

    My mempool isn’t full, and (I think) hasn’t been full this year. (It has a 1GB limit; though there’s only ~40MB of txs now anyway)

    Submitting a low-feerate tx with a high mempool limit already means your tx won’t relay without a cpfp tx, but we expect people to be who are clever enough to do that to also deal with the consequences. (If you do cpfp the low feerate tx, it’ll be broadcast via orphan handling, so won’t appear in the unbroadcast set any longer, but also won’t successfully relay without package processing, so you’ll end up in the exact same state, I think)

  12. glozow referenced this in commit bdfe27c9d2 on Apr 26, 2023
  13. ariard commented at 2:12 am on May 1, 2023: none

    If the state-of-art implementation of BIP331 can be linked here or in the BIP (Like there is https://github.com/glozow/bitcoin/pull/8 and https://github.com/glozow/bitcoin/pull/9) ?

    From a reviewer perspective, ideally it’s better to have the proposed specification changes, the proposed Core code changes and the backend code of broadcaster client (e.g Lightning) to grasp a correct mental model of all the interactions.

  14. ?
    project_v2_item_status_changed glozow
  15. ?
    added_to_project_v2 glozow
  16. fanquake pinned this on May 5, 2023
  17. glozow commented at 1:28 pm on June 2, 2023: member

    If the state-of-art implementation of BIP331 can be linked here or in the BIP (Like there is https://github.com/glozow/bitcoin/pull/8 and https://github.com/glozow/bitcoin/pull/9) ? From a reviewer perspective, ideally it’s better to have the proposed specification changes, the proposed Core code changes and the backend code of broadcaster client (e.g Lightning) to grasp a correct mental model of all the interactions.

    Forgot to respond to this earlier - #27742 is the branch you’re looking for :)

  18. AndriiHlukhovskyi commented at 10:50 pm on June 23, 2023: none
    Super
  19. ariard commented at 3:37 am on July 7, 2023: none

    From a reviewing standpoint on #27742, I think it would benefit if the release aim for current package version (BIP331 + nversion=3 policy regime) is explicitly bounded to Lightning time-sensitive confirmation flows, especially in matters of DoS protection:

    • broadcast of revoked transaction output spend
    • broadcast of a commitment transaction with pending HTLC outputs and its associated second-stage transactions

    I think this covers the most sensitive Lightning flows impacted by the pinning attacks mentioned as a design goal by BIP331. However this left of out considerations the following multi-party contract protocols and subsidiary Lightning flows:

    • submarine swaps e.g peerswap
    • LN dual-funding and splicing (package relay has been discussed as a griefing mitigation on the lightning dev mailing list iirc)
    • Taprooted wallet with time-sensitive script path

    I think this is opportune to say so on the mailing list and therefore avoid multi-party applications or contracting protocols having to complaint than this deployment of package relay doesn’t fit their use-case (kind of like we have with the mempoolfullrbf debate). Beyond, I would say it’s valuable to announce latest BIP331 (minor) changes, if it does change something for the p2p network, that we would have missed from the Bitcoin Core-side.

  20. bitcoin deleted a comment on Aug 17, 2023
  21. bitcoin deleted a comment on Aug 17, 2023
  22. achow101 referenced this in commit 5666966dff on Aug 31, 2023
  23. ?
    added_to_project_v2 glozow
  24. ?
    project_v2_item_status_changed glozow
  25. ?
    project_v2_item_status_changed glozow
  26. glozow commented at 1:49 pm on September 20, 2023: member

    Status update: I’ve put all the p2p PRs in draft to focus on getting the mempool/validation things done (I was struggling to context-switch and iterate quickly with the 5+ PRs). The v3 stuff also can’t make progress until the AcceptPackage interface is more stable. After #26711 and more fuzzing, it also might be safe to open submitpackage on mainnet.

    I’ll continue working on the p2p code and write a lot more tests before opening them again. Please review the mempool stuff if you want to help with the project.

  27. tolex469 commented at 10:24 pm on September 26, 2023: none
    Add new features
  28. achow101 unpinned this on Oct 5, 2023
  29. ?
    removed_from_project_v2 achow101
  30. ?
    added_to_project_v2 achow101
  31. ?
    project_v2_item_status_changed achow101
  32. fanquake referenced this in commit 5d9f45082b on Nov 3, 2023
  33. achow101 referenced this in commit d9007f51a7 on Nov 3, 2023
  34. fanquake referenced this in commit d690f89b57 on Nov 8, 2023
  35. achow101 commented at 5:06 pm on November 14, 2023: member
    #26711 was closed. Could we get a longer explanation of why and what the plan is going forward? My understanding is that the plan is to do a limited package relay carveout for just CPFP, then cluster mempool, then the rest of package relay?
  36. instagibbs commented at 5:45 pm on November 14, 2023: member
    I’ll update Ephemeral Anchors PR/BIP once current set of PRs are merged, since I build on #28848 for testing
  37. glozow commented at 5:59 pm on November 14, 2023: member

    There have been discussions on what package validation and RBF rules will look like in a post-cluster mempool world. #26711 either doesn’t work with cluster mempool or should not be considered until after cluster mempool. #26711 supports certain types of package submission that we might not be able to continue to support with cluster mempool depending on what approach is taken. There are different ideas on how to consider subsets of packages to accept when it doesn’t make sense to take all or none. IIUC the approach taken in #26711 (which is to do subpackage evaluation) no longer has conceptual support which is why I closed it.

    Another issue is a circular dependency between cluster mempool and package relay. (1) We want cluster mempool before package RBF since it allows us to assess incentive compatibility much more easily. (2) Cluster mempool requires the removal of CPFP carve out in order to switch from ancestor/descendant-based package limits to cluster limits. But there are people who rely on CPFP carve out for bumping presigned transactions; we need to build a replacement (i.e. package relay + package RBF).

    So the new plan of attack is to first create 1-parent-1-child package relay, including package RBF for v3 transactions. This allows the users of CPFP carve out to switch, thus allowing us to remove CPFP carve out and then add cluster mempool. This also allows us to defer the decision-making on what package evaluation and package RBF will look like in a post-cluster mempool world.

  38. achow101 referenced this in commit 7143d43884 on Feb 10, 2024
  39. ?
    removed_from_project_v2 achow101
  40. ?
    added_to_project_v2 achow101
  41. ?
    project_v2_item_status_changed achow101
  42. achow101 referenced this in commit d813ba1bc4 on Apr 30, 2024
  43. ryanofsky referenced this in commit 33303b2b29 on May 15, 2024
  44. achow101 referenced this in commit 6e4d18f37f on Jun 7, 2024
  45. fanquake referenced this in commit 9607277032 on Jul 24, 2024
  46. ?
    removed_from_project_v2 achow101
  47. achow101 referenced this in commit 7b66815b16 on Oct 29, 2024
  48. glozow commented at 2:23 am on November 19, 2024: member

    Update similar to my irc update: there are a few possible next steps including (1) rebasing #28031 to start adding the orphan resolution module (2) making TxDownloadManager internally thread-safe (3) finishing up the one_honest_peer fuzzer.

    Nothing is open for review right now as I am a bit busy with other things and still deciding what to do next.

  49. fanquake referenced this in commit 335798c496 on Jan 16, 2025
  50. fanquake referenced this in commit 329b60f595 on Feb 10, 2025
  51. achow101 referenced this in commit 80067ac111 on Jul 18, 2025
  52. DashCoreAutoGuix referenced this in commit 542591c20f on Jul 29, 2025
  53. fanquake referenced this in commit 24246c3deb on Aug 1, 2025
  54. DashCoreAutoGuix referenced this in commit e2170fa44e on Aug 3, 2025
  55. DashCoreAutoGuix referenced this in commit 3db4396906 on Aug 5, 2025
  56. jsarenik commented at 4:29 pm on August 27, 2025: none

    Let me note here that I noticed the zero (tested with LN Anchor) outputs are not being cleared in a read-only descriptor wallet even after they’ve been spent by a fee-paying transaction in a package.

    UPDATE: no issue because I am unable to reproduce it on current master (6ca6f3b37b99). Seems to have been fixed some time ago.

    UPDATE2: See #33265 which works on current master (6ca6f3b37b99)

  57. instagibbs commented at 4:31 pm on August 27, 2025: member
    @jsarenik could you open a new issue?
  58. glozow added the label Tracking Issue on Oct 9, 2025
  59. DashCoreAutoGuix referenced this in commit a093b05535 on Nov 27, 2025
  60. glozow commented at 7:07 pm on January 28, 2026: member

    Closing this as completed. We have package validation and relay for the desired use cases; TRUC and cluster mempool fix pinning problems to a great extent.

    Here is a list of the most wortwhile ideas to be explored and deployed if deemed necessary (also discussed at coredev):

    (1) Extended topologies for TRUC-like things. For example, chains longer than 2 (the topology restriction should require a branching factor of 1 at each generation) can help with tree-like L2 structures (source: requests from various developers) The child size limit should be distributed amongst the descendants to maintain pinning bounds.

    (2) Sender-initiated package relay can be a way to increase orphan resolution throughput and save bandwidth; it should be carefully measured in real-world scenarios. This may not be very impactful given the current transaction volume. See #33500

    (3) Arbitrary package acceptance. This problem (namely, more generalized package RBF) is not as tractable as one would hope even with cluster mempool, and perhaps not necessary unless (4) is desired. There is a writeup somewhere and several draft implementations on my repository.

    (4) Ancestor package relay (BIP 331) to eliminate txid-based transaction relay. There should be some discussion as to whether this benefit warrants a protocol change. It may also be best to do something closer to “cluster prefix” instead of ancestor set so that fee-bumping nieces/nephews are included. Requires (3) unless we are ok with simply submitting one by one.

  61. glozow closed this on Jan 28, 2026
  62. ?
    project_v2_item_status_changed github-project-automation[bot]


glozow instagibbs ariard ajtowns AndriiHlukhovskyi tolex469 achow101 jsarenik

Labels
Feature Brainstorming TX fees and policy P2P Tracking Issue

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2026-02-10 21:13 UTC
This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me