Since Bitcoin is a peer-to-peer network of mostly identical clients, I would expect each node to upload about as much as it downloads. So I was surprised to see that my Bitcoin Core node has (since last startup) downloaded 1 GB of data but sent 47 GB.

I am running a full node with pruning disabled, so my node might participate in IBDs. However, I don't think that should make that much difference unless there are a lot of new nodes joining the network compared to the current number. I also see that my node seems to have around 70 incoming connections and 10 outgoing connections.

Can someone explain this discrepancy?

  • This is interesting. Never looked at that. Maybe it's there really are that many people running non listening nodes?
    – noone392
    Jun 21 '21 at 14:49

While nodes are set to be listening by default, the vast majority does not permit inbound connections either because listening has been disabled or their network setup doesn't make the necessary port accessible. There seem to be in the range of 8-10k listening nodes, while estimates for non-listening nodes range in 60-400k depending on the source.

Next to full nodes there are numerous thin clients that only consume but not propagate network gossip. As a listening node has a lot more connections to hear about new inventory quickly, it will be more likely to be the first to announce new transactions and blocks to its peers in turn. Additionally, a listening node will serve nodes undergoing initial synchronization and thin clients.

To give one data point:

$ bitcoin-cli getnettotals
  "totalbytesrecv":   15176470806,
  "totalbytessent": 4708177804982,
  "timemillis": 1624363225070,
  "uploadtarget": {
    "timeframe": 86400,
    "target":              262144000000,
    "target_reached": false,
    "serve_historical_blocks": true,
    "bytes_left_in_cycle": 218592671495,
    "time_left_in_cycle": 46909

In the last 11 hours, my node has uploaded 40.5 GiB. Altogether since it was last restarted, my node has received 14 GiB while uploading 4384 GiB, making its upload volume about 313× its download volume.


This is not surprising, and I believe it is actually normal behavior. It's an artifact of the flood method that Bitcoin uses to relay blocks and transactions.

Consider the following: one of your peers announces an unknown transaction of size 1000 bytes to your node, so your node requests and downloads. Now your node announces the same transaction to every other peer that it is connected to. For the sake of simplicity, let's assume that every other peer has not seen this transaction before, so there are 79 transaction announcements. Then each of those 79 nodes request that transaction, and your node sends the 1000 byte transaction to all 79 of them.

In this scenario, your node only downloaded at least 1000 bytes, but it had to upload at least 79000 bytes (this calculation does not include some additional network overhead or the announcements). In this way, you can have your upload be significantly larger than the download.

  • 2
    This is true, but for transaction relay I don't expect such a large discrepancy. I believe that the largest difference between in and out is due to the fact that OP is not in IBD, and their peers are. IBD is done almost exclusively through outbound connections. Jun 21 '21 at 16:33
  • 1
    But this obviously can't be true for every node, since every byte sent by one node is a byte received by another node. So why is his node special? Jun 21 '21 at 17:36
  • 1
    OP has incoming connections. The majority of nodes don't. Jun 21 '21 at 17:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.