4 ms·

> Hasn't signature verification speed been improved significantly since 2014 Pieter Wuille's work in libsecp256k1 promises to improve verification speeds on 64

> Hasn't signature verification speed been improved significantly since 2014 Pieter Wuille's work in libsecp256k1 promises to improve verification speeds on 64-bit CPUs by as much as 700%, and it's set to be deployed on the network as early as February. This will hopefully be enough of a boost to reasonably process 2MB blocks on a desktop PC. This desktop processing goes very underappreciated by most onlookers. Imagine if you couldn't run a BitTorrent client on a home PC? To put it mildly, I would have an issue calling BitTorrent "peer-to-peer" in that case. For example, it would be absurd to out-and-out need a remote compute cluster to seed or leech torrents. > And what year would 32MB blocks be needed in and what processors would be available in that year? The "big blockist" proponents actually contended Bitcoin dies without 20MB blocks starting this month, January 2016, and doubling every two years. Going by their original propositions, we would have >32MB block capacity by around this time in 2018. How much do you think desktop PC performance will have improved by then? And this is to say nothing of the bandwidth costs [1]. [1]: http://statoshi.info/dashboard/db/bandwidth-usage http://statoshi.info/dashboard/db/bandwidth-usage

wmf 11y ago
Something seems off here. If a 7x performance increase is only enough for 2MB blocks, does that mean a PC today can only handle <300KB blocks? How have we not heard about this? How are people running full nodes on RPis? And I don't remember seeing anyone call for 20MB blocks. The debate looks more like 1MB vs. 2MB vs. 8MB etc.
- Anonobread 11y ago
  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. [1]: http://gavinandresen.ninja/does-more-transactions-necessarily-mean-more-centralized http://gavinandresen.ninja/does-more-transactions-necessaril...

wmf 11y ago

Something seems off here. If a 7x performance increase is only enough for 2MB blocks, does that mean a PC today can only handle <300KB blocks? How have we not heard about this? How are people running full nodes on RPis? And I don't remember seeing anyone call for 20MB blocks. The debate looks more like 1MB vs. 2MB vs. 8MB etc.

Anonobread 11y ago
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. [1]: http://gavinandresen.ninja/does-more-transactions-necessarily-mean-more-centralized http://gavinandresen.ninja/does-more-transactions-necessaril...