8000 Package Relay Project Tracking · Issue #27463 · bitcoin/bitcoin · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content
Package Relay Project Tracking #27463
Open
@glozow

Description

@glozow

This issue will be edited frequently to reflect the current status of the project.

What is ready for review now?

👇 👇 👇
#31829
☝️ ☝️ ☝️

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.

See PRs

☑️ (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.

See PRs

☑️ (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.

☑️ (2b) Package RBF for cluster size 2

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

☑️ (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).

(4) TxDownloadManager and orphan-handling improvements

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

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

See also:

Superseded/Deferred Work

Prehistory

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    Status

    TRACKING HERE

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      0