<p>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.</p>
<p>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.</p>
<p>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.</p>

CC BY-SA 4.0
2021-06-21T16:33:01.757Z
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.
Pieter Wuille
CC BY-SA 4.0
2021-06-21T17:36:02.217Z
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?
David Schwartz
CC BY-SA 4.0
2021-06-21T17:49:36.860Z
OP has incoming connections. The majority of nodes don't.
Pieter Wuille
CC BY-SA 4.0
2021-06-21T16:16:04.527Z
2021-06-21T16:22:16.420Z
2021-06-21T16:22:16.420Z
Ava Chow
<p>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 <a href="https://www.dsn.kastel.kit.edu/bitcoin/#nodes" rel="nofollow noreferrer">8-10k listening nodes</a>, while estimates for non-listening nodes range in <a href="https://luke.dashjr.org/programs/bitcoin/files/charts/historical.html" rel="nofollow noreferrer">60</a>-<a href="https://crawly.org.es/" rel="nofollow noreferrer">400</a>k depending on the source.</p>
<p>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.</p>
<p>To give one data point:</p>
<pre><code>$ bitcoin-cli getnettotals
{
  &quot;totalbytesrecv&quot;:   15176470806,
  &quot;totalbytessent&quot;: 4708177804982,
  &quot;timemillis&quot;: 1624363225070,
  &quot;uploadtarget&quot;: {
    &quot;timeframe&quot;: 86400,
    &quot;target&quot;:              262144000000,
    &quot;target_reached&quot;: false,
    &quot;serve_historical_blocks&quot;: true,
    &quot;bytes_left_in_cycle&quot;: 218592671495,
    &quot;time_left_in_cycle&quot;: 46909
  }
}
</code></pre>
<p>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.</p>

CC BY-SA 4.0
2021-06-21T18:29:07.373Z
2021-06-22T12:46:00.907Z
2021-06-22T12:46:00.907Z
Murch
<p>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.</p>
<p>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.</p>
<p>Can someone explain this discrepancy?</p>

CC BY-SA 4.0
2021-06-21T14:49:32.247Z
This is interesting. Never looked at that. Maybe it's there really are that many people running non listening nodes?
noone392
<bitcoin-core><full-node><p2p><bandwidth>
Bitcoin Core uploads much more than it downloads
Vojtěch Strnad
# Bitcoin Core uploads much more than it downloads

(Asked by: username_0 on 2021-06-21)

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?

**Tags:** bitcoin-core, full-node, p2p, bandwidth

> **Comments:**
> **username_1**: This is interesting. Never looked at that. Maybe it's there really are that many people running non listening nodes?  

---

## 2 answers

### Answer by username_5 on 2021-06-21. Score: 6 | Accepted answer

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](https://www.dsn.kastel.kit.edu/bitcoin/#nodes), while estimates for non-listening nodes range in [60](https://luke.dashjr.org/programs/bitcoin/files/charts/historical.html)-[400](https://crawly.org.es/)k 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.


---

### Answer by username_2 on 2021-06-21. Score: 1

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.

> **Comments:**
> **username_3**: 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.  
> **username_4**: 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?  
> **username_3**: OP has incoming connections. The majority of nodes don't.  

---

