Bitcoin Full Node Bandwidth Calculator

How Much Bandwidth Does a Bitcoin Full Node Use?

Running a Bitcoin full node requires ongoing bandwidth for relaying blocks, propagating transactions, and serving data to peers. The total monthly usage varies dramatically depending on your configuration: a default listening node with inbound connections open typically uploads 150 to 300 GB per month and downloads roughly 20 GB, while a non-listening node with only outbound connections may use as little as 5 to 10 GB total.

The single largest bandwidth event is the initial block download (IBD), which requires downloading and validating the entire blockchain. As of 2026, this means transferring approximately 740 GB of block data. After IBD completes, steady-state bandwidth depends on peer count, whether you relay transactions or run in blocksonly mode, your mempool size limit, and whether you route traffic through Tor.

Bandwidth Estimates by Configuration

The following table estimates monthly bandwidth for a fully synced node under different configurations. Upload is the dominant cost because listening nodes serve block and transaction data to many inbound peers. All figures assume average 2025 block sizes of approximately 1.6 to 1.9 MB and a base rate of 144 blocks per day.

Upload dominates because each inbound peer may request blocks, headers, and transaction inventory from your node. A listening node with the default 125-connection limit can serve dozens of peers simultaneously, each requesting different data. Non-listening nodes only maintain outbound connections (currently 11 by default in Bitcoin Core: 8 full-relay, 2 block-relay-only, and 1 short-lived feeler connection), which drastically reduces upload.

Key Configuration Parameters

Bitcoin Core exposes several settings that directly affect bandwidth consumption. Understanding these parameters helps you tune your node to match your internet plan.

Peer Connections (-maxconnections)

The -maxconnections flag controls the total number of peer connections your node maintains. The default is 125. Reducing this value lowers both upload and download, though Bitcoin Core's trustless security model works best when connected to multiple diverse peers. Setting it below 11 reduces outbound connections and may weaken your node's view of the network.

Compact Block Relay

Compact block relay (BIP 152) reduces block propagation bandwidth by transmitting only short transaction identifiers instead of full transaction data. Since your node already has most transactions in its mempool, it can reconstruct the full block locally. Bitcoin Core supports two modes: low-bandwidth mode (the default for most peers) announces a header hash and sends compact data only on request, while high-bandwidth mode pushes compact blocks immediately to a few selected peers for lower latency. Compact blocks reduce per-block relay data significantly compared to legacy full block transmission.

Blocksonly Mode (-blocksonly)

The -blocksonly flag disables transaction relay entirely, cutting bandwidth by approximately 88% according to Bitcoin Core documentation. Your node still downloads and validates every block but skips relaying unconfirmed transactions. The tradeoffs: fee estimation stops working, wallet auto-broadcast is disabled, and you lose the privacy benefit of relaying others' transactions (which helps obscure which transactions originated from your node). The mempool limit drops to 5 MB in this mode.

Mempool Size (-maxmempool)

The -maxmempool setting caps your node's mempool memory usage, defaulting to 300 MB. A larger mempool means accepting and relaying more unconfirmed transactions, which increases bandwidth. Reducing this value to 100 MB or 50 MB causes your node to evict low-feerate transactions sooner, reducing relay traffic at the cost of compact block efficiency: if your mempool has fewer transactions, you may need to request more full transaction data when reconstructing compact blocks. The minimum configurable value is 5 MB.

Upload Target (-maxuploadtarget)

The -maxuploadtarget option sets a soft daily upload budget in MiB (disabled by default). When the limit is approached, your node stops serving historic blocks older than one week but continues relaying new blocks and transactions. This primarily reduces upload from serving IBD data to new peers. Peers with the download permission are never disconnected, though their traffic still counts toward the target.

Pruned vs. Full Archive (-prune)

A pruned node validates the entire chain during initial sync but discards old block data afterward, keeping only recent blocks (configurable, minimum 550 MB). This reduces disk usage from over 740 GB to under 10 GB. For bandwidth, pruning primarily reduces upload: your node cannot serve historical blocks to peers performing their own IBD. Steady-state download remains the same because your node still receives every new block regardless of pruning. For disk planning details, see the Bitcoin node storage calculator.

Tor Routing (-proxy, -onion)

Running your node over Tor adds overhead from onion routing, which wraps each packet through at least three relay hops. There are no widely published measurements of the exact bandwidth overhead for Bitcoin Core over Tor, but the Tor protocol adds cell padding and per-hop encryption that typically increases data volume by an estimated 10 to 20%. More importantly, Tor significantly reduces throughput: measurement studies have found that Tor-connected Bitcoin nodes operate at roughly one-tenth the bandwidth of clearnet nodes, meaning IBD takes much longer. For ongoing block relay with modest peer counts, Tor overhead is manageable.

ISP Data Caps and Node Compatibility

Many home internet plans impose monthly data caps that can conflict with running a full node, especially a listening node with default settings. The following table shows common US ISP data caps as of 2025 and whether they accommodate different node configurations.

If your ISP enforces a 1 TB cap, a default listening node using 170 to 320 GB per month will consume 15 to 30% of your cap before accounting for other household internet usage. During months of heavy network congestion or if many new nodes are syncing from you, upload can spike well beyond 300 GB. The safest options under a data cap: run a non-listening node, enable blocksonly mode, or set -maxuploadtarget to a daily budget that fits your plan.

Bandwidth Reduction Strategies

Combining multiple configuration flags compounds their bandwidth savings. The following strategies are ordered from least to most restrictive.

1. Set -maxuploadtarget=5000 (approximately 5 GB/day or 150 GB/month) to cap historical block serving while continuing to relay new blocks and transactions normally.
2. Lower -maxconnections to 40 or 50 to reduce the number of peers requesting data, while maintaining enough connections for reliable block propagation.
3. Disable listening with -listen=0 to restrict your node to outbound connections only. This is the single most effective bandwidth reduction, cutting upload by 90% or more.
4. Enable -blocksonly to stop relaying unconfirmed transactions. Combined with non-listening mode, total bandwidth drops to approximately 3 to 7 GB per month.
5. Enable -prune=550 (minimum prune target in MB) to prevent serving historical blocks entirely. This further reduces upload but means other nodes cannot sync from you.

Each of these options trades network contribution for lower bandwidth. The Bitcoin network relies on archive listening nodes to serve IBD data to new peers. If your connection supports it, running a full archive listening node strengthens the network. For a full cost breakdown including hardware, electricity, and bandwidth, see the Bitcoin node cost calculator.

Understanding the Bandwidth Math

At a base level, a Bitcoin node downloads every new block. With an average block size of approximately 1.7 MB and 144 blocks per day, that is roughly 245 MB of new block data daily, or about 7.3 GB per month. On top of blocks, a node relaying transactions receives and forwards the contents of its mempool: during periods of normal activity, transaction relay can add 10 to 15 GB per month of download and similar upload per peer. The upload multiplier comes from serving this data to many inbound peers simultaneously.

Compact block relay reduces the per-block transmission to roughly 10 to 20 KB of short transaction IDs, with full transaction round-trips only for the handful of transactions your node missed. This saves most of the per-block bandwidth compared to legacy relay, where entire 1.7 MB blocks would be retransmitted. The savings compound across peers: without compact blocks, serving a new block to 50 inbound peers would cost roughly 85 MB of upload per block.

For a broader perspective on running a Bitcoin node, including hardware and electricity costs, see our research on Bitcoin full node cost requirements in 2026.

Layer 2 Nodes and Bandwidth

If you are running a Bitcoin full node to support a layer 2 protocol like the Lightning Network or Spark, your base layer node bandwidth requirements remain the same as described above. The L2 protocol itself adds additional bandwidth for its own peer-to-peer communication, but this is typically modest compared to Bitcoin block relay. Spark's architecture avoids channel management overhead entirely, reducing the operational complexity of running Bitcoin-native infrastructure.

Frequently Asked Questions

How much bandwidth does a Bitcoin full node use per month?

A default listening node (accepting inbound connections) typically uses 150 to 300 GB of upload and about 20 GB of download per month, totaling 170 to 320 GB. A non-listening node with only outbound connections uses approximately 5 to 10 GB total. These figures assume the node is fully synced and running with default Bitcoin Core settings.

Can I run a Bitcoin node on a 1 TB data cap?

Yes, but you will likely need to disable inbound connections (-listen=0) or set an upload target (-maxuploadtarget). A non-listening node uses only 5 to 10 GB per month, well within a 1 TB cap. A default listening node risks consuming 15 to 30% of that cap, which can be problematic when combined with other household internet usage.

Does blocksonly mode significantly reduce bandwidth?

Yes. Bitcoin Core's documentation states that blocksonly mode reduces bandwidth by approximately 88%. It achieves this by disabling transaction relay entirely, so your node only downloads and uploads block data. The tradeoff is that fee estimation stops working, your wallet cannot auto-broadcast transactions, and compact block reconstruction becomes less efficient.

How much bandwidth does the initial block download require?

The initial block download (IBD) for a new node requires transferring approximately 740 GB of block data as of 2026. This is a one-time cost that can take several hours to several days depending on your internet speed, CPU, and disk performance. After IBD completes, ongoing bandwidth drops to the steady-state figures described above.

Does running a Bitcoin node over Tor use more bandwidth?

Tor adds an estimated 10 to 20% bandwidth overhead due to onion routing cell padding and per-hop encryption. The more significant impact is reduced throughput: Tor-connected nodes typically operate at a fraction of clearnet speeds, which primarily affects IBD duration rather than monthly data volume. For a fully synced node with modest peer counts, Tor overhead is manageable.

Does a pruned node use less bandwidth than a full archive node?

A pruned node uses less upload bandwidth because it cannot serve historical blocks to peers performing their initial sync. Download bandwidth remains the same: your node still receives every new block regardless of pruning. The primary benefit of pruning is disk savings (under 10 GB vs. over 740 GB), not bandwidth reduction. For storage planning, see the Bitcoin node storage calculator.

What is the minimum bandwidth needed to run a Bitcoin node?

A minimal configuration (blocksonly, non-listening, pruned) can operate on as little as 3 to 6 GB per month after the initial sync. Bitcoin Core's documentation suggests a minimum of approximately 144 MiB per day (about 4.2 GB per month) to keep up with new blocks at the theoretical limit of one 1 MB block every 10 minutes.

This tool is for informational purposes only and does not constitute financial or technical advice. Bandwidth estimates are approximate and vary with network conditions, peer behavior, and Bitcoin Core version. Actual usage depends on your specific configuration and ISP plan. Always monitor your bandwidth consumption when running a node under a data cap.