HomeRedditMastering Blockchain Scaling: The Inconvenient Truth Mastering Blockchain Scaling: The Inconvenient Truth admin | May 16, 2019 | Mastering Blockchain Scaling: The Inconvenient Truth View Reddit by Ixian_IO – View Source Tweet Related Posts South African Platform Using Blockchain to Combat Unemployment December 21, 2018 | More Trade Today! January 21, 2019 | More CTG video English version October 15, 2018 | More Jamie Dimon Comments on Bitcoin Yet Again, Says He Doesn’t Give a Sh*t About It November 10, 2018 | More One Response jtoomim May 16, 2019 **Your numbers are off by a factor of 1,000.** At 1 billion users doing 10 tx/day each, we have about 116k tx/sec. Each transaction on Bitcoin averages about 400-500 bytes, not 250. At 500 bytes, that’s 463 Mbps average of download bandwidth. So far so good; this is not far off from what you calculated. The problem is that if your full node is connected to 2,000 peers, that does not mean that you’re uploading those complete blocks 2,000 times. If those 2,000 peers are SPV wallets (which is the only way that the 2,000 number makes sense), then you’re only uploading these wallets’ own transactions to them, plus some headers and compact merkle proofs to show that their transactions were actually included in blocks. These proofs take about 2 kB per transaction. At 10 tx/day, these 2,000 SPV clients will require an average of 2000 clients * 10 tx/day/client * 2000 bytes/tx * 1 day/86400 sec = 463 bytes/sec not 460 Gbps as your calculator suggests. SPV peers are insignificant for the total bandwidth requirements of a node. Even if those 2,000 peers are full nodes, not SPV wallets, you don’t get anywhere near 460 Gbps. If you have 2,000 peers, and each of those peers also has 2,000 peers, then you will need to announce to each peer when you have a new block (or transaction) in your inventory. Each of those peers will pick one peer to download that block or transaction from, and will only download that transaction once unless there is an error with the download. So in a full node scenario, the download bandwidth is on average equal to the upload bandwidth. (The exception to this is uploading historical blocks to peers who are syncing for the first time. However, that issue will only increase bandwidth requirements by about 2x, not 2000x, and can also be solved with UTXO commitments.) On the other hand, there is significant per-peer bandwidth overhead due to announcing transactions as being in your node’s inventory. This takes about 40 bytes per transaction per peer with the current code. If you have full node 2,000 peers, sending out (and receiving!) these inventory messages will take about 9.26 Gbps of upload and download bandwidth. But you can solve this problem by … not having 2,000 full node peers. Really, there’s no need for that. Eight peers is plenty. At 8 peers, you only need about 296 Mbps of bandwidth for inventory announcements. Adding in the bandwidth needed for the transactions themselves, and you get around **760 Mbps of bandwidth to stay synced at 116,000 tx/sec**. That’s a bit out of reach for most hobbyists today, but it’s within most businesses’ reach. For hobbyists, it should be reasonable in five years, and it will probably be 15 to 30 years before we have 116,000 tx/sec of actual demand.