Home › Glossary › Package relay

Package relay

Also called: BIP 331, ancestor package relay, 1p1c relay, package RBF, transaction packages.

Package relay lets Bitcoin nodes accept and relay related unconfirmed transactions together, so a high-fee child can carry a low-fee parent.

Package relay means nodes evaluate and forward a group (package) of dependent unconfirmed transactions together, instead of one at a time. Its main purpose is to make child pays for parent reliable. Without it, a parent whose fee rate is below a node's minimum is rejected on its own, and the high-fee child that would pay for it is then dropped too, because its parent is missing.

Why package relay matters

Contract protocols such as the Lightning Network pre-sign transactions with fees chosen days or months earlier. If fees rise, those transactions may not reach miners' mempools at all, and as BIP 331 explains, a counterparty can exploit that to steal funds. Package relay lets the honest party attach a fee-paying child at broadcast time, and package-aware replace-by-fee lets a package replace a conflicting transaction.

BIP 331: ancestor package relay

BIP 331, by Gloria Zhao, specifies the peer-to-peer messages. Peers agree on support with a sendpackages message during the handshake, then:

  • ancpkginfo lists the wtxids of a transaction's unconfirmed ancestor package;
  • getpkgtxns and pkgtxns request and send several transactions in one round trip.

It requires wtxid-based relay (BIP 339), because packages are identified by wtxid.

TRUC (version 3) transactions from BIP 431 restrict a package to one parent and one child, which makes evaluation and replacement much simpler and resists pinning. Bitcoin Core already relays one-parent-one-child packages opportunistically, and the keyless anchor output in BIP 433 is designed for that pattern. The replace-by-fee guide shows how these pieces fit together for fee bumping.

BIPs that define Package relay

  • BIP 331: Ancestor Package Relay: Draft. Lets nodes request and share an unconfirmed transaction together with the parent transactions it depends on, as a single package. This helps low-fee parents get relayed when a child pays extra fees…
  • BIP 431 (TRUC transactions): Topology Restrictions for Pinning: Draft. Explains 'pinning', a problem where someone can block a transaction from being replaced with a higher-fee version, which can endanger time-sensitive protocols like Lightning. It describes stricter…
  • BIP 339: WTXID-based transaction relay: Deployed. Nodes share new transactions by announcing short identifiers, and this change lets them use the "wtxid", an identifier that also covers a transaction's SegWit signature data. The older identifier…
  • BIP 433: Pay to Anchor (P2A): Draft. Defines Pay to Anchor, a tiny standard output that anyone can spend without a signature. Its purpose is to act as a hook for fee-bumping: by spending it in a follow-up transaction, any party can add…

Related terms

  • Child pays for parent (CPFP): Child pays for parent (CPFP) speeds up a stuck transaction by spending one of its outputs in a new high-fee transaction, so miners confirm both together.
  • Mempool: The mempool is a node's waiting area for valid, unconfirmed transactions; miners choose from it, usually by fee rate, when they build a block.
  • Anchor output: An anchor output is a small extra output on a pre-signed transaction that can be spent by a CPFP child to add fees when the transaction is broadcast.
  • Replace-by-fee (RBF): Replace-by-fee (RBF) lets you replace an unconfirmed Bitcoin transaction with a new version that pays a higher fee, so it confirms sooner.

Learn more

Guides