3 ms·

Block size isn't a free parameter. The team behind btcd, a Bitcoin full node written in Go, made the following observations about block size [1]: 1. a 32 MB bl

Block size isn't a free parameter. The team behind btcd, a Bitcoin full node written in Go, made the following observations about block size [1]: 1. a 32 MB block, when filled with simple P2PKH transactions, can hold approximately 167,000 transactions, which, assuming a block is mined every 10 minutes, translates to approximately 270 tps 2. a single machine acting as a full node takes approximately 10 minutes to verify and process a 32 MB block, meaning that a 32 MB block size is near the maximum one could expect to handle with 1 machine acting as a full node 3. a CPU profile of the time spent processing a 32 MB block by a full node is dominated by ECDSA signature verification, meaning that with the current infrastructure and computer hardware, scaling above 300 tps would require a clustered full node where ECDSA signature checking is load balanced across multiple machines. For context, a meager 300 tps is less than 10% of what VISA does - hence this solves no long standing problems in Bitcoin, yet it condemns all the nodes to run in compute clusters in datacenters. Naturally, "small blockists" as we're called, point out that this isn't how Bitcoin works today at all. Forcing nodes into compute clusters in remote datacenters is a major, sweeping departure from nodes running on home networks with consequences both forseeable and unforseeable. [1]: https://blog.conformal.com/btcsim-simulating-the-rise-of-bitcoin/ https://blog.conformal.com/btcsim-simulating-the-rise-of-bit...

wmf 11y ago
Hasn't signature verification speed been improved significantly since 2014? And what year would 32MB blocks be needed in and what processors would be available in that year?
- Anonobread 11y ago
  > 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...
mikeyouse 11y ago
Small quibble but that number is comparable to Visa's peak transactions per second figure, which is somewhere North of 56,000tps. Making the hypothetical 32x-better Bitcoin network 0.2% as capable as the current Visa network.

wmf 11y ago

Hasn't signature verification speed been improved significantly since 2014? And what year would 32MB blocks be needed in and what processors would be available in that year?

Anonobread 11y ago
> 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...

mikeyouse 11y ago

Small quibble but that number is comparable to Visa's peak transactions per second figure, which is somewhere North of 56,000tps. Making the hypothetical 32x-better Bitcoin network 0.2% as capable as the current Visa network.