Package relay - Revision history

NotATether: Add Package rules, Opportunistic relay, Related policies sections

2026-09-13T07:30:01Z

Add Package rules, Opportunistic relay, Related policies sections

← Older revision		Revision as of 07:30, 13 September 2026
Line 2:		Line 2:

	Bitcoin P2P transaction relay historically advertised one txid at a time. A peer who receives a transaction below <code>minrelaytxfee</code> rejects it. Contracting protocols that sign zero-fee or low-fee parents and bump them with a child therefore fail to propagate on nodes that have not already accepted the parent by other means. Local <code>submitpackage</code> allowed submitting a package to one node, but peers could not request packages from each other.		Bitcoin P2P transaction relay historically advertised one txid at a time. A peer who receives a transaction below <code>minrelaytxfee</code> rejects it. Contracting protocols that sign zero-fee or low-fee parents and bump them with a child therefore fail to propagate on nodes that have not already accepted the parent by other means. Local <code>submitpackage</code> allowed submitting a package to one node, but peers could not request packages from each other.

			== Package rules ==

	A package is a list of transactions in topological order. Validation applies consensus rules to each transaction, then package-level policy: the package feerate must meet the mempool minimum, transactions must not conflict with one another, and for the limited 1-parent-1-child (1p1c) case the graph must be one parent and one child. The parent may be below the minimum relay feerate if the package as a whole is not.		A package is a list of transactions in topological order. Validation applies consensus rules to each transaction, then package-level policy: the package feerate must meet the mempool minimum, transactions must not conflict with one another, and for the limited 1-parent-1-child (1p1c) case the graph must be one parent and one child. The parent may be below the minimum relay feerate if the package as a whole is not.

			== Opportunistic relay ==

	On the P2P network, when a node rejects a transaction as too low-feerate, it may remember the txid briefly. If a later child arrives that spends that txid, the node requests the parent again and validates the pair. Bitcoin Core 28.0 implemented this opportunistic 1p1c path and allowed [[TRUC]] parents to pay zero fee. Bitcoin Core 31.0 extended zero-fee parents to non-TRUC 1p1c packages. A child may have additional parents that are already in the mempool. A child with several unconfirmed missing parents is not covered by this limited P2P feature.		On the P2P network, when a node rejects a transaction as too low-feerate, it may remember the txid briefly. If a later child arrives that spends that txid, the node requests the parent again and validates the pair. Bitcoin Core 28.0 implemented this opportunistic 1p1c path and allowed [[TRUC]] parents to pay zero fee. Bitcoin Core 31.0 extended zero-fee parents to non-TRUC 1p1c packages. A child may have additional parents that are already in the mempool. A child with several unconfirmed missing parents is not covered by this limited P2P feature.

			Full peer-to-peer package negotiation (sometimes discussed as BIP 331 style package relay) would let nodes announce and request packages explicitly. Bitcoin Core's opportunistic path is narrower. It reconstructs a 1p1c package only when a low-feerate parent was recently rejected and a spending child later arrives. That is enough for many TRUC and ephemeral-anchor flows. It is not a general multi-parent package gossip protocol.

			Wallets that need guaranteed local acceptance can still use <code>submitpackage</code> even when opportunistic P2P reconstruction fails on some peers.

			== Related policies ==

	Package RBF (documented on [[Mempool#Package RBF\|Mempool]]) lets a package replace in-mempool transactions when the replacement is incentive-compatible. [[Ephemeral_anchor\|Ephemeral anchor]] constructions depend on package relay: a zero-fee parent with a dust pay-to-anchor output is not accepted alone and must arrive with its child.		Package RBF (documented on [[Mempool#Package RBF\|Mempool]]) lets a package replace in-mempool transactions when the replacement is incentive-compatible. [[Ephemeral_anchor\|Ephemeral anchor]] constructions depend on package relay: a zero-fee parent with a dust pay-to-anchor output is not accepted alone and must arrive with its child.

	~~Full peer~~-to-~~peer~~ package ~~negotiation (sometimes discussed as BIP 331 style package relay)~~ would ~~let nodes announce and request packages explicitly. Bitcoin Core's opportunistic path~~ is ~~narrower~~. ~~It reconstructs a~~ 1p1c ~~package only~~ when ~~a low-feerate parent was recently rejected~~ and ~~a spending child later arrives. That is enough for many TRUC and ephemeral-anchor flows. It is not a general multi-parent package gossip protocol~~.		Package acceptance interacts with [[Cluster mempool\|cluster mempool]] limits and [[Replace by fee\|replace-by-fee]] rules. A package that would create an oversized cluster or that fails incentive-compatibility checks is rejected even if each transaction is consensus-valid. Wallet software that builds CPFP bumps should prefer topologies that match the 1p1c policy when targeting broad relay, or submit directly to miners and to local <code>submitpackage</code> when more complex graphs are required.

	Package acceptance interacts with [[Cluster mempool\|cluster mempool]] limits and [[Replace by fee\|replace-by-fee]] rules. A package that would create an oversized cluster or that fails incentive-compatibility checks is rejected even if each transaction is consensus-valid. Wallet software that builds CPFP bumps should prefer topologies that match the 1p1c policy when targeting broad relay, or submit directly to miners and to local <code>submitpackage</code> when more complex graphs are required.

	== See also ==		== See also ==

NotATether: Expand See also links

2026-09-12T21:13:50Z

Expand See also links

← Older revision		Revision as of 21:13, 12 September 2026
Line 16:		Line 16:
	* [[Mempool]]		* [[Mempool]]
	* [[TRUC]]		* [[TRUC]]
			* [[Cluster mempool]]
	* [[Replace by fee]]		* [[Replace by fee]]
			* [[Pay-to-anchor]]
	* [[Ephemeral_anchor\|Ephemeral anchor]]		* [[Ephemeral_anchor\|Ephemeral anchor]]
	* [[Transaction pinning]]		* [[Transaction pinning]]

NotATether: Add cluster mempool interaction and wallet guidance

2026-09-12T21:13:48Z

Add cluster mempool interaction and wallet guidance

← Older revision		Revision as of 21:13, 12 September 2026
Line 10:		Line 10:

	Full peer-to-peer package negotiation (sometimes discussed as BIP 331 style package relay) would let nodes announce and request packages explicitly. Bitcoin Core's opportunistic path is narrower. It reconstructs a 1p1c package only when a low-feerate parent was recently rejected and a spending child later arrives. That is enough for many TRUC and ephemeral-anchor flows. It is not a general multi-parent package gossip protocol.		Full peer-to-peer package negotiation (sometimes discussed as BIP 331 style package relay) would let nodes announce and request packages explicitly. Bitcoin Core's opportunistic path is narrower. It reconstructs a 1p1c package only when a low-feerate parent was recently rejected and a spending child later arrives. That is enough for many TRUC and ephemeral-anchor flows. It is not a general multi-parent package gossip protocol.

			Package acceptance interacts with [[Cluster mempool\|cluster mempool]] limits and [[Replace by fee\|replace-by-fee]] rules. A package that would create an oversized cluster or that fails incentive-compatibility checks is rejected even if each transaction is consensus-valid. Wallet software that builds CPFP bumps should prefer topologies that match the 1p1c policy when targeting broad relay, or submit directly to miners and to local <code>submitpackage</code> when more complex graphs are required.

	== See also ==		== See also ==

NotATether: Add opportunistic vs full package negotiation

2026-09-12T21:13:46Z

Add opportunistic vs full package negotiation

← Older revision		Revision as of 21:13, 12 September 2026
Line 8:		Line 8:

	Package RBF (documented on [[Mempool#Package RBF\|Mempool]]) lets a package replace in-mempool transactions when the replacement is incentive-compatible. [[Ephemeral_anchor\|Ephemeral anchor]] constructions depend on package relay: a zero-fee parent with a dust pay-to-anchor output is not accepted alone and must arrive with its child.		Package RBF (documented on [[Mempool#Package RBF\|Mempool]]) lets a package replace in-mempool transactions when the replacement is incentive-compatible. [[Ephemeral_anchor\|Ephemeral anchor]] constructions depend on package relay: a zero-fee parent with a dust pay-to-anchor output is not accepted alone and must arrive with its child.

			Full peer-to-peer package negotiation (sometimes discussed as BIP 331 style package relay) would let nodes announce and request packages explicitly. Bitcoin Core's opportunistic path is narrower. It reconstructs a 1p1c package only when a low-feerate parent was recently rejected and a spending child later arrives. That is enough for many TRUC and ephemeral-anchor flows. It is not a general multi-parent package gossip protocol.

	== See also ==		== See also ==

NotATether: Create Package relay stub (1p1c / mempool package policy)

2026-09-12T03:44:21Z

Create Package relay stub (1p1c / mempool package policy)

New page

'''Package relay''' is a transaction-relay and [[Mempool|mempool]]-acceptance policy in which a group of related transactions is evaluated together rather than one at a time. The usual case is a parent that pays little or no fee and a child that pays enough for both (child-pays-for-parent). Without package relay, a node that enforces a minimum relay feerate drops the parent and never learns about the child.

Bitcoin P2P transaction relay historically advertised one txid at a time. A peer who receives a transaction below <code>minrelaytxfee</code> rejects it. Contracting protocols that sign zero-fee or low-fee parents and bump them with a child therefore fail to propagate on nodes that have not already accepted the parent by other means. Local <code>submitpackage</code> allowed submitting a package to one node, but peers could not request packages from each other.

A package is a list of transactions in topological order. Validation applies consensus rules to each transaction, then package-level policy: the package feerate must meet the mempool minimum, transactions must not conflict with one another, and for the limited 1-parent-1-child (1p1c) case the graph must be one parent and one child. The parent may be below the minimum relay feerate if the package as a whole is not.

On the P2P network, when a node rejects a transaction as too low-feerate, it may remember the txid briefly. If a later child arrives that spends that txid, the node requests the parent again and validates the pair. Bitcoin Core 28.0 implemented this opportunistic 1p1c path and allowed [[TRUC]] parents to pay zero fee. Bitcoin Core 31.0 extended zero-fee parents to non-TRUC 1p1c packages. A child may have additional parents that are already in the mempool. A child with several unconfirmed missing parents is not covered by this limited P2P feature.

Package RBF (documented on [[Mempool#Package RBF|Mempool]]) lets a package replace in-mempool transactions when the replacement is incentive-compatible. [[Ephemeral_anchor|Ephemeral anchor]] constructions depend on package relay: a zero-fee parent with a dust pay-to-anchor output is not accepted alone and must arrive with its child.

== See also ==
* [[Mempool]]
* [[TRUC]]
* [[Replace by fee]]
* [[Ephemeral_anchor|Ephemeral anchor]]
* [[Transaction pinning]]

== External links ==
* [https://bitcoinops.org/en/topics/package-relay/ Bitcoin Optech: Package relay]
* [https://bitcoincore.org/en/releases/28.0/ Bitcoin Core 28.0 release notes]
* [https://bitcoincore.org/en/releases/31.0/ Bitcoin Core 31.0 release notes]

[[Category:Technical]]