Transaction Relay

What Is Transaction Relay?

Transaction relay is the peer-to-peer propagation mechanism that distributes unconfirmed transactions across the Bitcoin network. When a user broadcasts a transaction, their node sends it to connected peers, who validate it against local policy rules and forward it to their own peers. This gossip-like process continues until the transaction reaches miners, who may include it in the next block.

Without transaction relay, users would need to submit transactions directly to miners. Relay creates a decentralized broadcast layer where any node can originate a transaction and have it reach the entire network within seconds. This is fundamental to Bitcoin's censorship resistance: no single entity controls which transactions propagate.

The relay layer also serves as the network's first line of defense against denial-of-service attacks. Each node independently validates transactions before forwarding them, filtering out invalid, malformed, or economically irrational transactions before they consume further bandwidth.

How It Works

Transaction relay follows a three-step message exchange between peers, designed to minimize redundant data transfer across the P2P network:

1. The originating node sends an INV (inventory) message containing the transaction's identifier to each connected peer, with a random delay per peer to resist timing analysis
2. Each receiving peer checks whether it already knows the transaction. If not, it responds with a GETDATA message requesting the full transaction data
3. The originating node replies with a TX message containing the complete serialized transaction

This announcement-based approach avoids sending full transaction data to nodes that already have it. INV messages are small (just a hash), so the overhead of announcing to peers who already know the transaction is minimal. Since BIP 339, nodes announce transactions by their witness transaction ID (wtxid) rather than the legacy txid, preventing issues related to transaction malleability.

Standardness Rules

Before relaying a transaction, nodes run it through a set of standardness checks that are stricter than consensus rules. A transaction must pass these checks to be accepted into the mempool and forwarded to peers. Key standardness rules include:

• Transaction weight must not exceed 400,000 weight units (100 kvB)
• Output scripts must use recognized standard types: P2PKH, P2SH, P2WPKH, P2WSH, P2TR, or OP_RETURN
• Each scriptSig must not exceed 1,650 bytes
• Output values must be above the dust limit (except OP_RETURN outputs and ephemeral anchors)
• The transaction must pay at least the minimum relay fee

The distinction between relay policy and consensus is important: a non-standard transaction is not invalid. It can still be included in a block if submitted directly to a miner. Policy rules exist purely to protect the network from resource abuse during the relay process.

Minimum Relay Fee

The minimum relay fee is the lowest feerate a transaction must pay for nodes to accept and forward it. This serves as a price on network bandwidth consumption. As of Bitcoin Core 29.1 (September 2025), the default minRelayTxFee was reduced from 1,000 sat/kvB (1 sat/vB) to 100 sat/kvB (0.1 sat/vB), a 90% reduction reflecting improvements in relay efficiency and mempool management.

# Bitcoin Core configuration
# Default minimum relay fee (as of v29.1)
-minrelaytxfee=0.00000100  # 100 sat/kvB (0.1 sat/vB)

# Transactions below this feerate are not relayed or accepted
# into the mempool, regardless of their consensus validity

Mempool Size and Eviction

Each node maintains a limited-size mempool (default: 300 MB) of unconfirmed transactions. When the mempool fills up, the node evicts the lowest-feerate transactions first and raises its effective minimum fee to match. This dynamic fee floor means that during periods of high network congestion, the practical minimum relay fee can be significantly higher than the configured default.

Evicted transactions are not re-requested from peers. Once a transaction is dropped from a node's mempool due to size limits, it must be rebroadcast by the originating wallet or another node that still holds it.

Recent Developments

Package Relay

Traditional transaction relay evaluates each transaction independently. This creates a problem: a parent transaction with a feerate below the minimum relay fee will be rejected, even if a child transaction attached to it would make the package economically attractive to miners. This undermines CPFP fee bumping for pre-signed transactions like those used in Lightning channels.

Package relay (specified in BIP 331) solves this by allowing nodes to evaluate groups of related transactions together. Bitcoin Core 28.0 introduced opportunistic one-parent-one-child (1p1c) package relay, where a low-feerate parent can be relayed alongside a high-feerate child. The combined feerate of the package determines acceptance.

This was paired with TRUC (v3) transactions, which opt into topological restrictions: only one unconfirmed descendant is allowed, with a maximum size of 10,000 vB. These constraints make package evaluation tractable and enable reliable CPFP fee bumping for protocols like Lightning that rely on pre-signed transactions.

Full ancestor package relay, supporting more complex transaction topologies, remains under active development. For a deeper look at how these relay improvements interact with Lightning and other off-chain protocols, see the v3 transactions and package relay research article.

Erlay: Bandwidth-Efficient Relay

The current flooding-based relay protocol is bandwidth-intensive: every node announces every transaction to every peer via INV messages. For a node with 8 outbound connections, roughly 87.5% of INV messages are redundant because the receiving peer already knows the transaction.

Erlay (BIP 330) replaces most of this flooding with set reconciliation using the Minisketch library. Instead of announcing every transaction individually, peers periodically reconcile their mempool contents by exchanging compact sketches that encode the symmetric difference between their transaction sets. This reduces transaction announcement bandwidth by approximately 40%.

The Erlay handshake message (sendtxrcncl) was merged into Bitcoin Core in 2022, and a comprehensive implementation is under active review as of 2026. Nodes that support Erlay negotiate reconciliation-based relay during connection setup; those that do not fall back to standard flooding seamlessly. For technical details on how set reconciliation works, see the Erlay protocol deep dive.

Replace-by-Fee

Replace-by-fee (RBF) allows a transaction in the mempool to be replaced by a conflicting transaction that pays a higher fee. This relay policy is critical for fee bumping: if a transaction is stuck due to a low fee, the sender can create a replacement with a higher feerate.

Bitcoin Core 28 made full RBF the default policy, and Core 29 made it unconditional by removing the configuration option entirely. Under full RBF, any unconfirmed transaction can be replaced regardless of whether it signals replaceability via BIP 125. The replacement must pay a higher absolute fee and a higher feerate, and must not evict more than 100 transactions from the mempool.

Why It Matters

Transaction relay policy directly affects the user experience and security of every Bitcoin transaction. Relay rules determine which transactions propagate, how quickly they reach miners, and what fee bumping strategies are available when fees spike.

For layer-2 protocols like Lightning and Spark, relay policy is especially important. These protocols rely on the ability to broadcast pre-signed transactions under adversarial conditions. If a time-sensitive transaction (such as a justice transaction or a HTLC timeout) cannot propagate through the relay network, funds may be at risk. Improvements like package relay and TRUC transactions directly address these transaction pinning vulnerabilities.

Wallet developers must also account for relay policy when constructing transactions. Outputs below the dust limit, non-standard scripts, or feerates below the dynamic minimum will cause transactions to be silently dropped by the network. Understanding relay rules is essential for building reliable Bitcoin applications.

Risks and Considerations

Relay Policy Is Not Consensus

Different nodes can run different relay policies. A transaction rejected by one node's policy may be accepted by another. This means relay is not guaranteed: even a valid, standard transaction might fail to propagate if network-wide mempool congestion raises the effective minimum fee above what it pays.

Privacy Concerns

Transaction relay can leak information about which node originated a transaction. Network observers can use timing analysis to trace transactions back to their source IP address. Mitigations include the Dandelion protocol (which routes transactions through a random stem phase before flooding) and using Tor for P2P connections, though neither is enabled by default in Bitcoin Core.

Transaction Pinning

An attacker can exploit relay and mempool rules to prevent a victim's transaction from being confirmed. By crafting a conflicting transaction that is expensive to replace (for example, one with many descendants), the attacker "pins" the victim's transaction. This is particularly dangerous for time-sensitive payment channel transactions. TRUC transactions and package relay were designed in part to mitigate pinning attacks by limiting descendant topology and enabling package-level replacement.

Censorship at the Relay Layer

While Bitcoin's consensus rules are permissionless, relay policy is not. Nodes can choose not to relay specific transactions, and a sufficiently connected adversary could theoretically suppress a transaction by controlling enough relay nodes. In practice, the large number of independent nodes and alternative submission methods (direct miner APIs, satellite broadcast) make sustained relay censorship difficult but not impossible.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.