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.
Thank you for helping me find a better value for the bandwidth multiplication factor. My initial guesstimate of 10 was really handwavy and I agree with your methodology. But I do like to use real-world data, so:
- Number of peers: 20 seems like a good minimum value for a healthy Bitcoin network - 8 for outbound connections, 8 for inbound connections, and a few for crawlers/leechers.
- tx size: the average tx size of the last 20160 blocks, beginning from block 363900, was 560 bytes.
- inv messages: My sniffer logged 13743 packets with 18374 inv messages. Including the various protocol overheads, the result was 98 bytes per inv.
- tx messages: Overhead (as determined from sniffer) was about 90 bytes per tx message - so an average of 650 bytes per tx.
- block messages: I'll assume overhead is negligible here, since blocks are bulk data. Thus block messages contribute an average of 560 bytes per tx.
The result is (20 * 98 + 2 * 650 + 2 * 560) / (560) =
7.8I shall update my original post/graphs with this factor.
I'm including overhead because ISPs do count overhead towards caps.
Interesting that nearly half of bandwidth attributable to a single tx is due to inv messages. Looks like there's room for optimisation there.