Core and Classic share the same long-term goal: To develop Bitcoin from a lab experiment to a revolution of global money systems.
However, they are advocating different short-term approaches due to diverging perception of the current situation.
If we imagine ourselves looking back from a 2040 that achieved this goal, would we care whether we first implemented Segregated Witness and then increased the blocksize1, or vice versa?
Neither approach appears to promise catastrophic failure, although each side makes it out that the other is more likely to do so.
This is the point, where people usually would agree to disagree and split a project to follow their strategies on separate paths, but other than most free software that can be run in isolated instances of varying flavors, Bitcoin is unique in that running divergent versions could cause the network to split. A split would severely impact the value of the whole network and especially the potential value of the opposite sister projects.
The Bitcoin project is complex. It’s many-faceted and points of view are colored by the heterogeneous interests of the diverse invested parties. It is hard to grasp the project’s challenges in its entirety. While developers on both sides are challenged to take the broader picture into account for their strategy, the community tends to pick out easy-to-grasp bits and pieces to debate. – This behavior is commonly coined as bike-shedding.
That is not to say that the community doesn’t contribute to said issues, or that the issues were irrelevant. Rather, it causes those issues to receive magnitudes more attention and effort than would be efficient.
Which raises the question: why do we waste all the involved parties’ time, and make all our lives miserable by emotionally arguing over an issue that has the importance of the bike shed’s color at the design review for a moon rocket landing pad?
The developers are more invested in this than you. If not for any other reason, you can have a little faith in them because they won’t aim to disintegrate their own work and the fruits of labor of the past six years.
Keep being so engaged and contribute! Keep track of facts and assumptions. Read up on things that seem odd, and ask questions about what remains unclear. Try to be open-minded, and don’t only read content that already confirms your previous opinion. Yet, don’t waste people’s times by forcing them to repeat their points endlessly.
- My proofreader suggested that some people might be worried that a blocksize increase would never happen. When asked for a quote, Gregory Maxwell wrote on 2016-01-31 in #bitcoin (Freenode IRC): “The Core capacity roadmap […] speaks directly to [hardfork] size increases in the future. […] I’m not opposed to the idea.” To my knowledge most other Bitcoin Core contributors have indicated likewise. The Core capacity roadmap (drafted by Gregory Maxwell) states: “I think that right now capacity is high enough and the needed capacity is low enough that we don’t immediately need these proposals, but they will be critically important long term. I’m planning to help out and drive towards a more concrete direction out of these proposals in the following months. […] Finally–at some point the capacity increases from the above may not be enough. Delivery on relay improvements, segwit fraud proofs, dynamic block size controls, and other advances in technology will reduce the risk and therefore controversy around moderate block size increase proposals (such as 2/4/8 rescaled to respect segwit’s increase). Bitcoin will be able to move forward with these increases when improvements and understanding render their risks widely acceptable relative to the risks of not deploying them. In Bitcoin Core we should keep patches ready to implement them as the need and the will arises, to keep the basic software engineering from being the limiting factor.”Source