I don't think the full node count would scale as far as 12m in the growth example above, but payment channels for node services would at least reverse the decline even when it becomes necessary to support that loading.
I agree.
I've been thinking a lot about full node count lately, and I could also imagine a future where node count continues to decline but network decentralization actually improves.
Let's imagine a distant future where:
- Every major research university operates 1 full node on average (there's 108 in the US, 15 in Canada, and let's assume 150 elsewhere). That makes about 280 nodes.
- Every major bitcoin company in this "bitcoin future" and every mining pool operates a full node. Assume another 280 nodes.
- Various branches of governments in most countries run a few nodes. Assume 190 countries x 2 nodes = 380 nodes.
- And a bunch of wealthy bitcoiners operate their own nodes. Assume another 300 or so.
This gives a total of only ~1,240 nodes, but I think such a configuration would be more decentralized than the current state of the network.
I'm not suggesting that this will actually happen, just pointing out that the network doesn't necessarily need hundreds of thousands of nodes.
Fully agree, I was saying something along these lines in the earlier UTXO commit discussion where we might end up with only a small number of "archival" nodes that maintain a full history, while most nodes function as some form of pruned node. The reason this or your situation above works is you only need one honest node on the network to highlight and flag issues.
If some majority of full nodes (which is possible with a small node count) decide to collude and cheat, because of
the way the blockchain is structured any single honest node has the ability to present irrefutable proof of such collusion to the public. Again, this goes back to the fact that Bitcoin's decentralization is driven by the mining security process, not the node count (which can be influenced by Sybil attacks, mining cannot be influenced by Sybil attacks because it requires work). Even with 1 billion tps the mining situation looks similar to today. A large number of independent miners operating over stratum (<1kbps) connected to a small number of pools. If any pools collude, it only takes one honest node to highlight that and those pools would see their miners switch to honest pools. As long as the independent miner remains decentralized, Bitcoin is OK.
This is also why your O(nm) equation works. It is OK for the number of nodes m to decrease as needed bringing us back to O(n). The devs' arguments that you can't scale O(n^2) networks is correct, but this is showing they don't understand the network and Bitcoin's economics as well as they think.
This is actually a very astute point in bold and I am surprised given the other dumb technical errors you made upthread.
However what you fail to grasp is that Bitcoin's protocol can be forked by 51% of the hashrate.
Those who don't follow, lose their BTC value in that chain. They could spend in another fork, but the Coinbase, Circle, and Paypal masses will stay on the coin managed by the elite. And they can 50% attack your minority fork too claiming it is rogue.
Now with pegged side chains, you could move your BTC value out of the main and into your minority fork. But it still doesn't protect your minority fork against 50% attack.
And you don't have a concentration of smaller miners. The mining is becoming more and more concentrated in larger ASIC farms (who won't want to risk destroying their hardware investment on some fight against TPTB to support a minority chain). And even the P2P network is becoming concentrated around larger hubs that thus have influence over the propagation delays.