Is all it took really just to have a developer fly out to China and talk to a hanful of people? Seems like there's a lot more politics going on behind the scenes.
In any case, fixing the blocksize limit will be good, but I think the real value in Classic is breaking the perceived monopoly Core has and moving to a healthier political setup. Many people were absolutely unwilling to even talk about XT (or as you mention, allow others to talk about XT) because "OMG it's not Core!". That argument will be a lot less viable if everyone's moved to Classic.
This narrative that Gavin and I were unwilling to compromise is deeply unfortunate. BIP 101 originally started with a 20mb limit+growth. That was based on some calculations Gavin did. At that point the Chinese miners started saying they couldn't accept 20 because of the firewall, but eight would be OK. They put announcements of their support for eight megabyte blocks in their coinbases, etc.
Why eight? Because it's a Chinese homonym for "prosper" or "wealth":
https://en.wikipedia.org/wiki/Numbers_in_Chinese_culture#Eig...
It crops up in the Chinese Bitcoin community all the time. So this choice obviously wasn't based on any kind of scientific analysis. Having Bitcoin protocol constants be decided by rhymes would obviously have been an embarrassment, but nonetheless, we compromised and did it.
After Core rejected the now-modified BIP 101, Gavin and I released XT together. At this point the miners changed their tune. They announced they would never run anything except Core, period, end of story. This "requirement" had not been specified before. From both speaking to them personally (I have had various phone calls with miners around the world, including miners in China) and their public statments, they made it clear that their loyalty to Core was absolute and no matter what changes we made to XT, they would never run it. Thus compromising further was pointless.
Why is Classic different? It wasn't, just one or two days ago. After I released my article, I was CCd on a private thread where KnC Miner published an "open letter" and suggested switching to Classic. The other miners shot him down immediately saying they wanted the change to come from Core. Then the price started sliding, and they started reversing their positions. Suddenly, Classic was acceptable whereas just hours before it had not been.
And the trigger for that was your medium article the other day. :-)
And since, block size/scalability was the key point in your post. Would you be willing to re-join Bitcoin, since what you wanted would be achieved? Even if its Classic and not via XT.
Perhaps, my question may come across as naive. But looking at it from outside (reading /Bitcoin & /btc & etc), it would definitely clear a lot of air, and be good for Bitcoin.
At this point the community seems to be mostly decided that they want to break the Core dev's monopoly and Classic provides a lowest common denominator way to do this. I just hope the Classic devs make better choices.
This presumes the blocksize limit is being fixed, which is an incorrect assumption. Originally, the proponents of Classic wanted to boost block size limits to 20MB effective January 2016 [1], and used bombastic and divisive language, inventing their own crisis even, to get people to take them seriously.
Interestingly, those same people are now contending for just 2MB, which is only 0.4MB higher than that proposed by Core.
Performance test data shows 32MB is the absolute maximum block size you can handle on a modern desktop PC today [2]. And by this I mean you could validate no more than one block per 10 minutes, hence realistically you actually couldn't run a full node on a desktop at 32MB. You'd need a clustered full node just to keep up, which is unprecedented in Bitcoin.
To make matters worse, 32MB blocks gets Bitcoin to 300 tps which is less than 1% of VISA's current capacity.
[1]: http://gavinandresen.ninja/does-more-transactions-necessaril...
[2]: https://blog.conformal.com/btcsim-simulating-the-rise-of-bit...
Hearn mentions the backstory behind this in a comment here [0], posted a little while after you posted your comment. After reading his comment, does the shift from 20MB max blocks to something smaller become less "interesting" and more understandable? If not, why not?
Edit: Additionally, do you have anything to say about this comment? [1]
If we wait for a perfect fix to all problems, current and projected, we'll be waiting forever.
No, it's maximum size you can handle using a single-threaded poorly-optimized cpu software.
>Additionally, a profile of the CPU usage of this node, using golang’s great profile capabilities, shows that the CPU usage is dominated by the ECDSA signature verifications
OpenCL on gpu can easily process 50 MILLION bitcoin addresses per second (ecdsa + sha). [0] Note that OpenCL is available even on smartphones. For a very rough estimate, Adreno 530 on Snapdragon 820 has 500GFlops, 10% of 780 ti which can do 50M/s, so it should do about 5M/s. So a $400 smartphone should be more than enough to process 32MB blocks - provided the gpu is used.
XT was much more aggressive. Not only would it have initially increased the blocksize to 8MB, but then it fixed a schedule of doubling the blocksize every 2 years[0].
[0]: https://en.wikipedia.org/wiki/Bitcoin_XT#Determining_the_new...
Most people really gave them way too much credit and took them at their word, but it's been dug into the ground at this point that they are going to try to lie, censor, and outright sabotage any attempt to adapt bitcoin since they think creating problems gives them an opportunity to solve them.
The bitcoin implementation by the "real" bitcoin foundation (ie, asciilifeform's group) at least can claim that it is an implementation of the actual bitcoin protocol:
For some period of time there will be two versions of bitcoin running on the machines that mine, and it will take some time for them to switch over-- but since Classic is doing the switch with major support now, the transition should be smooth.
Bitcoin the protocol can and is run by a wide variety of software... the blockchain is a consensus agreement of that software. Basically its an agreement on protocol based on the rules in the software.
For most of its history, that software has been based on Bitcoin Core. That may change in the future to Bitcoin Classic, or both may be running at the same time with different variances, but supporting effectively the same protocol.
Nobody wants %50 of the network to be running software incompatible with the other %50.
As far as I'm concerned, neither side 'has a monopoly' on the protocol because they haven't documented the protocol with a proper specification.
Forking Bitcoin today to 'solve' contingent future problems seems like the height of folly.
I have a small nitpick to offer. Any hard-forking change is one for a new network and a new chain, by the very definition of hard-fork. The original Bitcoin blockchain and network will still exist, no matter how many times some of its users employ a hard-fork. A hard-fork cannot "turn off" Bitcoin for everyone else. This is no different than the way that an altcoin, like Litecoin, cannot "turn off" Bitcoin merely by the deployment and launch of Litecoin.
Since their proposal is a backwards-incompatible change (hard-fork), it should be obvious that it does not increase the capacity of the current system, but rather a new system. I find myself wondering how anyone can think it is increasing the capacity of the previous network, given the definition of an (intentional!) hard-fork?
Maybe if we all just wish hard enough, IPv4 will spontaneously transform into IPv6..... Bitcoin will continue to function even in the presence of yet-another hard-fork.
Anyone is welcome to do as they please, including whatever hard-forks they might want to participate in, just as anyone is welcome to use Bitcoin or how they are welcome to abandon Bitcoin if they find that they don't like its offering. However, anyone who wants to participate in a hard-fork should do so in a safe and responsible way, such as by using a new name for the new system, using a new address identifier to avoid cross-chain contamination accidents, etc.
What is Bitcoin Core's role in all of this? https://bitcoin.org/en/bitcoin-core/2016-01-07-statement
Soft-forks and hard-forks? https://petertodd.org/2016/soft-forks-are-safer-than-hard-fo...
bip99 has some more details: https://github.com/bitcoin/bips/blob/master/bip-0099.mediawi...
Bitcoin Core published a capacity increases roadmap: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-...
... and a FAQ about their capacity increases roadmap: https://bitcoincore.org/en/2015/12/23/capacity-increases-faq...
> and [theymos] has strongly censored and perverted all discussion of changes
That's not really true, just search "site:reddit.com/r/bitcoin" for XT or classic or whatever. His lynch mob is waving the banner of censorship but meanwhile actual content shows up on the subreddit. Theymos even acknowledges this, but for some reason refuses to use moderation to eliminate the false allegations of censorship in his subreddit.
Every "version" is pure w.r.t its current rules. Hard-forking is something that impacts a new chain. The old chain still exists even after a hard-fork.
_Anyone_ can run old Bitcoin versions and participate on the old chains using the pre-hard-forked-changed rules.
There is no way to "turn off" the previous chain, at least not in the protocol.
The old version could become unmaintained, have no remaining miners, no remaining validating nodes, etc. That's true. But for this to be the case, there would have to be universal disinterest in maintaining the previous tech, or mining with the previous rules, operating and running fully-validating nodes, etc. Universal disinterest cannot be measured.
I cannot offer you any justification I agree with for the previous hard-forks. At the time that those hard-forks were deployed, various justifications were given, and as of 2016 I am not sure that I can agree with those reasons now. Perhaps at the time I would have found merit in the idea that the Bitcoin ecosystem was small enough to tolerate a hard-fork or something. Another possible rationalization is that, at the time, the Bitcoin software was horribly inefficient in hundreds of ways, this is why verification took >10 hours of a blockchain that was less than 30% the size of the current 2016 blockchain.... and 32MB was probably a security hole that everyone at the time was able to universally agree must be plugged. This sort of reasoning resonates with me even as of 2016; if there was a hole that bad in modern Bitcoin, heck yeah we would all have to do a hard-fork, it's unfortunate but security is important and I like avoiding holes.
FWIW, I don't care about purity.
Here is some text on validation costs:
http://diyhpl.us/wiki/transcripts/scalingbitcoin/validation-...
http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/v...
> other releases that required a hard fork as well the world didn't end
Bitcoin isn't going to destroy the world, nsh is. Anyone saying otherwise is just trolling you.
If I had Electum which uses the Bitcoin Core could I send Bitcoin to someone using Bitcoin Classic or Bitcoin XT?
If not then this causes a lot of problems and confusion.
Bitcoin Classic was created by Jonathan Toomim, an American miner and developer who went to China to talk directly with Chinese miners and to test the effect of bigger blocks on mining operations behind the Great Firewall. Gavin Andresen, Bitcoin Core's former lead developer, and Jeff Garzik, another prominent Core developer, as well as many others, are collaborating with Toomim on further changes that Bitcoin Classic may implement later.
The big difference between Bitcoin Classic and Mike Hearn's failed Bitcoin XT is the concerted effort by the people behind Classic to garner the explicit support of miners (and other important members of the Bitcoin ecosystem) for a blocksize increase. At my last check yesterday, mining-pool operators representing 72% of global hashing power had explicitly expressed their support for Bitcoin Classic's blocksize increase, as had the operators of many popular exchanges, web wallets, and payment providers. (There is a growing compendium of prominent supporters on Bitcoin Classic's website; the complete list is on the project's Github page [1].)
That means that Bitcoin Classic is very likely to break Core's monopoly on the protocol soon. The blocksize increase, and the fork of the blockchain that it will create, is tentatively scheduled to take place after March 1. Get ready.
(By the way, the best sources for information and discussion about the Bitcoin world are now the /r/btc sub-Reddit and the discussion forums at bitcoin.com and bitco.in; the community's former hubs, /r/Bitcoin and bitcointalk.org, are both controlled by the same operator/moderator, and he has strongly censored and perverted all discussion of changes to the protocol that are not supported by Core's intransigent cabal of developers.)
0. https://www.bitcoinclassic.com
1. https://github.com/bitcoinclassic/website/issues/3