First, it would behoove you to run a full node on your desktop PC.
What you will surely find is that maxing out your CPU at 100% for hours on end isn't very fun and isn't necessarily conducive to getting other work done at the same time. This is again to say nothing of the bandwidth requirements, streaming videos or playing games for example may become out of the question depending on the quality of your network connection.
This is to say, at 1MB blocks, full nodes on the desktop are already becoming problematic for some users. The warning signs are as clear as day. What's more, to even get the performance of full nodes on desktop to this level has been a monumental feat and one largely spearheaded by the so called "small blockists" - th efforts of Dr. Adam Back, Gregory Maxwell and Dr. Pieter Wuille have been absolutely essential to making Bitcoin full nodes at least runnable on consumer hardware. For example, Greg Maxwell claims testing an original version 0.1 full node would take upwards of _20 weeks_ to sync fully.
Second, Gavin Andresen originally proposed 20MB blocks starting January 2016, and doubling every two years [1]:
> CPU and storage are cheap these days; one moderately fast CPU can easily keep up with 20 megabytes worth of transactions every ten minutes.
>
> Twenty megabytes downloaded plus twenty megabytes uploaded every ten minutes is about 170 gigabytes bandwidth usage per month – well within the 4 terabytes/month limit of even the least expensive ChunkHost plan.
>
> Disk space shouldn’t be an issue very soon– now that blockchain pruning has been implemented, you don’t have to dedicate 30+ gigabytes to store the entire blockchain.
>
> So it looks to me like the actual out-of-pocket cost of running a full node in a datacenter won’t change with a 20 megabyte maximum block size; it will be on the order of $5 or $10 per month.
>
> I chose 20MB as a reasonable block size to target because 170 gigabytes per month comfortably fits into the typical 250-300 gigabytes per month data cap– so you can run a full node from home on a “pretty good” broadband plan.
That we now see Gavin entertaining a much lesser fork - to 2MB instead of his previously claimed "safe" 20MB - speaks volumes about the severity of this issue.
Now, the Bitcoin core team has proposed a similar increase to 1.6MB effective through SegWit. Hence, the divisiveness of this issue isn't just about the numbers, but it is regretably devolved into a political power struggle with one side apparently wanting to demote the other side. "Big blockists" have long seen no harm in putting full nodes datacenters, backing their logic up with such gems as "Satoshi said this was fine 8 years ago therefore it's fine now". Meanwhile the "small blockists" - who are comprised of the very people who optimized Bitcoin full nodes to the point where we can now have this very debate - believe you need desktop PC users of full nodes to have a truly P2P network.
What you will surely find is that maxing out your CPU at 100% for hours on end isn't very fun and isn't necessarily conducive to getting other work done at the same time. This is again to say nothing of the bandwidth requirements, streaming videos or playing games for example may become out of the question depending on the quality of your network connection.
This is to say, at 1MB blocks, full nodes on the desktop are already becoming problematic for some users. The warning signs are as clear as day. What's more, to even get the performance of full nodes on desktop to this level has been a monumental feat and one largely spearheaded by the so called "small blockists" - th efforts of Dr. Adam Back, Gregory Maxwell and Dr. Pieter Wuille have been absolutely essential to making Bitcoin full nodes at least runnable on consumer hardware. For example, Greg Maxwell claims testing an original version 0.1 full node would take upwards of _20 weeks_ to sync fully.
Second, Gavin Andresen originally proposed 20MB blocks starting January 2016, and doubling every two years [1]:
> CPU and storage are cheap these days; one moderately fast CPU can easily keep up with 20 megabytes worth of transactions every ten minutes. > > Twenty megabytes downloaded plus twenty megabytes uploaded every ten minutes is about 170 gigabytes bandwidth usage per month – well within the 4 terabytes/month limit of even the least expensive ChunkHost plan. > > Disk space shouldn’t be an issue very soon– now that blockchain pruning has been implemented, you don’t have to dedicate 30+ gigabytes to store the entire blockchain. > > So it looks to me like the actual out-of-pocket cost of running a full node in a datacenter won’t change with a 20 megabyte maximum block size; it will be on the order of $5 or $10 per month. > > I chose 20MB as a reasonable block size to target because 170 gigabytes per month comfortably fits into the typical 250-300 gigabytes per month data cap– so you can run a full node from home on a “pretty good” broadband plan.
That we now see Gavin entertaining a much lesser fork - to 2MB instead of his previously claimed "safe" 20MB - speaks volumes about the severity of this issue.
Now, the Bitcoin core team has proposed a similar increase to 1.6MB effective through SegWit. Hence, the divisiveness of this issue isn't just about the numbers, but it is regretably devolved into a political power struggle with one side apparently wanting to demote the other side. "Big blockists" have long seen no harm in putting full nodes datacenters, backing their logic up with such gems as "Satoshi said this was fine 8 years ago therefore it's fine now". Meanwhile the "small blockists" - who are comprised of the very people who optimized Bitcoin full nodes to the point where we can now have this very debate - believe you need desktop PC users of full nodes to have a truly P2P network.
[1]: http://gavinandresen.ninja/does-more-transactions-necessaril...