4 ms·
> The larger issue is that some of the core developers don't want to scale Bitcoin at all. They would rather have a more decentralized, less widely used Bitcoin
by Rauchg 11y ago
> The larger issue is that some of the core developers don't want to scale Bitcoin at all. They would rather have a more decentralized, less widely used Bitcoin.
This is not the case. See: https://bitcoin.org/en/bitcoin-core/capacity-increases-faq https://bitcoin.org/en/bitcoin-core/capacity-increases-faq
What some of the core developers don't want to do is scale by increasing the block size and thusly increase the costs of being part of the decentralized network.
As an analogy, consider the EMFILE error in Unix. The kernel has a pre-set constant of how many file descriptors a user can open simultaneously.
Your computer might have it set to 256 and you might never have a problem because you use it for single-user workloads. When I deploy services to the cloud, however, it's annoying that sometimes the constant is too low: the system can handle a lot more TCP connections sometimes and the constant is inappropriate.
Now let's say you have a peer-to-peer network whose participants' computing capabilities (= EMFILE limit) are unknown. Let's say this network becomes super popular, and a lot of the nodes are close to hitting their file descriptor limit.
If you raise the constant from 256 to Infinity for everyone in the network, some nodes might be able to handle the load (for example powerful cloud computers), but some desktop computers will just struggle. No matter how high you set the constant, you're not introducing more capacity. You're throwing nodes out.
Luckily, there seem to be ways to scale the network without relaying (and persisting) every single transaction to every node.
- toomim 11y ago> > The larger issue is that some of the core developers don't want to scale Bitcoin at all. They would rather have a more decentralized, less widely used Bitcoin. > This is not the case. See: https://bitcoin.org/en/bitcoin-core/capacity-increases-faq https://bitcoin.org/en/bitcoin-core/capacity-increases-faq No, parent's statement is correct. Luke Jr, for instance, thinks that 1MB is already too big: https://www.reddit.com/r/btc/comments/404b01/ulukejr_1_mb_is_too_large_today/ https://www.reddit.com/r/btc/comments/404b01/ulukejr_1_mb_is... You're pointing at a document jointly written by a number of Core Developers, but some developers don't want Bitcoin to scale at all.
- Rauchg 11y agoIncreasing the block size is not the only way to make the system scale. Imagine that you have 300GB available to store logs for requests to your webserver. Let's say you're at 250GB and you can make calculations that, based on your website's growth and traffic projections, you'll hit your 300GB limit by the end of the year. One way to scale is to buy new hard drives. Another way to scale is to keep only the most recent 300GB. Another way to scale is to ask yourself: do you want every single entry in the log, with user agent, IP, headers and TLS handshake parameters? Perhaps you care only about malicious actors. Perhaps you care about some critical business events. In that case, an alternative would be to aggregate and collapse log entries. In the context of a system that is designed for decentralization, those scaling strategies seem to be a better fit.
- nullc 11y agoHi, Which developers don't want Bitcoin to scale at all. I think that it's critical that when the founder and lead developer of Bitcoin "Classic" makes allegations like this that they back them up concretely.