Quote
I had described that upthread already, thanks for your out of context link though. The person I was responding to specifically asked what was wrong with just changing the size constant.
I disagree that classic solved the other issues. E.g. Adding an arbitrary limit to an N2 algorithm that can be simply made O(N) is not 'solving it', it's a kludge that bakes additional limitations into the system.
As far as the non-productive, I don't say it lightly-- I think it's an objective fact which is beyond reasonable dispute. Lets look at the evidence.
Here is the development team listed in the release notes for Classic 0.12.1: Gavin Andresen, Jeff Garzik, Pedro Pinheiro, Tom Zander, Jon Rumion.
Gavin Andresen :Zero commits to Classic 0.12.1.
Jeff Garzik: Only commit to classic ever is changing a URL from Bitcoin Core to classic, no commits in 0.12.1
Pedro Pinheiro: No commits to 0.12.1 (only code contribution I see in Classic was a hardfork status RPC command that was broken; later fixed by ftrader)
Jon Rumion: Appears to have no commits to classic ever (it may be that they're using a pseudonym in the commit history, or only doing testing or binary builds and no development in 0.12.1).
Tom Zander: In 0.12.1 tweaked some documentation, removed a correct warning that classic nodes were operating under rules inconsistent with what a majority hashpower was signaling.
Copied from core: several bug fixes by Wladimir J. van der Laan, Pieter Wuille.
These kinds of comparisons are inherently pretty approximate, but the results are clear.
Quite literally, even though Classic 0.12.1 takes almost nothing from Core 0.12.1, the developers of Bitcoin Core managed to develop more of classic 0.12.1 than most of the "classic" team combined. And Classic's major novel contribution in Classic 0.12.1 is a clear anti-feature that hides useful information from the user.
In the last month, across all branches, Classic has merged 1 pull request, and had zero new unmerged proposals. By comparison, Core has merged 87 in the same period and 33 propose. Classic has fallen behind protocol development: failing to merge BIP 68 and CSV friends so far, though Core kindly wrote it for them.
To each their own-- they're not bad people for not getting anything done there. But this idea in /r/btc that classic is a functional competing system, just isn't supported by the data. A lot of allegations are made in /r/btc that Core has bad qualities or is unenjoyable to work with, but the reality is that core is very effective and vigorous, and classic is .. not.
This is precisely the outcome you get when you don't have a large, experienced, vibrant team that cares deeply about Bitcoin and the technology supporting the system. And it is the perfectly predictable outcome when someone tries to stage a political coup to over-ride the technical and fundamental-value based reality; and kick out a large and successful community effort.
Lets stop pretending.
Stick a fork in it, indeed.
I disagree that classic solved the other issues. E.g. Adding an arbitrary limit to an N2 algorithm that can be simply made O(N) is not 'solving it', it's a kludge that bakes additional limitations into the system.
As far as the non-productive, I don't say it lightly-- I think it's an objective fact which is beyond reasonable dispute. Lets look at the evidence.
Here is the development team listed in the release notes for Classic 0.12.1: Gavin Andresen, Jeff Garzik, Pedro Pinheiro, Tom Zander, Jon Rumion.
Gavin Andresen :Zero commits to Classic 0.12.1.
Jeff Garzik: Only commit to classic ever is changing a URL from Bitcoin Core to classic, no commits in 0.12.1
Pedro Pinheiro: No commits to 0.12.1 (only code contribution I see in Classic was a hardfork status RPC command that was broken; later fixed by ftrader)
Jon Rumion: Appears to have no commits to classic ever (it may be that they're using a pseudonym in the commit history, or only doing testing or binary builds and no development in 0.12.1).
Tom Zander: In 0.12.1 tweaked some documentation, removed a correct warning that classic nodes were operating under rules inconsistent with what a majority hashpower was signaling.
Copied from core: several bug fixes by Wladimir J. van der Laan, Pieter Wuille.
These kinds of comparisons are inherently pretty approximate, but the results are clear.
Quite literally, even though Classic 0.12.1 takes almost nothing from Core 0.12.1, the developers of Bitcoin Core managed to develop more of classic 0.12.1 than most of the "classic" team combined. And Classic's major novel contribution in Classic 0.12.1 is a clear anti-feature that hides useful information from the user.
In the last month, across all branches, Classic has merged 1 pull request, and had zero new unmerged proposals. By comparison, Core has merged 87 in the same period and 33 propose. Classic has fallen behind protocol development: failing to merge BIP 68 and CSV friends so far, though Core kindly wrote it for them.
To each their own-- they're not bad people for not getting anything done there. But this idea in /r/btc that classic is a functional competing system, just isn't supported by the data. A lot of allegations are made in /r/btc that Core has bad qualities or is unenjoyable to work with, but the reality is that core is very effective and vigorous, and classic is .. not.
This is precisely the outcome you get when you don't have a large, experienced, vibrant team that cares deeply about Bitcoin and the technology supporting the system. And it is the perfectly predictable outcome when someone tries to stage a political coup to over-ride the technical and fundamental-value based reality; and kick out a large and successful community effort.
Lets stop pretending.
Stick a fork in it, indeed.
