Chapter 7 of the book The Blocksize War is published below. The full book is available on Amazon. As a reminder, 50% of any profits from physical book sales will be donated to Médecins Sans Frontières, a charity that provides medical assistance to people affected by conflict, epidemics, disasters, or exclusion from healthcare.
The Blocksize War – Chapter 7 – Bitcoin Classic
Towards the end of 2015, the war was intensifying considerably. There were even waves of distributed denial of service (DDoS) attacks on Bitcoin XT nodes. On December 28, 2015 Reddit user /u/tl212 commented:
I was DDos’d. It was a massive DDoS that took down my entire (rural) ISP. Everyone in five towns lost their internet server for several hours because of these criminals. It definitely discouraged me from hosting nodes.[1]
This action did seem pretty aggressive and was unjustifiable. It is remarkable that there were reports of attacks so strong that they took down an entire ISP. The attacks did appear to have a material detrimental impact on the Bitcoin XT network and, therefore, to some extent, one could argue they were working. I am not aware of any small blockers with a known identity that supported such unethical behaviour, although some anonymous small blockers appeared to defend the action on BitcoinTalk, referring to it as a “counter attack”. The one thing that the attack did bring to light, however, was the importance of a large, distributed and robust P2P network, something Bitcoin XT had not developed at this point. It was never known who was behind these attacks, although rumours did circulate several months later of a Botnet operator who was paid anonymously in Bitcoin to launch them. The behaviour of the attackers was regarded as unethical even by small blockers, many of whom regarded it as potentially counter-productive, driving people away from their side of the argument. In my view, this is a rare example of a tactical blunder from the small block camp, assuming of course this was a small blocker and not some kind of false flag operation. This war was about persuading people to join one’s chosen side, and such aggressive action was not productive. This form of attack did not prominently feature again in the blocksize war, as far as I am aware.
On January 3, 2016, Brian Armstrong, the CEO of Coinbase (one of the largest spot exchanges in the space and the company with the most impressive VC backing), published a blog in support of larger blocks. Brian also supported Gavin and had controversial views on how to upgrade Bitcoin.
Luckily, bitcoin has a built in upgrade mechanism with an elegant design. If a majority of bitcoin miners “vote” for a particular upgrade then by definition this is the new version of bitcoin. The number of votes each miner gets is proportional to the amount of computational power they are adding to the network (so votes can’t be faked).[2]
The view that whatever chain had the most hashpower behind it was defined as Bitcoin did not seem to make much sense to the small blockers. To them, Bitcoin nodes did enforce certain rules; a block had to comply with these rules or it would be ignored. To the small blockers, this was a critical part of how Bitcoin worked. If miners just tried to change the rules like that, it would cause a split in the chain and result in a new coin. The coin following the original rules would continue to be Bitcoin.
Small blockers tended to see full validating nodes as important in regards to enforcing protocol rules, while to large blockers this was not the case at all. To the large blockers, most users did not run fully validating nodes, they typically ran light nodes. However, even in this large blocker vision, where users didn’t have full nodes, they still had wallets. All user wallets, even though they don’t enforce all the protocol rules, still enforce some of the rules. Bitcoin had all kinds of rules and conventions, not just the blocksize. For instance, transaction formats, signatures approving spending, a Merkle tree structure, a block header format etc, etc. Surely Brian and the large blockers were not arguing that anything with more computational power behind it, even just a chain of hashes without any other transaction-related data, would or could be defined as Bitcoin? Even in the large blocker world view, where people only ran light nodes, blocks still had to comply with some rules.
Perhaps a more favourable interpretation of Brian’s argument is that miners were free to do as they wished within the protocol, except for the rules imposed on them by the light wallets. In that context, this larger block narrative makes more sense. This may have excluded the blocksize limit from the rules, however different light wallets enforce different subsets of the rules. Therefore, there would have been a grey area in drawing the line between what miners can control and what they cannot. Small blockers disagreed with this. They required strong clarity with respect to what was a network rule and what was not, to ensure there was always little doubt as to which was the longest valid blockchain.
I often tried to explore this topic with some of the large blockers. I asked them questions like: what happens if the miners create new inflation above the 21 million supply limit and gave these coins to themselves; if that chain had more work, would that be Bitcoin? Typically, they responded by saying something like: “Miners would never do that”; or “Bitcoin is about game theory and incentives, if miners were to do that the price would fall”; or “the game theory is structured such that miners would not do that”. If miners did that, all the nodes and wallets would regard that chain as invalid, I proclaimed. If miners breached the supply cap, you would not see those blocks. Large blockers typically responded to this by claiming that “nodes do not matter”; to them Bitcoin is defined at the most work chain, whether their nodes were following it or not. If a user wanted to be part of Bitcoin, they may need to download and install new node software to make sure they followed the most work chain, whether it breached some rules or not.
It was not clear to me who was correct here. It depended on how people behaved. If everyone behaved like the large blockers and downloaded new clients to follow the longest chain, then yes, they were correct. However, if everyone behaved like the small blockers and stubbornly kept their original client, then the small blockers were correct. This was an open question and nobody could be 100 percent certain of the right answer. The extremists on both sides appeared convinced that they were correct, however they were both being closed-minded. Both sides had built a mental model that assumed people would behave just like them. The reality, of course, was that different people had different ideas and visions and would therefore behave differently. The larger blocker visions appeared to rely on almost everyone agreeing with them, while the small blocker vision appeared to require any significant minority to agree with them. From this perspective, it appeared to me as if the small blockers were mostly correct. Some people would upgrade their clients, and some would not, therefore we may have a network split.
This different vision with respect to the role of full nodes in enforcing the rules led to further confusion. Small blockers often said they opposed a blocksize limit increase, as it would make the cost of running a node too high, which could reduce the full node count and cause centralisation. Large blockers wrongly interpreted this to mean that small blockers were concerned that there would be not enough relay nodes, and therefore the peer-to-peer communication network, where transaction data is propagated around, may be too weak. Communication would therefore be centralised around a few large hubs. In general, this was not the type of centralisation that small blockers were concerned about. They were more worried about the idea that not enough end users would be able to run Bitcoin clients which fully validated all the protocol rules, which could undermine the decentralisation of the enforcement of the protocol rules. The large blockers never seemed to even understand this concern and believed that it was not necessary that end users needed the capability to run these full node clients. The risk that larger blocks would therefore make it prohibitively expensive to run full nodes, was not a significant concern to the larger blockers. These different visions essentially meant both sides were talking at each other, rather than building up an understanding of the others’ point of view.
This confusion was often mingled with a similar misconception about how Bitcoin worked. Namely, the popular idea that a 51 percent mining attack could steal user funds, even without a valid signature being provided by the spender. Miners cannot do that, at least in the small block world; all miners can do in a 51 percent attack is double spend transactions where they have a valid signature for two conflicting transactions. This is not to say that all large blockers didn’t understand this; they did to some extent. It is just that this was a new area of science being explored for the first time. There was considerable uncertainty from both sides on this issue, and it takes time to build up an understanding. The lack of clarity in this area reduced the capability of the large blockers to achieve their objectives. Had the larger blockers more succinctly focused on removing the blocksize limit from the protocol rules, rather than creating confusion over whether such rules even existed, they may have been more successful.
Brian’s view, that the hashrate defined the chain, appeared to be reinforced by the last sentence in Bitcoin’s whitepaper, which read as follows:
They vote with their CPU power, expressing their acceptance of valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them. Any needed rules and incentives can be enforced with this consensus mechanism.
This quote was often circulated and repeated by the large blockers. However, it is not clear that Satoshi shared this vision at all. Indeed, the whitepaper also states:
We consider the scenario of an attacker trying to generate an alternate chain faster than the honest chain. Even if this is accomplished, it does not throw the system open to arbitrary changes, such as creating value out of thin air or taking money that never belonged to the attacker. Nodes are not going to accept an invalid transaction as payment, and honest nodes will never accept a block containing them. An attacker can only try to change one of his own transactions to take back money he recently spent. [3]
Above, Satoshi makes clear that nodes do enforce certain rules. It is important to judge the whitepaper in context: it was primarily about a potential solution to the double spend problem. Users running nodes to enforce the rules was not the key innovation of the system; proof-of-work mining was. Miners decided on the order of transactions. It is in this context, small blockers argued, that one should assess the last line of the whitepaper. However, those two quotes in the whitepaper do seem somewhat contradictory.
To many, it appeared as if there were some fundamentally different visions as to how Bitcoin worked. However, this potential issue did not necessarily have to directly cause problems in this blocksize war. Above all, what the large blockers really wanted was larger blocks. They wanted to give miners free rein with respect to the blocksize, whether that was under a BIP 100-like system where miners vote for the limit, or by removing the blocksize limit altogether from the Bitcoin protocol rules. Instead, there was confusion in the space around this issue, with large blockers often claiming the majority of the hashrate was able to do almost anything, without adding any qualifications. This lack of focus and clarity greatly damaged the large block camp. It made it much harder for them to recruit users to their side. The argument that in the event of a hardfork blocksize limit increase being supported by a majority of miners, users would install a new large blocksize limit client, because it increased the blocksize limit, made a lot of sense to me; the large blockers did have a point here. However, the argument that anyone would download and install a new client to follow a longer chain that stole coins from some users and gave it to the miners made little sense. If that really happened, I had a high degree of confidence that the larger blockers would quickly abandon their claim that there were no network rules. Therefore, perhaps the apparent difference of vision was not as deep as it appeared. Large blockers just wanted larger blocks. They made this argument about the most work chain defining Bitcoin as they thought it helped their cause.
In his blogpost, Brian went on to express Coinbase’s continued support for Bitcoin XT:
I think BitcoinXT is one of several good proposals that we’d be happy with, but people shouldn’t read much into it beyond that (we are running a variety of node types in production including bitcoin core, XT, a custom node we wrote which works at our scale, and we will probably add others in the future like BitcoinUnlimited)
Before this blog and explanation, Brian had put out tweets (now deleted) expressing support for Bitcoin XT. Almost immediately after that, Coinbase was removed as a recommended wallet on the Bitcoin.org website. This website was one of the main information sources on Bitcoin and the website was originally set up by Satoshi.[4] This aggressive action was very similar to the moderation policy on the Bitcoin Reddit. It infuriated larger blockers, who believed it was petty, childish and divisive. On the other hand, smaller blockers proclaimed that Coinbase had effectively announced its intention to switch from Bitcoin to an altcoin. Therefore, they believed it should no longer be listed on a Bitcoin website, which would cause confusion. Just like the Reddit censorship, this act appeared to only strengthen the resolve of the larger blockers and further divide the community.
In late December, many appeared surprised by the continued support Brian provided to Bitcoin XT, as the idea seemed almost dead at this point, with most mining pools stating that the increase to 8 MB was too large. In the same blogpost, Brian included a screenshot of an excel spreadsheet from miners, showing their preferences with respect to the blocksize. The screenshot indicated that the top three mining pools all opposed Bitcoin XT. Opinions on the matter had changed in the six months since miners had agreed to 8 MB. A simple, more conservative increase to 2 MB was now on the agenda and appeared to be gathering momentum.
On January 14, 2016 there was another seminal moment in the blocksize war. Mike Hearn, the primary proponent of Bitcoin XT, was so frustrated by the lack of progress on the blocksize issue that he declared Bitcoin a failed experiment and announced he was selling all his coins.[5] Mike opined:
The resulting civil war has seen Coinbase — the largest and best known Bitcoin startup in the USA — be erased from the official Bitcoin website for picking the “wrong” side and banned from the community forums. When parts of the community are viciously turning on the people that have introduced millions of users to the currency, you know things have got really crazy.
Mike Hearn’s apparent “ragequit” was featured in many media outlets and appeared to have caused a 10 percent collapse in the Bitcoin price, from US$432 to around US$388.
A couple of days after Mike’s announcement, on January 16, 2016, Jihan Wu tweeted the following:
Mike Hearn Loser expressed lots of racist and unfair opinion against China bitcoiners. Explaining why he could not get enough support.[6]
Jihan was one of the most influential and significant players in the mining industry. He was the co-CEO and co-founder of Bitmain, a Chinese company that produced mining machines, had its own mining farms and operated mining pools. Jihan was clearly angry at Mike’s ragequit, however the criticism is somewhat ironic as Jihan would soon establish himself as the leading player in the large block camp. As for Jihan’s assertion about Mike’s racism, this seemed strange to me, as in all my interactions with Mike this had not come across at all. On the other hand, some large blockers had expressed some anti-Chinese comments to me directly. For instance, they blamed the lack of support for XT on Chinese loyalty to the oppressive status quo and drew parallels to the widespread support of the communist party in China. This explanation for a lack of XT support was ridiculous and outrageous in my view, and stems from confirmation bias, which was rampant in the space. It is possible Mike may have expressed this kind of view, but unlikely. The following day, Mike indicated in a forum post that he had had heated phone conversations with Chinese miners. These calls are likely not to have gone well, and this may have been what caused the racism accusations. The post also explains why 8 MB was originally chosen as the limit for Bitcoin XT; eight is a lucky number in China.
Why eight? Because it’s a Chinese homonym for “prosper” or “wealth”:
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 statements, 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.[7]
It is around this point, when the last nail had been put in the XT coffin, that the large blockers needed a new cause to rally around. The next attempt at larger blocks was called Bitcoin Classic.[8] This was a simple, one-off jump to a 2 MB limit, a much more moderate and reasonable proposal than the 8,000 MB which was included in Bitcoin XT. This time, Gavin would be the lead developer, rather than Mike. Jeff Garzik now also supported the proposal and was listed on the Classic website as a developer. Classic appeared to have a better chance of success than XT, with its much more moderate approach to the blocksize.
Almost all the miners and major industry players appeared to agree with a one-off jump to 2 MB. On the other hand, a precedent had been set, a campaign to remove a Bitcoin consensus rule had just failed and now the large blockers were trying the same thing again. This appeared to give the small blockers some hope. Bitcoin miner Jonathan Toomim had argued at Scaling Hong Kong that 2 MB was a safe limit, and he was an advocate of Bitcoin Classic. Small blockers nicknamed the coin “ToomimCoin”,[9] perhaps as part of an attempt to associate Classic with Jonathan Toomim, in the same way Bitcoin XT had been linked to Mike. Bitcoin Classic was officially released on February 10, 2016.[10]
Bitcoin Classic’s activation methodology was almost identical to Bitcoin XT, with no improvements. There was also no effort to obtain widespread consensus before encouraging users to run the client. Indeed, the large blockers did not want to do this. Not only did the large blockers want larger blocks, but they also appeared to despise the activation methodology advocated by the smaller blockers. This was down to a lack of trust, as well as anger at the censorship and other perceived aggressive behaviour from the small blockers. Bitcoin Classic therefore kept the 75 percent miner activation threshold which Bitcoin XT has used. This appeared to me to be a tactical blunder. Had they chosen a more moderate activation methodology, with better safety features, it would have been an opportunity for the large blockers to split the small block camp and potentially emerge as victors in this conflict.
In general, the small blockers opposed the 75 percent threshold for several reasons. The flag in the block header was considered a safety signalling mechanism, indicating that everyone was ready to upgrade. In their minds, the upgrade itself is not meant to be controversial or voted on. In April 2012, the P2SH softfork activated with a 55 percent threshold. However, after this upgrade occurred, the 45 percent of miners who had not upgraded produced invalid blocks for several months after the activation. This was considered a problem and therefore a new 95 percent threshold was selected, which has been used ever since. To the large blockers, the miner flagging was a vote or decision-making process. In such a scenario, 75 percent seemed a strong majority, while 95 percent appeared an unrealistic target. In addition to this, the larger blockers thought that 75 percent was easily enough hashrate to build the longer chain. In their mind, 51 percent was enough to control the network and 75 percent represented an unnecessarily large buffer.
I do not think small blockers opposed miner votes in order to gauge their opinion. However, there is a distinction between gauging the opinion of miners and flags in the block header which activate changes to the consensus rules. Small blockers considered these flags as a critical part of network security and combining activation with miner voting over proposals was dangerous and inappropriate.
What the large blockers didn’t realise at this point in the conflict was that their chosen activation methodology was significantly hampering their own chances. It was almost akin to going into battle and tying one’s own hand behind one’s back. Remember, the large blockers were trying to increase the blocksize limit: the prevailing rule was that blocks needed to be 1 MB or smaller, and they wanted this to be 2 MB or smaller. The smaller block rule is therefore a subset of the larger block rule, and this created asymmetry. If the hardfork activated and the network split, the larger block nodes would consider the smaller block chain as valid, while the smaller block nodes would consider the larger block chain as invalid. In the event of a contentious split, this asymmetry created an advantage for the small blockers. What this means is that, if the smaller block chain ever took the proof-of-work lead, the larger block chain could vanish from existence, known as a wipeout. This may not sound like a large threat, especially if the larger block chain has a super majority of miners, but one needs to consider the situation from the point of the split. If, by chance, when the first block over 1 MB is produced, the smaller block chain took the lead, it could wipe the larger block chain out of existence quite quickly. This could have a devastating effect on the larger block side, as miners could be fearful of ever producing a larger block again.
When one considers this from the perspective of financial markets, the asymmetry of the situation becomes potentially even more significant. It created the opportunity for financial speculators to back the coin on the smaller block side and short the coin on the larger block side. This would have the impact of driving the price of the larger block coin down and the smaller block coin up, which would then incentivise miners to switch to the smaller block chain to earn higher mining rewards. This could eventually completely wipeout and destroy the larger block chain, providing the speculators with large profits.
This problem had a simple fix: the activation methodology could require that the first block at the activation point was greater than 1 MB, thereby resulting in a clean split where no chain was vulnerable to a wipeout. However, when discussing this with larger blockers, I was told this wasn’t an issue, since support for the larger block side was overwhelming. Large blockers also believed that the hashrate majority defined Bitcoin, and including such a checkpoint undermines this view. It was almost as if the large block ideology made their chain more vulnerable. A prominent smaller blocker however, did discuss this issue with me. He said that it’s best to keep this issue quiet, better to not interrupt an enemy while they are making a major mistake, he explained. Some small blockers preferred to keep this potential tool in the bag as an emergency mechanism to use in the event that a larger block chain with this weakness was launched. As the war progressed, this lesson was eventually learnt by the larger blockers, and they did adopt the clean split approach with a checkpoint. However, it took them until the summer of 2017 to appreciate this.
Bitcoin Classic (along with Bitcoin XT) had another self-imposed disadvantage, which, combined with the asymmetry mentioned above, made the situation even worse for them: the 75 percent rolling activation windows. As mentioned before, Bitcoin had used a 95 percent activation thresholds to activate softforks, but these were over fixed two-week periods. In contrast, the Bitcoin Classic hardfork had a rolling 75 percent window, meaning that if 750 blocks flagged support for Classic in any consecutive 1,000 block period, it would activate. Let’s assume that miners gradually upgrade over time, which was certainly the case with previous upgrades. Since the grace period was only four weeks this essentially means that, at the time the first large block was produced, approximately 25 percent of the miners would still be mining the smaller block chain. Had fixed voting windows been used, even with a 75 percent threshold, this would have at least allowed the possibility of greater than 75 percent support. Actually, the situation was likely to be even worse. When one did statistical analysis on the miner signalling, assuming slow adoption, Classic was likely to cross this 75 percent threshold before 75 percent of the miners had even upgraded. The most likely scenario was a 29 percent vs 71 percent split.[11]
The rolling window was therefore almost guaranteed to cause a chaotic split. Large blockers were insisting on going into battle with their hands tied behind their backs and wearing blindfolds too. Regardless of numbers on either side, the likely outcome was a victory for the smaller blockers.
This rolling window seemed entirely unnecessary and was explained to Gavin on numerous occasions by some of the Bitcoin developers. However, Gavin was not concerned by this since, in his view, support for larger blocks was overwhelming. This was therefore not an important problem. It may have been prudent for Gavin to listen to this feedback, since for very little extra effort he could have increased the chances of making the upgrade as smooth as possible and potentially won more people over to his side. Indeed, Gavin could always have been wrong in his assumption of the level of support for Bitcoin Classic. Better safe than sorry, I thought. The refusal to do this did not feel like the old Gavin to me, who appeared more cautious in his approach and more open-minded. It seemed like his frustration with the situation had clouded his judgement to some extent, and he was losing his patience. Perhaps Gavin was totally justified in losing his patience, and perhaps all these concerns from the small blockers were merely stalling tactics. The small blockers were quite good at that. It was not as if the small blockers were saying “just fix these two things and we will support Classic”. Had Gavin fixed this, the same people would have just moved on to additional problems with Classic they had identified. For example, they would have then asked for the block header to change, so that light clients knew the hardfork had occurred, which was another safety feature small blockers often demanded. Like most of these issues in the war, the truth probably lies somewhere in the middle, but the fact that the large blockers finally addressed some of these concerns later on in the war suggests that perhaps there is some truth to the claim that they were damaging their own side with these activation systems.
Despite these potentially disastrous weaknesses in Bitcoin Classic’s activation methodology, Classic was growing in popularity. Almost all the Silicon Valley-backed venture companies in San Francisco, such as Coinbase, backed Classic. The weaknesses in Bitcoin Classic were too theoretical, too technical and not widely understood or discussed. At this point, the larger blockers had the momentum and were winning the war. More and more mining pools, such as Bitfury Group, started to state their intention to support Bitcoin Classic.[12] At the same time, more ecosystem companies were announcing their support. However, the number of blocks actually flagging support for Bitcoin Classic was fairly low, and not many users appeared to be running Classic nodes.
In February 2016, an event was held called the Satoshi Roundtable. It was the second in a series of annual events that continued until 2020 which provide an opportunity for leaders in the blockchain space to gather and discuss various issues. The agenda this time was dominated by the blocksize issue. I was not in attendance at this event, so cannot provide a first-hand account. Brian Armstrong did attend, however, along with his colleague at the time, Litecoin founder and brother of Bobby Lee, Charlie Lee. After the conference, Brian wrote a blogpost criticising several Bitcoin Core developers and proclaiming his support for Bitcoin Classic. From memory, initially the post was more scathing against Bitcoin Core, however this was quickly rectified with a more moderate post.
In my opinion, perhaps the biggest risk in bitcoin right now is, ironically, one of the things that has helped it the most in the past: the bitcoin core developers.
…
The core team contains some very high IQ people, but there are some things which I find very concerning about them as a team after spending some time with them last weekend. Some of them show very poor communication skills or a lack of maturity — this has hurt bitcoin’s ability to bring new protocol developers into the space. They prefer ‘perfect’ solutions to ‘good enough’. And if no perfect solution exists they seem ok with inaction, even if that puts bitcoin at risk.
…
We need to form a new team to work on the bitcoin protocol. A team that is welcoming of new developers to the community, willing to make reasonable trade offs, and a team that will help the protocol continue to scale. You’ll be hearing more about this over the next month or two.
…
If you want to ensure Bitcoin’s success, I’d encourage you to upgrade to Bitcoin Classic in the short term
…
I also gave the example of web browsers. The Chrome and Safari team are fierce competitors, but also attend the same conferences and collaborate with the IETF on standards. Many competing companies were present at the conference as well. They weren’t hostile or combative between each other. We are all working in the same industry and are friends in many ways. It would be the same with multiple teams working on the bitcoin protocol. By providing choice in the market you will get more progress, not less.[13]
The above is a summary of perhaps the most controversial parts of Brian’s post. It clearly reflected a growing resentment towards some of the Bitcoin Core developers and a desire for Bitcoin to break free from them.
Brian brought up the example of competing developer teams in web browsers, Chrome vs Safari. Of course, to the small blockers this illustrated that Brian did not understand the situation. Web browsers did not have a global consensus system. To small blockers, this war was not about competing teams; it was about competing network consensus rules and therefore competing coins, with the potential of market prices and financial flow between the coins, and all the complexity that a split entails. Bitcoin Classic wasn’t even really a competing team at all. It was largely the same code as Bitcoin Core, with a few parameters changed. There were already competing teams, with a different codebase to Bitcoin Core, that implemented Bitcoin. These other Bitcoin clients were written in different languages, for instance Libbitcoin or BTCD. The failure to appreciate the distinction between competing coins and competing teams was a pivotal mistake from the large blockers. From the small blocker perspective, the large blockers wanted larger blocks but didn’t understand how Bitcoin worked or how to conduct a hardfork, so they let their frustration out on Bitcoin Core and the development team, a convenient scapegoat.
Despite the lack of significant miner signalling for Bitcoin Classic, in February 2016 it felt like miners would be getting ready to signal, and activation looked like a real possibility. At the same time, Coinbase’s support for Classic now looked resounding. Given some of the parameters involved in the activation and the resolve of the smaller blockers, which the larger blockers failed to appreciate, Bitcoin appeared to me to be heading into a major crisis and split. At this point in the war, the larger block side were in a stronger position than they had ever been, while the smaller blockers still had some tricks left up their sleeves. Bitcoin felt on the brink of a catastrophic failure.
[1] https://www.reddit.com/r/bitcoinxt/comments/3yewit/psa_if_youre_running_an_xt_node_in_stealth_mode/
[2] https://blog.coinbase.com/scaling-bitcoin-the-great-block-size-debate-d2cba9021db0
[3] https://bitcoin.org/bitcoin.pdf
[4] https://github.com/bitcoin-dot-org/Bitcoin.org/commit/7d1cdd94651461ff13ad4ed10b05b2374690fac2
[5] https://blog.plan99.net/the-resolution-of-the-bitcoin-experiment-dabb30201f7#.h81ihjioy
[6] https://twitter.com/JihanWu/status/688300019003162626
[7] https://news.ycombinator.com/item?id=10920902
[9] https://bitcointalk.org/index.php?topic=1330553.0
[10] https://github.com/bitcoinclassic/bitcoinclassic/releases/tag/v0.11.2.cl1
[11] https://bitcoinmagazine.com/articles/bitcoin-classic-hard-fork-likely-to-activate-at-hashrate-support-1457020892
[12] https://twitter.com/valeryvavilov/status/688054411650818048
[13] https://blog.coinbase.com/what-happened-at-the-satoshi-roundtable-6c11a10d8cdf
