|
Getting your Trinity Audio player ready…
|
A Comprehensive Study on Payload-to-Overhead Ratios in Bitcoin Transaction Transmission
1. Introduction
Bitcoin, as a decentralized peer-to-peer currency system, relies on a global network of independently operated nodes to process and propagate transactions. When a user creates a Bitcoin transaction — say, paying someone for goods or services — the raw data that represents this payment is just a small number of bytes. Yet, getting that transaction from the originator to the rest of the network incurs a surprisingly large cost in terms of overhead.
This overhead comes from several layers:
- Bitcoin’s own peer-to-peer protocol, which uses small request and acknowledgement messages to announce and request transactions.
- The underlying transport stack (TCP/IP), which adds headers for addressing and reliable delivery.
- Link-layer protocols such as Ethernet, which add framing and timing gaps to ensure that data is moved correctly over the physical medium.
- Network-wide propagation, where the same transaction is repeatedly transmitted across thousands of peer connections until nearly all reachable nodes have a copy.
While miners also expend energy (hashing) to secure the network, this is a computational cost, not a transmission cost. Here, we are concerned strictly with network transmission overhead, measured in bits and bytes, relative to the payload — the transaction itself.
This study will quantify that overhead from a per-peer perspective, then scale the analysis to the entire Bitcoin network. The result is a clear picture of how a tiny piece of data balloons into megabytes of global traffic in the name of decentralization and redundancy.
2. Definitions and Scope
Before we get to the math, we need clear definitions.
- Payload: The serialized Bitcoin transaction bytes — the useful data we are trying to transmit.
- Overhead: All other data transmitted in order to deliver that payload:
- Bitcoin P2P headers and inventory/request messages.
- TCP/IP headers.
- Ethernet framing, preamble, and inter-frame gap (IFG).
- Any “chit-chat” that happens before the payload is sent (e.g., INV and GETDATA messages).
- Per-peer cost: The amount of payload and overhead exchanged between your node and one of its peers to transmit the transaction.
- Network-wide cost: The sum of all per-edge transmissions needed to flood the transaction to all reachable nodes in the Bitcoin network.
This scope does not include:
- Mining energy use or hash computations.
- Disk storage overhead for blocks and transactions.
- Higher-layer application logic beyond the standard Bitcoin Core protocol.
3. Anatomy of a Bitcoin Transaction Transmission
Let’s start with a concrete example of a small, typical transaction:
- Type: SegWit Pay-to-Witness-Public-Key-Hash (P2WPKH)
- Composition: 1 input, 2 outputs.
- Serialized size: ~222 bytes.
3.1. The Bitcoin P2P Protocol Steps
When your node has a new transaction to share:
- INV message: Your node tells each peer “I have something new,” including a 32-byte hash of the transaction.
- Message header: 24 bytes.
- Payload: 1-byte count + 36 bytes per transaction ID.
- Size for 1 tx: 24 + 37 = 61 bytes.
- GETDATA message: Peer replies “Send it to me.”
- Same size as INV for 1 tx: 61 bytes.
- TX message: Your node sends the transaction.
- Header: 24 bytes.
- Payload: 222 bytes transaction data.
- Total: 246 bytes.
3.2. P2P Overhead Summary (per peer)
| Message | Size (bytes) |
|---|---|
| INV | 61 |
| GETDATA | 61 |
| TX | 246 |
| Total | 368 |
Of these 368 bytes, only 222 bytes are the payload. The rest (146 bytes) is Bitcoin P2P protocol overhead.
4. Adding the Networking Layers
4.1. TCP/IP Headers
- IP header: 20 bytes (no options).
- TCP header: 20 bytes (no options).
- Total: 40 bytes per TCP segment.
4.2. Ethernet Frame Overhead
- Ethernet header: 14 bytes.
- Frame Check Sequence (FCS): 4 bytes.
- Total frame overhead: 18 bytes.
4.3. On-Wire Gaps
Ethernet also uses:
- Preamble + Start Frame Delimiter (SFD): 8 bytes.
- Inter-frame gap (IFG): 12 bytes.
- Total: 20 bytes.
4.4. Per-Segment “Wire” Overhead
Summing: 40 (IP+TCP)+18 (Ethernet hdr/FCS)+20 (preamble/IFG)=78 bytes40 \ \text{(IP+TCP)} + 18 \ \text{(Ethernet hdr/FCS)} + 20 \ \text{(preamble/IFG)} = 78 \ \text{bytes}
5. Total Per-Peer Transmission Cost
Each of the three messages (INV, GETDATA, TX) is small enough to fit in a single TCP segment. That means we pay 78 bytes of wire overhead per message.
- Wire overhead for 3 segments: 3×78=234 bytes3 \times 78 = 234 \ \text{bytes}
- Bitcoin P2P overhead: 146 bytes.
- Total overhead per peer: 146+234=380 bytes146 + 234 = 380 \ \text{bytes}
5.1. Bits Conversion
- Payload: 222×8=1,776 bits222 \times 8 = 1,776 \ \text{bits}
- Overhead: 380×8=3,040 bits380 \times 8 = 3,040 \ \text{bits}
Ratio (payload : overhead) = 1,776:3,0401,776 : 3,040 ≈ 0.584 : 1.
In other words, for every 1 bit of overhead, we have only 0.58 bits of transaction data.
6. Scaling Up: Your Node’s 8 Outbound Peers
Bitcoin Core by default maintains 8 outbound connections.
If you send this transaction to all of them:
- Payload total: 1,776 bits×8=14,208 bits1,776 \ \text{bits} \times 8 = 14,208 \ \text{bits} (~1.78 KB)
- Overhead total: 3,040 bits×8=24,320 bits3,040 \ \text{bits} \times 8 = 24,320 \ \text{bits} (~3.04 KB)
- Combined: 4,816 bits×8=38,528 bits4,816 \ \text{bits} \times 8 = 38,528 \ \text{bits} (~4.8 KB)
Plain English: Even though the transaction is smaller than a tweet, by the time you’ve sent it to your 8 direct peers with all the network wrapping, you’ve moved about 4.8 KB — most of which is “packaging,” not the payment itself.
7. The Full-Network Propagation Footprint
Bitcoin transactions spread by gossip: each peer tells its peers, who tell their peers, and so on.
7.1. How many edges?
As of 2025:
- ~45,000 reachable nodes.
- Each with ~8 outbound connections.
- Total connections (edges) ≈ 45,000×82=180,000\frac{45,000 \times 8}{2} = 180,000
(Divide by 2 because each connection is shared by two nodes.)
7.2. Cost per edge
From Section 5:
- Payload: 1,776 bits
- Overhead: 3,040 bits
- Total: 4,816 bits
7.3. Multiply out
- Payload: 1,776×180,0001,776 \times 180,000 = 319,680,000 bits ≈ 38.0 MB
- Overhead: 3,040×180,0003,040 \times 180,000 = 547,200,000 bits ≈ 65.1 MB
- Total: 866,880,000 bits ≈ 103.3 MB
Result: To fully propagate one small 222-byte transaction to the entire public network costs on the order of 103 megabytes of total network traffic — about 65 MB of overhead and 38 MB of payload.
8. Ratios Don’t Change With Scale
Notice: The payload-to-overhead ratio is the same for one peer or the entire network: Ratio=0.584:1\text{Ratio} = 0.584 : 1
Scaling up just multiplies both numbers — the inefficiency is baked into the per-edge interaction.
9. Variants: Changing What You Count
If you stop counting at higher layers:
- Exclude preamble/IFG: Wire overhead per segment = 58 bytes. Total network footprint drops from ~103 MB to ~97.6 MB.
- Exclude Ethernet entirely (count up to IP): Overhead per segment = 40 bytes. Total footprint ~87.8 MB.
Ratios change slightly, but the big picture remains: overhead outweighs payload.
10. Why So Much Overhead?
The large overhead is not “waste” in the conventional sense — it’s a direct result of Bitcoin’s design goals:
- Redundancy: Every reachable node gets the transaction independently.
- Robustness: No central point of failure or coordination.
- Integrity: Headers, checksums, and framing ensure data isn’t corrupted.
- Negotiation safety: INV/GETDATA handshakes avoid sending data peers already have.
Without these, Bitcoin’s reliability and decentralization would be compromised, but with them comes the cost of massive duplication and wrapping.
11. The Block Relay Case (Compact Blocks)
While transaction relay has a high payload-to-overhead ratio, block relay is more efficient because:
- Most nodes already have most transactions in the block.
- Compact Blocks (BIP152) send short IDs for known transactions, and only full data for unknown ones.
- For a well-connected node, block relay might only send a few kilobytes of extra data for a 2 MB block.
This is a rare case where Bitcoin’s P2P network achieves relatively low overhead per payload bit.
12. Implications and Observations
- Efficiency trade-offs:
Bitcoin’s network is not bandwidth-efficient per transaction — but it is resilient, censorship-resistant, and globally distributed. - Scaling concerns:
Even with ~103 MB network-wide per small transaction, the total network bandwidth remains manageable because the total transaction volume is modest (~hundreds of thousands per day, not millions per second). - Potential optimizations:
- Transaction relay compression.
- Batching multiple INV/GETDATA exchanges in fewer TCP packets.
- UDP-based propagation experiments (with reliability layers) — though these have trade-offs.
- Alternative designs:
Payment channel networks (e.g., Lightning) move transactions off-chain, reducing the global gossip burden.
13. Conclusion
In raw numbers:
- Per-peer: 1,776 bits payload, 3,040 bits overhead — ratio 0.584:1.
- Your 8 peers: ~4.8 KB total traffic for one 222 B transaction.
- Full network: ~103 MB total traffic, ~65 MB of which is overhead.
In plain language:
A Bitcoin payment may be only a few hundred bytes, but broadcasting it to the world involves tens of thousands of tiny “Hey, I’ve got something!” messages and network headers. By the time the last node hears about it, the network has moved almost 500 times its size in extra wrapping and signaling.
This cost is the price of a system where no single party controls the message’s path, every node is equal, and the whole network can keep running even if parts of it go dark. The bandwidth bill is high, but so is the resilience.
If you’d like, I can also produce a diagram showing how the 222 bytes travel through INV, GETDATA, TX and the Ethernet/IP stack across peers, so this 3,000-word study has a clear visual. That would make the ratios and costs even easier to digest. Would you like me to add that?
Leave a Reply