Package Relay (BIP-331)

Package relay is an enhancement to Bitcoin's peer-to-peer transaction relay, formalized as BIP-331, that lets nodes announce and evaluate a group of related transactions as a single unit rather than judging each one in isolation. Its purpose is to make child-pays-for-parent (CPFP) fee bumping reliable across the whole network, especially for time-sensitive second-layer transactions whose fees were fixed long before broadcast.

The problem it solves

A node's mempool normally rejects any transaction whose own feerate falls below its floor — during congestion, nodes raise that floor to shed load. This breaks CPFP at the relay layer: if a low-fee parent is rejected on arrival, the high-fee child meant to bump it can never even be evaluated, because the parent it spends from is not in the mempool. The child is dropped as an orphan, and the pair never reaches miners — even though a miner would happily take both, since the child's fee pays for the package. The failure is invisible to the user: the transactions are valid, profitable to mine, and simply cannot propagate.

How packages fix it

With package relay, a node can offer a parent and child together and assess them by their combined feerate. If the package as a whole clears the node's floor, both are accepted and forwarded together. The deployed design deliberately targets the 1-parent-1-child ("1p1c") topology, which covers the dominant real-world need — a pre-signed transaction plus one fee-bumping child — while keeping the DoS-analysis surface small. Bitcoin Core has long used ancestor-aware scoring internally when miners build block templates; package relay extends that same package-level thinking outward to mempool acceptance and propagation, closing the gap between what miners would mine and what the network will carry to them. It works alongside the TRUC/v3 transaction rules and ephemeral anchors, which standardize a clean, anyone-can-bump fee attachment point.

Why second layers depend on it

The urgency comes from contracting protocols. A Lightning Network commitment transaction is signed potentially months before it is broadcast, at a feerate nobody can predict; when a channel closes unilaterally, the broadcaster must be able to bump it into a block before a timelock expires, or funds are at risk. Reliable package propagation is the difference between an anchor output that works under congestion and one that fails exactly when fees spike — and it shrinks the surface for transaction pinning attacks that exploit single-transaction relay quirks. It complements, rather than replaces, replace-by-fee (RBF): RBF bumps a transaction you can re-sign, CPFP-via-package bumps one you cannot.

For node runners, this is mempool policy evolving toward incentive-compatibility — your node relaying what miners actually want strengthens fee estimation and censorship resistance for everyone. D-Central tracks these relay-layer developments because a sound fee market is part of what keeps the mining economics honest; these are spec-level policy changes, not consensus changes, and require no soft fork. Consensus still accepts any valid block; what changes is only the network's willingness to carry certain transaction shapes between wallets and miners.

The broader lesson generalizes: Bitcoin's relay layer is where most of the network's practical behavior actually lives, and it evolves far faster than consensus because it can. A wallet developer who assumes "valid transaction" equals "propagating transaction" will eventually be surprised; the mempool's admission rules — feerate floors, ancestor limits, package logic — are the real gatekeepers between signing and confirmation. Package relay is the most user-visible of these improvements in years precisely because it fixes a case where a perfectly rational, fee-paying pair of transactions simply could not reach the miners willing to mine them. Quiet plumbing, but it is the kind that decides whether a Lightning channel's safety guarantees hold on the worst fee day of the year.