Package Relay lets Bitcoin nodes relay and assess related unconfirmed transactions together. It is useful when the first transaction offers too little in fees but another transaction spending its output adds enough for both. Their validity and the node’s local rules still matter; assessment as a package does not guarantee confirmation.
Anna is waiting for a bitcoin payment. The sender chose a low fee, and demand for block space has since increased. A block groups transactions into a batch added to the shared history. A node is software that checks transactions and blocks and communicates with other participants in the network. Some nodes therefore refuse to admit the transaction to their mempool, their local collection of unconfirmed transactions. Anna would like to add a fee through a follow-up transaction. But that transaction spends coins whose arrival the rejecting node does not yet know about. Package Relay helps bridge this gap: it brings the necessary context to a node so it need not assess only the cheap first transaction in isolation. [1] [6]
The first transaction is called the parent and the one spending its output the child. Anna can create a child if she can satisfy the spending conditions of a parent output: a specific amount available to be spent. She might send the received coins to another address of her own, allocating some to a fee. This is CPFP (Child Pays for Parent): the child’s higher fee can help both transactions confirm. Package Relay helps with delivery and assessment; it does not pay the fee, sign anything or grant access to someone else’s coins. [1] [5]
Suppose the parent is 200 vB and pays 200 sat, while the child is 100 vB and pays 1300 sat. A vByte (vB) measures virtual transaction size, commonly used to calculate fees; a sat is a small unit of bitcoin. Together they pay 1500 sat for 300 vB, or 5 sat/vB. This is not the simple average of their rates of 1 and 13 sat/vB. We assume only these two not-yet-accepted transactions, no other unconfirmed ancestors and no local fee adjustments. Real nodes do not count already accepted transactions again; the precise set of dependencies being assessed matters. [5] [3]
A child’s input refers to a parent’s output. Assessing them together may make sense, but missing history cannot simply be ignored. The list places each included parent before its child; this is called topological order. Signatures and all other validity rules still apply. A digital signature provides proof of authorization for a payment using a private key, a secret numerical value, without revealing that key. Two transactions spending the same coins do not become compatible because someone adds a fee. Limits on package count, size and shape also bound the node’s workload: packages are not permission to submit an arbitrary chain of transactions. [5] [3] [7]
A wallet is an application or device for receiving and sending bitcoin. Delivery means a node obtained the data. Acceptance means it put the transactions in its mempool under its own rules. Confirmation requires inclusion in a block. Each node has its own mempool; success at one does not tell us what a neighbour did. In Bitcoin Core 28.0, the combined rate can overcome the rising minimum of a crowded mempool, but does not generally remove the separate relay minimum. That version provides an exception for TRUC Transactions, a specially restricted transaction type. A sufficiently expensive child therefore cannot rescue every possible parent. [2] [5] [8]
Gloria Zhao’s BIP 331 describes negotiating support and messages for requesting ancestor information and transactions themselves. It is a broader proposal. Bitcoin Core 28.0 documented limited pairing of one parent with one child through the existing network protocol. Its local RPC programming interface could also accept a child with several independent parents, but this did not imply equivalent support for relaying between nodes. These details refer to that version; for another version, check its documentation and the capabilities of the peer as well. [1] [2]
The submitpackage command in Bitcoin Core 28.0 submits a prepared package to the local node. It expects a child and its unconfirmed parents, with no dependencies between those parents, and the child last. Read package_msg alongside the individual tx-results. The node may accept part of the package: an error does not automatically undo everything already accepted. Even overall success proves neither network propagation nor confirmation. The command is not a general payment acceleration service; it requires correctly constructed transactions, not just addresses. [3]
In a separate test environment, testmempoolaccept checks acceptance without broadcasting. If another transaction fails, the allowed result may be absent because this transaction was not fully validated. The test call and submitpackage also have somewhat different conditions. Record the version, settings, dependencies, sizes and fees, and separately observe acceptance at another node. Time-sensitive Lightning Network transactions still need a timely response: Package Relay alone does not remove congestion, irregular block timing or pinning, the deliberate use of mempool rules to obstruct fee bumping. [4] [2] [1]
For the clearest picture, read this entry together with Mempool, CPFP (Child Pays for Parent), Fee Rate, Replace-by-Fee (RBF), Lightning Network, vByte. The reverse links also lead from CPFP (Child Pays for Parent), Gloria Zhao, Cluster Mempool, TRUC Transactions.