I feel like that's giving the Bitcoin Core developers a bit too much credit.
> When asked "can you scale this?" They said, "we'll do the best we can." That wasn't good enough for many, especially those who don't understand the architecture or the nature of what is going on inside of Bitcoin.
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. There is no right answer here of course, but many companies and VCs bet their future on a widely used, less decentralized version of Bitcoin (i.e. one where it's hard to run a Bitcoin server on a home internet connection, much like SMTP today).
> Many people call them "Bitcoin Core" as if they are some sort of company you can fire or a random set of developers with skills that you can just train others to acquire.
They called themselves Bitcoin Core, and even went so far as to create a separate website and have started branding the reference client as Bitcoin Core.
> It feels like while the Bitcoin Core development community is robust, the ecosystem of stakeholders and the understanding of how decisions are made and information is shared is still fragile and vulnerable.
The real issue is that Bitcoin has no "official" governance, so it's resulting in design-by-committee and stalemate on key decisions. The project needs a BDFL, but since it has none it will fail to keep pace with innovation in the space. Unlike most internet protocols, the consensus layer prevents anyone from effectively forking the project, without creating a whole separate blockchain (unless they can convince 100% of the community to follow them).
Luckily, we are starting to see more innovation and competition in the blockchain space, with Ethereum being by far the most interesting newcomer IMO (and run by a competent team with a clear governance structure).
> 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.
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.
> > 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.
Hi, 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.
Increasing 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.
> the consensus layer prevents anyone from effectively forking the project
This isn't true, as soon as 51% of clients are trying to push "new" blocks not recognized by the old client old clients cannot recognize them and the chain forks. This has happened several times in the past, but we have never seen anything like Classic where it was a version increment out of the Core tree that is set to break old clients.
There was technically a second hard fork a couple of months after the accidental one in order to carry out the change that caused the first one in a more controlled and planned manner. Sticking with the existing code was not an option for technical reasons: "This would be an issue even if the entire network was running version 0.7.2. It is theoretically possible for one 0.7.2 node to create a block that others are unable to validate, or for 0.7.2 nodes to create block re-orgs that peers cannot validate, because the contents of each node's blkindex.dat database is not identical, and the number of locks required depends on the exact arrangement of the blkindex.dat on disk (locks are acquired per-page)."
Also, there was technically also one way back in 2010 to fix an integer overflow bug that allowed large amounts of BTC to be created from thin air: https://bitcointalk.org/index.php?topic=823.0
Right. And that would be a disaster. Imagine if io.js forked node.js, but the fork was effectively unusable until 75% of projects started using it. And as soon as that threshold was reached, everyone still using and developing node.js was stuck with unmaintainable software and forced to migrate against their wish.
Personal opinions aside, what Bitcoin Classic is trying to do is follow the traditional open source project fork playbook, but it will not succeed with a consensus protocol - at best they are keeping attention focused on the issue. Blockchain development works best when there is competition _between_ blockchains, not within them.
Except that is the problem in Bitcoin. None of the money, none of the participation, none of the market are in alternate blockchains. They are in the bitcoin blockchain. That is fine, like the article says, when you have BDFL steering the project and keeping the original vision absolute, but that is not the case with bitcoin. Development is hijacked by those in a small insular group who refuse to adopt extremely popular reforms despite the userbase dramatically demanding the change.
This has happened before. It happened with ffmpeg when it was forked into libav. Up until the fork happened the leadership of ffmpeg did not yield - only after the competition was real did they change their behavior and then they made the smart decision of obsoleting libav by merging back in all changes made.
I'm not sure how you think Bitcoin Classic is failing. They already have a majority of hashing power pledged, and last I saw they had around a quarter of nodes running Classic or XT a week or so ago. If Classic wins, it simply demonstrates that the current project leaders of bitcoin core are not acting in the interests of a supermajority of the community as a whole according to their desires, and free software never works like that. If everyone wants change, someone will provide that change - it has happened so many times in the past they are near innumerable to list. I do not see how, if 75% of bitcoin users want 2MB blocks, it will not happen.
> When asked "can you scale this?" They said, "we'll do the best we can." That wasn't good enough for many, especially those who don't understand the architecture or the nature of what is going on inside of Bitcoin.
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. There is no right answer here of course, but many companies and VCs bet their future on a widely used, less decentralized version of Bitcoin (i.e. one where it's hard to run a Bitcoin server on a home internet connection, much like SMTP today).
> Many people call them "Bitcoin Core" as if they are some sort of company you can fire or a random set of developers with skills that you can just train others to acquire.
They called themselves Bitcoin Core, and even went so far as to create a separate website and have started branding the reference client as Bitcoin Core.
> It feels like while the Bitcoin Core development community is robust, the ecosystem of stakeholders and the understanding of how decisions are made and information is shared is still fragile and vulnerable.
The real issue is that Bitcoin has no "official" governance, so it's resulting in design-by-committee and stalemate on key decisions. The project needs a BDFL, but since it has none it will fail to keep pace with innovation in the space. Unlike most internet protocols, the consensus layer prevents anyone from effectively forking the project, without creating a whole separate blockchain (unless they can convince 100% of the community to follow them).
Luckily, we are starting to see more innovation and competition in the blockchain space, with Ethereum being by far the most interesting newcomer IMO (and run by a competent team with a clear governance structure).