Quote from: someone42 on July 04, 2015, 09:28:39 AM

and that block data needs to be transferred a total of 10 times. This is reasonable, as Bitcoin is a P2P gossip network and transactions/blocks may need to be retransmitted to peers.

This is not true. On average every node has to receive each transaction and block only once. This means that on average each node has to send each transaction once. Some (fast) nodes may end up sending transactions lots of times. The closer your node is to miners, the more likely it is to have to send blocks multiple times.

If you are connected to 20 peers and a new transaction is broadcast. On average 10 of those peers will receive the transaction once. Each of those peers will send you an inv message with the hash of the transaction. You will then ask for one of them to send you the transaction. Once you add the transaction into your memory pool, you will inform the other 10 peers about it and one of them will (on average) ask you to send it to them.

That means that you need to send or receive a hash digest to every peer. Either they inform you that they got the transaction or you inform them that you have it. Due to propagation delays, sometimes you will both send transaction digests at each other.

This means that a transaction costs

peers * digest_size + 2 * transaction size

The same logic applies to blocks, but less often.

With 20 peers and a 250 byte transaction, that costs

20 * 32 + 2 * 250 = 1140

You also receive the transaction a second time when you receive the block and you have to also forward the block to one peer.

That is another 500 bytes.

This means that a 250 byte transaction costs 1640 bytes or 6.56 times its base size.

If blocks are 1MB each, then the node needs a total bandwidth of 6.56MB to keep up.

If the node falls behind, then that reduces the chances that it needs to send transactions and blocks to its peers. That reduces the bandwidth slightly. Blocks and transactions may not have to be forwarded.