2MB blocks will likely also reduce node count, but it seems like while there is probably an optimum node number relative to network size and most would agree more nodes seems desirable the actual number remains an unproven assumption, to put that in perspective a rational argument can be made for as few as 50 nodes to keep bitcoin decentralized.
The number of nodes is unlikely to be dictated by the size of the blockchain. Full nodes are more likely to be dictated by the number of miners and network participants who are dependant on the security, information and utility a full node can provide.
@adamstgbit
Once deployed, only SegWits enabled nodes will be fully capable nodes, all other nodes will be some type of diminished node. The result will be fewer full nodes.
It's been argued that the increased space demand for nodes will eventually lead to centralisation, Gmaxwell tells us: "Segwit is not about saving space for plain full nodes"
If we are to believe the small block proponents argument that increasing the block size will result in increasing the blockchain size that result in a centralized data center, then Segwit could have same effect given it's not about space saving.
Scaling is not about optimising block space, scaling Bitcoin is about using the most scarce resource optimally. In the case with Bitcoin and implementing SegWits and 2MB blocks, it's using bandwidth effectively provides the biggest scaling returns. SegWits as pointed out is less efficient with bandwidth than 2MB blocks would be.
And when put in context of Gavin's Headers first, BitPay's dynamic / Bitcoins Unlimited consensus block sizes and Xthin, these are far more efficient proposals available for implementation now, and combined they will allow Bitcoin to scale while optimising the scarce resources of bandwidth more efficiently than SegWit.
