<p>What you're describing is a push mechanism where each node automatically pushes whatever data it gets. This is not how the networking part of bitcoin works. The network protocol of bitcoin works as a pull mechanism. As a node, you request an inventory of blocks and transactions from other nodes. Usually, you request an inventory of what blocks and transactions other nodes have and then request specifically for the blocks and transactions you don't have. Other nodes you are connected to do the same thing.</p>

<p>As such, the upload bandwidth is only as much as other nodes request from you and given that you only need to receive each transaction or block once, in general, your upload bandwidth will be roughly equal to your download bandwidth.</p>

<p>That said, if you're one of the nodes that has a block first (like a miner), you're going to be uploading the block data to a lot more nodes than you download. If you're running a normal full node and not mining, you'll most likely be downloading more data than uploading.</p>

<p>That said, if your mempool gets flooded with transactions, the bitcoind behavior is to randomly discard transactions so that it's under a certain limit.</p>

CC BY-SA 3.0
2015-10-31T18:17:05.217Z
2015-10-31T18:17:05.217Z
Jimmy Song
<p>Since Bitcoin is largely a flooding-based P2P network it means that any message it receives on one of its connections also needs to be routed to all of its other connections. This means that by definition Bitcoin consumes far more upload bandwidth than it does download bandwidth since every downloaded message will also need to be uploaded to every other peer (by a factor of the number of connections - 1.)</p>

<p>We can assume that a node on the Bitcoin network can only upload messages as fast as it receives them so this means upload is also limited by download. Most ISPs also have far less upload bandwidth available to their customers than download bandwidth so conceivably this means that if a node is maxing its download bandwidth, it will lack the required resources to be able to broadcast those messages to its connected peers.</p>

<p>My question is: what happens when the messages start to overflow and the node can't keep up? Does Bitcoin maintain some kind of queue for the messages and what does it do when it can't keep up any more? Does it simply start to discard random messages? Also, given that you can't semi-reliably know beforehand what the available bandwidth is (without testing), how would you even set a limit for what size the buffer would need to be (the buffer will overflow eventually if the network can't keep up, right?)</p>

<p>(Sorry if these questions seem a bit technical but I am genuinely curious how Bitcoin handles this.)</p>

<client>
Does Bitcoin ensure all messages will be broadcast?
Matthew Roberts
# Does Bitcoin ensure all messages will be broadcast?

(Asked by: username_0 on 2015-10-31)

Since Bitcoin is largely a flooding-based P2P network it means that any message it receives on one of its connections also needs to be routed to all of its other connections. This means that by definition Bitcoin consumes far more upload bandwidth than it does download bandwidth since every downloaded message will also need to be uploaded to every other peer (by a factor of the number of connections - 1.)

We can assume that a node on the Bitcoin network can only upload messages as fast as it receives them so this means upload is also limited by download. Most ISPs also have far less upload bandwidth available to their customers than download bandwidth so conceivably this means that if a node is maxing its download bandwidth, it will lack the required resources to be able to broadcast those messages to its connected peers.

My question is: what happens when the messages start to overflow and the node can't keep up? Does Bitcoin maintain some kind of queue for the messages and what does it do when it can't keep up any more? Does it simply start to discard random messages? Also, given that you can't semi-reliably know beforehand what the available bandwidth is (without testing), how would you even set a limit for what size the buffer would need to be (the buffer will overflow eventually if the network can't keep up, right?)

(Sorry if these questions seem a bit technical but I am genuinely curious how Bitcoin handles this.)

**Tags:** client


---

## 1 answers

### Answer by username_1 on 2015-10-31. Score: 2

What you're describing is a push mechanism where each node automatically pushes whatever data it gets. This is not how the networking part of bitcoin works. The network protocol of bitcoin works as a pull mechanism. As a node, you request an inventory of blocks and transactions from other nodes. Usually, you request an inventory of what blocks and transactions other nodes have and then request specifically for the blocks and transactions you don't have. Other nodes you are connected to do the same thing.

As such, the upload bandwidth is only as much as other nodes request from you and given that you only need to receive each transaction or block once, in general, your upload bandwidth will be roughly equal to your download bandwidth.

That said, if you're one of the nodes that has a block first (like a miner), you're going to be uploading the block data to a lot more nodes than you download. If you're running a normal full node and not mining, you'll most likely be downloading more data than uploading.

That said, if your mempool gets flooded with transactions, the bitcoind behavior is to randomly discard transactions so that it's under a certain limit.


---

