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

    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: Nothing right now :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.

    :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

    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.

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

    (4) TxDownloadManager and orphan-handling improvements

    • Modularize TxDownloadManager + testing
    • Make orphanage more robust
      • #30000
      • Orphan resolution tracker, try with all orphan announcers #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.

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

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

    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. fanquake pinned this on May 5, 2023
  15. 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 :)

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

    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.

  18. bitcoin deleted a comment on Aug 17, 2023
  19. bitcoin deleted a comment on Aug 17, 2023
  20. achow101 referenced this in commit 5666966dff on Aug 31, 2023
  21. 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.

  22. tolex469 commented at 10:24 pm on September 26, 2023: none
    Add new features
  23. achow101 unpinned this on Oct 5, 2023
  24. fanquake referenced this in commit 5d9f45082b on Nov 3, 2023
  25. achow101 referenced this in commit d9007f51a7 on Nov 3, 2023
  26. fanquake referenced this in commit d690f89b57 on Nov 8, 2023
  27. 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?
  28. 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
  29. 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.

  30. achow101 referenced this in commit 7143d43884 on Feb 10, 2024
  31. achow101 referenced this in commit d813ba1bc4 on Apr 30, 2024
  32. ryanofsky referenced this in commit 33303b2b29 on May 15, 2024
  33. achow101 referenced this in commit 6e4d18f37f on Jun 7, 2024
  34. fanquake referenced this in commit 9607277032 on Jul 24, 2024
  35. achow101 referenced this in commit 7b66815b16 on Oct 29, 2024
  36. 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.


glozow instagibbs ariard ajtowns AndriiHlukhovskyi tolex469 achow101

Labels
Feature Brainstorming TX fees and policy P2P

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: 2024-11-21 09:12 UTC
This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me