Broadcast Transaction

What Is a Broadcast Transaction?

Broadcasting a transaction is the act of submitting a signed Bitcoin transaction to the peer-to-peer network so that nodes can validate it, add it to their mempools, and relay it to other nodes until a miner includes it in a block. Without broadcasting, a signed transaction is just data sitting on your local device: valid but invisible to the network.

Think of it like mailing a letter. Signing the transaction is writing and sealing the envelope. Broadcasting is dropping it in the mailbox. Until you broadcast, the network has no knowledge that you intend to move funds.

The broadcast step is deceptively simple on the surface, but it carries important implications for privacy, reliability, and transaction confirmation speed. How, when, and where you broadcast can determine whether your transaction confirms quickly, gets stuck in a congested mempool, or leaks your IP address to surveillance nodes.

How It Works

The full lifecycle from signing to confirmation follows a well-defined sequence governed by the Bitcoin P2P protocol:

1. You construct a raw transaction specifying inputs (UTXOs to spend), outputs (recipient addresses and amounts), and a change output
2. You sign the transaction with your private key(s), producing a valid witness or scriptSig
3. Your node sends an inv (inventory) message containing the transaction hash to all connected peers
4. Each peer that does not already have the transaction sends a getdata message requesting the full transaction
5. Your node responds with a tx message containing the full serialized transaction
6. The receiving peer validates the transaction (checks signatures, script validity, input availability, and fee adequacy), adds it to its mempool, and repeats the announcement process to its own peers
7. This flooding continues until the transaction reaches miners, who select it for inclusion in their next block template

The Three-Step Announcement Protocol

Bitcoin uses an announcement-based relay protocol rather than blindly forwarding full transactions. This three-step handshake (inv → getdata → tx) prevents transmitting the same transaction twice to the same peer, conserving bandwidth across the network.

Since BIP-339, nodes can negotiate wtxid-based relay during the version handshake. This uses the witness-inclusive transaction ID for announcements, preventing redundant downloads caused by witness malleation.

Propagation Speed

A typical Bitcoin Core node maintains up to 125 total connections: 8 full-relay outbound, 2 block-relay-only outbound, 1 feeler connection, and up to 114 inbound slots. Each relay hop adds a random delay drawn from an exponential distribution (a privacy measure to obscure the origination point).

In practice, a broadcast transaction reaches roughly 50% of all nodes within about 5 seconds and 90% within about 15 seconds. Full propagation across the network typically completes in 13 to 20 seconds.

Broadcast Methods

Bitcoin Core RPC

The most direct method is submitting via Bitcoin Core's RPC interface. The sendrawtransaction command accepts a hex-encoded signed transaction, validates it against the local node's mempool policy, and relays it to connected peers:

# Create, sign, and broadcast a transaction
bitcoin-cli createrawtransaction '[{"txid":"...","vout":0}]' '{"bc1q...":0.01}'
bitcoin-cli signrawtransactionwithwallet "hex_string"
bitcoin-cli sendrawtransaction "signed_hex"

# Optional: set maxfeerate (in BTC/kvB) to reject absurdly high fees
bitcoin-cli sendrawtransaction "signed_hex" 0.10

The testmempoolaccept RPC lets you dry-run a transaction against mempool policy without actually broadcasting, which is useful for validating fee levels and script correctness before committing.

Electrum Servers

Electrum wallets broadcast through the blockchain.transaction.broadcast RPC method exposed by Electrum protocol servers (ElectrumX, Fulcrum, or Electrs). The server validates the transaction and submits it to its connected Bitcoin Core backend.

For full sovereignty over broadcasting, users can run their own Electrum server connected to their own full node. This avoids trusting a third-party server with transaction data and IP address information.

Block Explorer APIs

Web-based services provide HTTP endpoints for broadcasting without running a node. Blockstream Esplora accepts a raw hex body via POST /tx and returns the txid on success. Mempool.space offers both a web interface at /tx/push and an equivalent API endpoint.

These are convenient for occasional use but carry privacy tradeoffs: the service operator sees your IP address and knows you originated the transaction. For repeated use, combining these APIs with a VPN or Tor mitigates the risk.

Tor-Based Broadcasting

Tor prevents network observers from correlating a broadcast with the sender's IP address. Bitcoin Core supports routing all P2P traffic through Tor via the -proxy option or operating as a Tor hidden service with an .onion address. Over 60% of reachable Bitcoin nodes now operate via Tor according to Bitnodes data.

Electrum wallets also support Tor proxying natively, allowing users to connect to .onion Electrum servers so that neither the server operator nor network observers learn the user's real IP address. For a deeper look at network-level privacy, see the research on Bitcoin's privacy landscape.

Privacy and Deanonymization Risks

Broadcasting is the most vulnerable moment for transaction privacy. While the Bitcoin blockchain is pseudonymous, the broadcast step can link a transaction to a real-world IP address.

Timing Analysis

An adversary can deploy a "supernode" that connects to as many Bitcoin nodes as possible and records the timestamp of the first inv message received for each transaction. The first-spy estimator links each transaction to the first node observed broadcasting it, since the originating node is statistically most likely to announce first.

Research by Biryukov et al. (2014) demonstrated that such supernodes could associate transactions with originator IP addresses with meaningful accuracy. A more sophisticated variant identifies each client by its set of outgoing connections (entry nodes), allowing the attacker to link a transaction to a specific client after receiving it from just 2 to 3 entry nodes.

Diffusion Spreading

Bitcoin Core's current mitigation is diffusion spreading: each relay node transmits to each neighbor with an independent random delay drawn from an exponential distribution. This replaced an earlier "trickle" protocol that used a fixed 200ms delay. While diffusion adds timing uncertainty, sophisticated adversaries who know the network graph topology can still exploit the symmetric spreading pattern.

The Dandelion Protocol (BIP-156)

The Dandelion protocol, proposed in BIP-156, introduces a two-phase broadcast mechanism designed to break the link between transaction originators and their IP addresses:

1. Stem phase: the transaction is forwarded along a single randomly selected path, one peer at a time. During this phase the transaction is not added to the node's mempool and is forwarded to only one peer per hop. Each hop has approximately a 10% chance of transitioning to the next phase, producing stem paths that average roughly 10 hops.
2. Fluff phase: after traveling the stem, the transaction transitions to standard diffusion (normal flooding to all peers). By this point, the transaction appears to originate from a node far removed from the actual sender.

An improved version called Dandelion++ addresses edge cases around nodes that do not follow the protocol, using a 4-regular graph for the stem phase and per-hop randomization. While BIP-156 was not merged into Bitcoin Core, Dandelion++ has been adopted by other cryptocurrencies including Grin and Zcash. For more context on Bitcoin network privacy techniques, see the research on Dandelion network privacy.

Common Broadcast Errors

When a broadcast fails, Bitcoin Core returns specific rejection reasons. Understanding these helps diagnose issues quickly:

The testmempoolaccept RPC is the safest way to check for these errors before broadcasting. If a transaction is rejected for insufficient fees, techniques like replace-by-fee (RBF) or child-pays-for-parent (CPFP) can help resolve the issue.

Use Cases

Standard Wallet Broadcasting

The most common use case is simply sending Bitcoin. A wallet constructs and signs a transaction, then broadcasts it to the network through a connected node or API. Most wallet software handles this automatically behind a "Send" button.

Transaction Batching

Exchanges and payment processors use transaction batching to combine multiple payments into a single broadcast. This reduces the number of transactions competing for block space and lowers per-payment fees. Timing the broadcast to coincide with lower fee periods further reduces costs.

Fee Bumping

When a transaction gets stuck in the mempool due to low fees, users broadcast a replacement transaction with a higher fee using RBF. The replacement is a new broadcast that signals to nodes that the original should be evicted from their mempools. Alternatively, CPFP involves broadcasting a child transaction that spends an output of the stuck parent, incentivizing miners to confirm both.

Layer 2 Settlement

Layer 2 protocols like the Lightning Network and Spark use on-chain broadcasts for channel opens, cooperative closes, and force closes. The timing of these broadcasts matters: a justice transaction must be broadcast within the timelock window to prevent a counterparty from stealing funds. For more on how Spark handles on-chain settlement, see the Spark layer 2 overview.

Future Improvements

Erlay (BIP-330)

Erlay proposes replacing the current flood-based transaction relay with set reconciliation using Minisketch. Instead of every node sending inv messages to every peer, only well-connected public nodes would flood transactions. All other relay would use efficient set reconciliation, where nodes periodically compare their mempool contents and exchange only the differences.

This approach is expected to reduce transaction relay bandwidth by approximately 40% with negligible impact on propagation latency. The bandwidth savings would allow nodes to maintain more connections without increased resource usage, strengthening the network's censorship resistance and connectivity.

Risks and Considerations

• IP address exposure: broadcasting through a clearnet node reveals your IP to all connected peers and potentially to adversarial supernodes monitoring the network. Use Tor or a trusted VPN to mitigate this risk.
• Rebroadcast leaks: Bitcoin Core periodically rebroadcasts wallet transactions that have not yet confirmed. This repeated broadcasting can further correlate your node with specific transactions, degrading privacy over time.
• Mempool rejection: transactions can be silently rejected by nodes with different mempool policies. A transaction accepted by your local node may not propagate to miners if it violates their policy (for example, non-standard scripts or insufficient fees during congestion).
• Single-point-of-failure APIs: relying on a single block explorer API for broadcasting means your transaction depends on that service's uptime and censorship posture. For critical transactions, broadcast through your own full node or use multiple independent services.
• Timing sensitivity: for time-critical broadcasts like justice transactions in Lightning ortimelock-dependent protocols, delays in propagation or mempool acceptance can result in financial loss.

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.