The Scaling Wars

In October 2010, when Bitcoin was still an obscure experiment, a developer named Jeff Garzik proposed changing a number in its software. The maximum block size was approximately one million bytes. Garzik wanted to raise it dramatically so that the network could someday carry payments at the scale of an established service such as PayPal. Bitcoin was barely being used, yet a question that would later consume its community had already appeared: what should happen when a network built to let strangers agree on one ledger needed to change the rules of that agreement?

Satoshi Nakamoto's answer was not that the limit could never be changed. It was that such a change needed coordination. Nodes following the old rules could reject oversized blocks produced by nodes running the new rules. A network could not safely treat a breaking alteration as if it were an ordinary software improvement. [1]

The exchange anticipated the Scaling Wars more clearly than its participants could have known. A block-size limit regulates more than traffic. It also establishes how much data a validating node might have to download, check, retain, and relay. A larger maximum permits more transactions in each block but may make it harder for some people to operate independently. A smaller maximum reduces those demands but makes access to scarce block space more expensive as demand increases.

Neither consequence settles the matter by itself. Bitcoin's distinct promise was not merely that payments could move across a network. It was that participants could verify the rules of a monetary system without obtaining permission from an institution. Protecting that independence while accommodating more users would become one of Bitcoin's most difficult arguments.

The Bitcoin white paper introduced a peer-to-peer electronic cash system but did not prescribe a perpetual one-megabyte maximum block size. The limit emerged in the early software. By the time Garzik proposed his October 2010 increase, its enforcement had become relevant to whether nodes would accept the same blocks. [1]

One megabyte did not mean exactly a fixed number of transactions. Transaction sizes differ: a payment spending several prior outputs uses more bytes than one spending a single simple output. A block can also contain data that does not correspond neatly to an ordinary customer payment. The limit constrained block data rather than imposing a simple count of purchases. With blocks targeted at roughly ten-minute intervals, though, a fixed ceiling still created a finite supply of settlement capacity.

At first that ceiling was generous compared with actual demand. As the network grew, it became a binding design question. Raising the maximum would be a hard fork if it permitted blocks rejected by software enforcing the old rule. The fact that a developer could edit the limit locally did not alter what an unmodified node considered valid.

The exchange with Satoshi established a principle that survived the later argument: an implementation could define a proposed rule, but compatibility with other implementations remained a separate problem. The central controversy would concern what counted as adequate agreement, how to establish it, and how much risk to take when it could not be established.

A full node independently checks the history and current rules of Bitcoin. It does not need to trust a mining pool's assertion that a block is valid. That independence has a cost: bandwidth, processing, storage, and the time required to synchronize a new machine with the network. A more demanding chain can narrow the group able to maintain that independence, especially where internet service or equipment is expensive.

Opponents of rapid increases emphasized that the cost is not only the disk space consumed by the latest block. Larger blocks must be propagated to miners and other nodes, checked against consensus rules, and incorporated into a growing history. Different costs change at different rates. Technical improvements can reduce some of them without eliminating all others. If ordinary participants abandon validation, powerful service providers gain the ability to mediate users' understanding of what Bitcoin is doing.

Advocates of larger blocks pointed to an equally uncomfortable possibility. If on-chain transactions became slow or expensive, ordinary users might also move to custodians, hosted wallets, or payment services. A payment network that made independent verification affordable but direct participation economically unattractive could likewise concentrate practical control. They questioned whether conservative limits would protect decentralization in theory while undermining it in daily use.

The difference was not between a group that valued decentralization and one that ignored it. It was between competing predictions about where dependence would accumulate. Gregory Maxwell's December 2015 roadmap recognized explicitly that resource requirements and too little practical capacity could both force greater trust in intermediaries. The official 2015 Montreal workshop program placed research into validation costs, fee markets, propagation, and payment channels side by side. [2] [3]

The debate also concerned the economics of transaction fees. A constrained block creates competition for scarce space. Higher fees can reward miners but also price out smaller payments. Larger blocks can accommodate more demand in the short run, but participants disagreed over whether a sufficiently strong future fee market required persistent scarcity. No simple formula determined the best size for a globally distributed monetary system whose future usage was unknown.

By 2015, Gavin Andresen believed the constraint was approaching economic significance. His BIP 101 proposed replacing the fixed maximum with a schedule beginning at eight million bytes and doubling approximately every two years. The proposal did not promise that blocks would immediately be filled to that size. It changed the ceiling under which miners could construct them. Its long-term schedule was nevertheless ambitious, relying on the expectation that computing and network capacity would continue improving. [4]

BIP 101 also specified miner signaling. This was an attempt to coordinate activation through blocks themselves, not a ballot in which every Bitcoin user could cast an equal vote. Miners could communicate readiness, but a node enforcing the former maximum would not accept a larger block merely because a signaling threshold had been reached elsewhere.

Mike Hearn and Andresen backed Bitcoin XT, an alternative implementation intended to offer a practical route beyond the prevailing Bitcoin Core approach. The August 2015 release gave operators an actual program to install, making disagreements over code review and priorities concrete. Publishing XT did not, by itself, produce a new blockchain. Its proponents were seeking enough coordinated adoption for the new rules to take effect. [5]

To supporters, the availability of an alternative client was evidence of Bitcoin's openness: no particular repository owned the right to decide its future. To critics, an incompatible activation mechanism risked setting the network on competing paths, with users exposed to consequences they might not understand. Both arguments drew on real features of a permissionless system.

XT ultimately failed to deliver BIP 101 as an accepted Bitcoin consensus change. That outcome does not make its original concerns imaginary. It makes the failure of its coordination strategy a historical fact worth examining. At the moment an alternative release entered the public conversation, an engineering debate became a contest over who could credibly claim to lead an upgrade.

The Bitcoin protocol did not have a central authority able to forbid an alternative implementation. Public conversation, however, depended heavily on identifiable venues. The Bitcointalk forum and r/Bitcoin subreddit had administrators and moderators who could promote, restrict, or remove discussion. In August 2015, discussion of Bitcoin XT became a public controversy when moderation restrictions and removed posts were challenged by large-block advocates. [6]

Critics argued that restricting discussion of alternative software gave the appearance of a closed development establishment. Defenders distinguished promotion of potentially incompatible software from discussion of the existing Bitcoin project, and argued for moderation against repetitive advocacy and manipulation. The historical evidence establishes that restrictions existed; it does not establish that every conversation about XT was prohibited in every venue. Other forums continued to host the dispute, and competing discussion communities grew around different approaches.

The controversy revealed a distinction that software alone could not erase. Bitcoin users did not have to request permission to validate blocks, but they still depended on channels of public information to decide which software and arguments they trusted. Administrators could influence visibility without controlling the network's rules.

The role of Blockstream was contested. The company was founded by Bitcoin developers in 2014, publicly raised investment capital, and announced work on sidechains including Liquid. Some employees also contributed to Bitcoin Core. These relationships are documented. They do not, without additional evidence, prove that Blockstream directed the moderation decisions or engineered Bitcoin's block-size limit to promote commercial products. Those were claims advanced in a bitter dispute and require attribution, not adoption as established fact. [7]

A larger lesson was emerging: freedom to publish software did not guarantee equal access to attention. Control of a popular forum was meaningful social power, but not consensus-rule authority. The Scaling Wars increasingly confused—or deliberately contested—the boundary between those forms of influence.

In September 2015, developers, researchers, miners, and other participants met in Montreal for the first Scaling Bitcoin workshop. Rather than presenting one block-size solution for endorsement, organizers sought to describe the technical bottlenecks and evaluation criteria. The schedule included relay networks, validation costs, security concerns, fee economics, wallet design, and payment channels. It also presented an argument by Peter Rizun that a transaction fee market could exist without a fixed maximum of the kind then in force. [3]

The workshop did not settle the argument, but it exposes the weakness of later accounts that describe the competing positions as purely ideological. Specialists disagreed about measurable properties: how quickly large blocks reached miners, how propagation delays affected orphan risk, how much full-node operation cost, and which improvements were ready to deploy.

The December follow-up in Hong Kong moved further toward concrete proposals. Pieter Wuille described Segregated Witness; other speakers discussed layers and efficiency gains. The location mattered because Chinese mining operations played an important role in block production and international attendance could not be taken for granted.

Technical workshops created a place for arguments to be tested, but they could not create binding agreement for a currency that had no mechanism for obliging nonparticipants to upgrade. Their value was evidence, research, and communication. For advocates convinced that congestion was imminent, methodical review could seem intolerably slow. For developers worried about permanent consensus errors, rushed activation could seem intolerably dangerous.

The same gathering could therefore be remembered as a serious effort to reconcile perspectives or as another delay in a process already incapable of reaching a decision. Neither memory should substitute for the programs, transcripts, and contemporary statements. [3]

Segregated Witness began as an engineering approach to how signatures and other witness information were represented in Bitcoin transactions. Traditional transaction identifiers could be affected by changes to certain signature-related data without changing the underlying economic transfer. Such transaction malleability complicated designs in which subsequent transactions depended on a stable identifier for a prior unconfirmed transaction.

Payment channels were especially sensitive to this problem. Participants wanted to make and update payments while relying on the blockchain for eventual enforcement if cooperation failed. A transaction identifier that an outsider could alter created unnecessary uncertainty for some arrangements. SegWit changed how transaction identifiers and witness commitments were constructed for new transaction forms, removing the known third-party malleability problem for those transactions. It helped prepare a foundation for the Lightning Network, although Lightning's subsequent development required additional engineering and deployment. [8] [9]

SegWit also altered Bitcoin's capacity accounting. Instead of simply raising the old one-million-byte ceiling, BIP 141 introduced a four-million-unit block-weight limit. Non-witness data and witness data were weighted differently. This could accommodate more effective transaction capacity, depending on how wallets used the new transaction forms. It was not equivalent to permitting four megabytes of arbitrary legacy transactions, nor did it instantly make every wallet more efficient. [8]

The soft-fork deployment design was central. Older nodes could continue checking the rules they understood, while upgraded nodes enforced additional conditions for the new witness structure. That compatibility reduced one class of coordination risk relative to an incompatible hard-fork expansion. It did not make deployment automatic or eliminate all questions about the security assumptions of nodes that did not upgrade.

SegWit was not merely a marketing label for a small-block position. Its development involved sidechain experimentation, multiple contributors, test networks, extensive code review, and difficult decisions about validation, transaction structure, and backward compatibility. The contemporaneous Bitcoin Core account traces this work from Pieter Wuille's earlier Elements implementation through 2016 testing and review. [9]

The feature was technically significant even for readers who later disagree with its activation politics. Separating the invention from its contested rollout is essential to telling the history fairly.

The failure of the XT initiative did not end proposals for larger blocks. Bitcoin Classic promoted a more modest initial increase to two megabytes; Bitcoin Unlimited explored configurable rules and a model of emergent consensus. Their proponents differed over methods and risk, not merely over their names. They could agree that additional on-chain capacity mattered while disagreeing about how much, how soon, and through whose decisions. [10] [11]

In January 2016, Mike Hearn announced his departure from Bitcoin development in an essay that portrayed the experiment as having failed. His denunciation was a participant's judgment at a time of intense conflict, not a verified description of Bitcoin's future. It shows how grave the institutional disagreement had become for an early contributor. [12]

In February, representatives from mining businesses and other organizations met with individual Bitcoin Core contributors in Hong Kong. Their published Roundtable Consensus supported proceeding with SegWit and undertaking work toward a future hard-fork proposal. The text anticipated an increase in non-witness capacity to around two megabytes, with a total size no more than four megabytes, and said adoption would require broad support. Participating contributors promised an implementation to recommend, not a guarantee that Bitcoin Core would merge it or that users would activate it. [13]

That difference became a source of distrust. For participants seeking assurance that SegWit would not end the prospect of an on-chain increase, the agreement could reasonably be understood as a meaningful political bargain. For those emphasizing the limits of any participant's authority, no roundtable could promise a network-wide rule change.

The commitments thus occupied an unstable position between technical intent and political expectation. The document could record work to be undertaken; it could not bind absent users. When expectations diverged, each side could accuse the other of treating conditional statements as absolute commitments, or of walking away from what had been understood at the table.

Hong Kong did not resolve the governance problem. It exposed it in contractual language.

SegWit's path into Bitcoin passed through BIP 9, a deployment mechanism in which miners signaled with designated block-version bits. A threshold of 95 percent over a 2,016-block window was required for lock-in. Lock-in meant the activation conditions had been met; actual enforcement followed later. [14]

The signaling mechanism was sometimes described in the language of voting. That metaphor was convenient but incomplete. Mining pools selected and produced blocks. The owners of the underlying hash power were not each casting an equal personal ballot, and neither exchange customers nor independent full nodes cast votes through block headers. Most importantly, no amount of signaling made an otherwise invalid block acceptable to a node whose consensus rules rejected it.

Signaling did matter. It offered an observable way to coordinate miners before new rules took effect, reducing the chance that a software change would strand significant hash power on a chain rejected by its intended users. But the threshold also introduced a vulnerability to stalemate. A meaningful minority of block production could prevent a 95 percent requirement from being met, even if many developers, businesses, or users favored activation.

The low signaling levels encouraged competing interpretations. Some participants saw insufficient miner readiness and argued for patience or further negotiation. Others saw miners using a coordination mechanism as a de facto veto over a technically reviewed soft fork. Still others objected to the design of SegWit or to the conditions attached to its activation.

The eventual resolution could not be understood simply by counting support letters or blocks. It required distinguishing miner readiness, economic support, node validation, and what would happen if those preferences diverged. Bitcoin's software could measure version bits more easily than it could measure legitimate collective consent.

Bitcoin Unlimited challenged not only Bitcoin Core's preferred block-size constraints but also the idea that the limit had to be centrally specified in one release. Its configurable preferences and emergent-consensus model were intended to give participants greater discretion over capacity. This approach made its implementation and coordination assumptions particularly important: what would happen if different nodes accepted different maxima, or miners produced blocks that some participants refused? [11]

Its proponents argued that a competitive ecosystem of implementations could reduce reliance on one development group. Critics questioned whether flexible limits would lead to unstable coordination, tactical behavior by miners, or unexpected chain disagreement. These were substantive questions independent of any personalities involved.

Software reliability became an additional problem. In February and March 2017, Bitcoin Unlimited faced denial-of-service vulnerabilities. In a conspicuous March incident, crafted network messages were used to crash Bitcoin Unlimited and Bitcoin Classic nodes. Contemporary reporting recorded a steep drop in publicly observed Unlimited nodes. [15]

The incident matters because Bitcoin is adversarial infrastructure. Software intended to secure valuable balances must withstand inputs from strangers who may actively try to make it fail. A bug in an alternative client does not prove its scaling philosophy wrong, just as reliability in the most widely used client does not make all its governance judgments correct. Yet users evaluating a contested upgrade reasonably cared whether the alternative software was ready.

Bitcoin Classic's initial two-megabyte proposal and Bitcoin Unlimited's adaptive model did not achieve the intended consensus changes on the original Bitcoin network. That result reflected several interacting obstacles, including disagreement about acceptable rules, activation methods, implementation trust, and the absence of a binding arbiter. The story should not be reduced to one crash or one developer's argument.

For someone buying a modest product, a blockchain is not an abstraction. A transaction is submitted, a fee is paid, and the recipient waits for confirmation. When demand for block space rises, miners tend to select transactions offering higher fee rates. A lower-fee payment can remain unconfirmed while more competitive payments pass ahead of it.

This pressure became increasingly visible during 2017. The experience varied with the time of day, wallet software, transaction size, and fee-selection strategy. Some users could choose to wait; others were paying at a checkout counter, moving an exchange balance, or dealing with a payment processor that expected timely confirmation. A headline about average fees could hide those differences.

The most revealing contemporary commercial example came after the central political conflict had reached its climax. On December 6, 2017, Valve announced that Steam would stop accepting Bitcoin. The company cited elevated transaction fees and Bitcoin's price volatility, explaining that payment adjustments and refunds were becoming impractical when sending money again incurred a substantial network fee. The announcement said fees had approached twenty dollars, compared with approximately twenty cents when Bitcoin payments were first introduced. [16]

This example should not be projected backward as if every negotiator in May had already observed December's conditions. It is later evidence that the capacity problem remained economically consequential. It also illustrates why a serious account must acknowledge that larger-block advocates had genuine user problems to solve.

The counterargument remained important: simply providing greater base-layer capacity could increase verification burdens, and some applications might be better served by off-chain payment channels or more efficient transactions. The hardest question was not whether payments should be affordable. It was how to preserve direct access and independent verification as the network scaled.

In March 2017, the proposal known as BIP 148 described a user-activated soft fork. Starting August 1, participating nodes would reject blocks that failed to signal support for the existing SegWit deployment, unless SegWit had already locked in or activated. It did not rewrite SegWit's substantive rules. Instead, it tried to compel signaling under the already specified activation mechanism. [17]

The difference is subtle and essential. A user operating a validating node could always reject a block that violated that user's selected rules. BIP 148 sought to make that action an effective collective commitment. If enough economic participants enforced the same restrictions, miners would have a practical incentive to produce blocks they accepted. If too few did, BIP 148 users could find themselves following a smaller chain, with serious risks of reorganization and incompatible confirmation histories.

The idea acquired a distinctive public culture. The initials UASF became a declaration that miners did not own Bitcoin's rules. The movement challenged the assumption that lack of miner signaling should indefinitely prevent a compatible soft fork from activating.

It was never a universal position among Bitcoin Core contributors. Minutes of a May 25 developer meeting record Pieter Wuille objecting that merging BIP 148 would encourage network forks, Luke Dashjr arguing that leaving it out could also endanger users, and several contributors preferring the more gradual BIP 149 proposal. [18]

That meeting is one of the Current's most useful pieces of evidence. The apparent public divide between Core and miners concealed disagreement within Core itself over how aggressively to confront the activation stalemate. The central principle—individuals enforce the rules they choose—did not automatically settle whether a particular enforcement strategy was prudent.

BIP 148 made the possibility of chain separation tangible. A July warning on Bitcoin.org acknowledged that confirmations could become unreliable if groups of nodes rejected each other's blocks. Activists were not merely insisting on a preference. They were accepting, or asking others to accept, real coordination risk to obtain a result they regarded as important. [19]

On May 23, 2017, a group of Bitcoin mining and business organizations announced the New York Agreement. Its published terms called for SegWit activation at an 80 percent signaling threshold and a two-megabyte hard fork within six months. Supporters presented it as a practical compromise linking the efficiency and compatibility gains of SegWit to a capacity expansion long sought by businesses and miners. [20]

The agreement reflected real commercial influence. Its supporters included companies operating wallets, exchanges, payment services, and mining facilities. These organizations were not peripheral to Bitcoin's daily operation. They handled customers, investment, transactions, and substantial computing power.

But signatures were not the same as consent from every Bitcoin holder or full-node operator. Companies could express their own positions; in custodial settings, customers might not share them. A mining pool could signal readiness without representing an electorate. Some opponents therefore challenged the legitimacy of negotiating a protocol change through an agreement among selected businesses.

The project created an implementation known as btc1 and established a deployment timetable. It had software, organizational structure, and a proposed activation height—not just a press release. The SegWit2x working group's own archive presents its planned milestones and technical commitments. [21]

What appeared to supporters as overdue coordination appeared to opponents as an attempt to elevate commercial bargaining into authority over consensus rules. The disagreement was sharpened because the second stage would not be compatible with nodes maintaining the existing maximum. Any successful upgrade required a broad alignment of software choice and economic recognition.

New York did not confer that alignment. It initiated a campaign to achieve it.

The weeks before August 1 brought overlapping strategies into direct contact. UASF supporters prepared to enforce BIP 148. Miners and businesses supporting the New York Agreement sought a coordinated way to activate SegWit while keeping the later hard-fork plan alive. James Hilliard's BIP 91 offered one such method: miners could signal for a temporary rule requiring future blocks to signal SegWit, using a lower threshold of 80 percent over a 336-block window. [22]

BIP 91 and BIP 148 were not identical. BIP 148 was a date-based enforcement rule run by its participating nodes; BIP 91 used miner signaling to coordinate a temporary restriction on blocks. Both were designed to produce signaling consistent with SegWit's existing BIP 9 activation.

BIP 91 locked in in July and its enforcement began before August 1. SegWit then reached its original BIP 9 lock-in threshold in August and activated at block 481,824 on August 24. Those are separate milestones: preliminary signaling, enforcement of signaling, lock-in of SegWit, and actual activation. [22] [23]

These events are sometimes retold as a victory caused solely by UASF pressure or solely by the New York Agreement. The underlying sequence does not independently prove either exclusive explanation. The UASF created a credible prospect of enforcement and division; the NYA helped organize a mining and business coalition; BIP 91 supplied a technical coordination path; miners produced the signaling blocks; and users continued validating according to their chosen software.

Bitcoin Optech's later historical account explicitly notes that the relative causal contribution of these factors remains debated. This is a useful limit for the documentary narrative. We can explain precisely how activation occurred without pretending to know exactly which fear, agreement, or preference was decisive inside every participant's decision. [23]

On August 1, 2017, Bitcoin Cash emerged as a separate blockchain sharing Bitcoin's earlier history. The last common block was height 478,558; the first divergent blocks on the two continuing histories were at height 478,559. After that point, participants applied incompatible rules and continued distinct ledgers. Users controlling private keys at the separation generally had the ability to control corresponding assets on both chains, while customers relying on custodians faced additional questions about crediting, support, and withdrawal access. [24]

The split was more than a larger-block software release. Its proponents pursued a different continuing network and argued for greater on-chain capacity as a means of preserving electronic cash. Its existence allowed that approach to be tested through separate users, miners, wallets, and markets rather than depending on consensus-rule adoption by the original Bitcoin network.

Bitcoin Cash also highlighted an important technical problem. When two chains share transaction history and compatible transaction forms, an operation valid on one can sometimes be valid on the other. Replay protection reduces the danger of unintentionally spending assets on both. Bitcoin Cash introduced fork-specific signing rules, including SIGHASH_FORKID, that protected transactions using those rules against replay on Bitcoin. These protections later became a point of comparison in arguments about SegWit2x's treatment of a possible chain split. [24] [25]

At the split, participants could not know the eventual market trajectories of either system. The competing claims about the Bitcoin name expressed interpretations of continuity: maintaining the previous consensus constraints and their associated software network on one side; preserving a particular understanding of Bitcoin's payments purpose on the other.

The two systems' shared origins did not remove the need for exchanges, wallets, custodians, and users to decide what they would support. The separate chain established that disagreement could produce coexistence instead of a universal decision.

By October, the remaining SegWit2x hard fork threatened a different kind of conflict. Bitcoin Cash had already acquired a separate name and market. SegWit2x supporters, however, intended their proposed upgrade to continue as Bitcoin rather than automatically accept minority-fork status.

Bitcoin.org warned on October 9 that custodial services supporting the proposed fork could expose customers to incompatible software, replay risks, or uncertainty about which asset would be called BTC. Its published warning also listed prominent firms it associated with the initiative. The warning was a partisan document in a public campaign; its safety concerns nonetheless referred to genuine hazards that would arise if incompatible chains coexisted. [26]

Coinbase's October statements make the issue unusually concrete. On October 23, the company said the existing chain would initially retain the BTC label and the proposed SegWit2x chain would be designated B2X. On October 24, Coinbase clarified that, after the chains stabilized, it intended to use the Bitcoin name for the chain with the most accumulated difficulty, while potentially considering market capitalization and community support. [27]

That clarification did not change any block-validation rule. It changed the stated commercial policy of a major custodian. For a customer holding Bitcoin through an exchange, names, balances, and trading markets were an immediate part of practical ownership. A person running their own fully validating node could reject an incompatible block, but no node configuration could force a private exchange to use a particular ticker symbol.

The dispute therefore crossed another boundary. The authority to determine what blocks one's own node accepts was technically different from the ability to shape which chain the market recognized as Bitcoin. Neither domain was completely independent of the other. A chain with no economic counterparties could be expensive to maintain; an exchange could not make an invalid block pass a user's full-node checks merely by renaming it.

Bitcoin's identity was neither reducible to accumulated hash power nor established by a company's blog post. It arose from the interplay of rule enforcement, software adoption, history, commerce, and public expectations.

As the November hard-fork date approached, SegWit2x proponents faced unresolved opposition. The proposed change would allow larger base blocks rejected by participants retaining the prior consensus limit. Unlike SegWit, which had entered through a compatible soft-fork path, the second stage required an overt decision about accepting new validity rules.

Replay protection was among the concerns. Opponents argued that if competing chains continued without sufficiently robust separation, transactions or customer balances could be placed at risk. SegWit2x developers discussed their own replay-related mitigation proposals, reflecting the tradeoff between preparing for a split and presenting the upgrade as the continuation of one network. [21] [25]

On November 8, Mike Belshe and other prominent supporters announced that they were suspending the planned two-megabyte hard fork. They continued to believe larger on-chain capacity was needed, but acknowledged that sufficient agreement for a clean upgrade was absent and proceeding might divide the community. A preserved same-day archival capture contains the original mailing-list announcement. [28]

The cancellation did not prove that miners and businesses possessed no influence. They had helped coordinate SegWit's activation and had assembled the resources for a proposed hard-fork deployment. It demonstrated that those resources did not guarantee a non-contentious change to Bitcoin's consensus rules.

Nor did the announcement make every possible attempt to mine under SegWit2x rules technically impossible. The coordinated initiative ended; independent actors remained free to operate incompatible software. The difference between stopping a campaign and preventing an alternative chain from ever existing is fundamental to the nature of Bitcoin.

The fork that did not happen may be the conflict's clearest illustration of the power of nonparticipation. Participants unwilling to accept a proposed rule could not be compelled by a signature or a press release to recognize it as Bitcoin.

Bitcoin Core continued development under the existing base block-size rules, now including SegWit's new transaction and block-weight structure. Bitcoin Cash continued as a separate network. SegWit2x's planned hard fork was suspended. Each outcome was observable; their political meaning remained contested.

For many opponents of contentious hard forks, the cancellation demonstrated that even powerful mining and commercial coalitions could not redefine Bitcoin merely by organizing signatures and software. For some larger-block proponents, the same outcome confirmed that the established development and social institutions were too resistant to on-chain scaling. Neither retrospective conclusion should be treated as a unanimous verdict.

Bitcoin Classic's November 9 closing statement offers a vivid contemporary example. Its release manager Tom Zander described the failure of the proposed two-megabyte compromise and endorsed Bitcoin Cash as the path forward. The statement predicted that Bitcoin Cash could eventually claim the Bitcoin name. This was his interpretation and expectation, not a settled result. [29]

The rhetoric of victory also obscured the participants who had supported SegWit while disagreeing over the later hard fork. Individuals who favored more base-layer capacity did not all choose Bitcoin Cash. Developers who opposed SegWit2x did not necessarily agree with every UASF activation tactic. Mining pools and their hash providers were not identical political actors.

What had become clearer was a structural limit: no single constituency's preferred metric—code commits, miner signals, corporate signatures, forum subscribers, or claimed user counts—functioned as an unconditional right to change the rules recognized by everyone else.

That conclusion is powerful precisely because it is less sweeping than a claim that any one group won control. The Scaling Wars ended without producing a new central authority.

The network emerged from 2017 having activated SegWit but not the proposed two-megabyte SegWit2x hard fork. Its users were now separated from Bitcoin Cash users by incompatible rules and divergent networks. The immediate constitutional lesson was visible: major changes to consensus could not be made binding on all participants merely through industry agreements.

The economic tradeoffs did not disappear. Steam's December decision to stop accepting Bitcoin captured the continuing difficulty of using constrained block space for relatively small everyday payments during periods of high fees. For advocates of on-chain expansion, it was evidence that payment affordability remained an urgent problem. For proponents of layered scaling and cautious base-layer changes, it showed why efficiency improvements and alternative payment architectures needed to mature. [16]

Lightning development was already underway before the conflict, and SegWit had helped remove a major technical obstacle. It would be misleading to describe Lightning as an instant, fully deployed replacement for ordinary payments in 2017. Its subsequent implementations and adoption belonged to a continuing story, not to a victory automatically secured on the day SegWit activated.

The conflict also left a durable political vocabulary: user-activated soft forks, economic nodes, chain splits, contentious hard forks, signaling thresholds, and rule enforcement. Later Bitcoin protocol proposals would inherit the example of 2017, sometimes as a model and sometimes as a warning. A later history can evaluate those consequences, but the participants in November could not know all of them.

Bitcoin's central puzzle remained unresolved in an absolute sense. A decentralized network could change its rules, but the ability to propose, build, signal, and advocate was not the same as the ability to bind every participant. There was no single office to issue the final decision, and no guarantee that disagreeing participants would continue on one chain.

That was the lasting discovery of the Scaling Wars. Bitcoin's participants had not learned to agree. They had learned, through costly experiment, what could happen when agreement failed.

By the end of 2017, three different responses to disputed change had become part of Bitcoin's history: SegWit activated on the original network through a compatible process; Bitcoin Cash continued as a separate chain; and SegWit2x's organizers suspended their planned hard fork. Each response involved coordination among individuals, software implementations, miners, businesses, and users, but none was equivalent to a network-wide election.

The capacity debate had not been answered once and for all. Instead, Bitcoin had acquired a set of precedents about who could make changes, what opposition could accomplish, and what forms a disagreement might take. A community could argue about a rule, publish alternatives, deploy a compatible change, create a separate network, or abandon a contested proposal. The authority to do any one of those things was not authority to command all of the others.

The Scaling Wars exposed how difficult it is to govern money without a government. They also exposed why so many participants believed that difficulty was worth preserving.