The argument was already complete in 2010
On 3 October 2010 Jeff Garzik posted a patch to the bitcointalk forum raising the one-megabyte limit on block size, with the comment: "We should be able to at least match Paypal's average transaction rate." Satoshi Nakamoto replied the same evening: "Don't use this patch, it'll make you incompatible with the network, to your own detriment. We can phase in a change later if we get closer to needing it."
Garzik answered with what phasing in would require: "The effort to raise the transaction rate limit is the same as the effort to change the fundamental nature of bitcoins: convince the vast majority to upgrade." The next day Satoshi gave the mechanism rather than a verdict:
It can be phased in, like: if (blocknumber > 115000) maxblocksize = largerlimit
It can start being in versions way ahead, so by the time it reaches that block number and goes into effect, the older versions that don't have it are already obsolete.
That exchange is still online, and it contains almost everything the next seven years produced: the limit was not treated as sacred, raising it was understood to be a hard fork, and a hard fork was understood to mean convincing effectively everyone. What nobody had in 2010 was a case where the vast majority could not be convinced.
What the problem actually was
A block is capped at 1,000,000 bytes and arrives roughly every ten minutes. That is the whole constraint, and by 2015 the space was being used.
A 2016 position paper by twelve researchers put the situation plainly: Bitcoin "achieves 7 transactions/sec maximum throughput", and "the current trend of ever increasing block sizes on Bitcoin portends a potential problem where the system will reach its maximum capacity to clear transactions, probably by 2017" (On Scaling Decentralized Blockchains, Croman and eleven co-authors, 2016).
Everyone agreed on that sentence. What they disagreed about was whether a full block was a problem to be fixed or a price signal working as intended, and whether the cost of raising the cap fell on people who could afford it.
The case for bigger blocks, at its strongest
Most accounts of this period are written by people who got the result they wanted. So it is worth setting out what the other side actually proposed, in its own published words, before anything else.
The whitepaper reading. Bitcoin's founding document is titled A Peer-to-Peer Electronic Cash System. Bitcoin Classic's own front page still states its purpose as standing "for the original Bitcoin as Satoshi described it" (bitcoinclassic.com). On that reading, on-chain payments between ordinary people are not one use of Bitcoin among several. They are the use, and a cap that prices them out is not neutral: it decides what the system is for. Satoshi's 2010 reply is offered as evidence that the limit was always understood as adjustable.
The fee market. The large-block proposals did not deny that fees must eventually pay for security. They denied that the transition should be forced by a constant written into the software. Jeff Garzik's BIP 102, a one-time increase to 2,000,000 bytes, lists its first motivation as "Continue current economic policy", and argues that an increase was needed "matching market expectations and preventing market disruption". Gavin Andresen's BIP 109 repeats the same first motivation word for word. Two years later Sergio Demian Lerner's Segwit2Mb proposal gave as an aim "reducing temporarily the fee pressure until other scaling techniques such as the Lightning Network, sidechains, drivechains and extension blocks prove to be useful or not" (bitcoin-dev, 31 March 2017). The claim is narrow and hard to dismiss: a fee market arriving because a limit binds is not the same event as a fee market arriving because demand outgrew the technology, and the first one is a choice somebody made.
Node count is not the only measure of decentralisation. This is the argument most often left out. BIP 101's own objections section concedes that reachable full nodes had been declining, then contests the cause: the author "believes that the decline in fully validating nodes on the network is largely due to the availability of convenient, attractive, secure, lightweight wallet software and the general trend away from computing on desktop computers to mobile phones and tablets". It then makes the positive case: increased capacity "should enable increased adoption by users and businesses, especially in areas of the world where existing financial infrastructure is weak. That could lead to a more robust network with nodes running in more political jurisdictions" (BIP 101). On mining, the same document argues that bandwidth is one input among many, since "many other factors influence miner profitability, including cost of electricity and labor and real estate", so "increasing the influence of bandwidth in the mining profitability equation will not necessarily lead to more centralization". A network of five thousand nodes in three countries and a network of five thousand nodes in eighty are not equally decentralised, and counting nodes cannot tell them apart.
It was not an unmeasured claim. The position paper above concluded, from propagation measurements, that "given the current overlay network and today's 10 minute average block interval, the block size should not exceed 4MB" if at least ninety percent of nodes are to keep up. Four megabytes is four times the cap that was being defended. The same paper is careful in the other direction too, saying reparameterisation "should be viewed only as a first increment" and that major advances need "a basic rethinking of technical approaches". Both halves are real, and the segwit2x specification later cited exactly this paper for the proposition that a two-megabyte base block "is considered safe by many users, companies, miners and academics" (PCS-2017-0002).
And the procedural point, which turned out to be the strongest one. BIP 109 chose a 75 percent activation threshold rather than 95, and said why: "to minimize the opportunity for a single large mining pool or miner to be able to veto an increase, either because of ideological opposition or threat of violence or extortion." Whatever one thinks of the block size, that sentence identifies a genuine defect in how Bitcoin was changing its rules, and the people who won the war later wrote the same complaint into their own specification. Keep it in mind for the end of this piece.
The opposing case was published just as plainly. Greg Maxwell's capacity roadmap of 7 December 2015 rests on a single trade-off: "If the system is too costly people will be forced to trust third parties rather than independently enforcing the system's rules", and "since Bitcoin is an electronic cash, it isn't a generic database" (bitcoin-dev, 7 December 2015). Both sides claimed decentralisation. They disagreed about which cost destroys it first.
Three implementations, three different bets
Bitcoin XT shipped first. On 15 August 2015 Mike Hearn announced release 0.11A on the bitcoin-dev list, "which includes the bigger blocks patch set", and gave his reason: "The Bitcoin Core project has drifted so far from the principles myself and many others feel are important, that a fork is the only way to fix things" (bitcoin-dev, 15 August 2015). XT carried BIP 101: 8,000,000 bytes from January 2016, doubling every two years until a ceiling of 8,192,000,000 bytes in 2036, activating when 750 of 1,000 consecutive blocks signalled, plus a two-week grace period.
Bitcoin Classic made the smallest possible ask. Its release manager described the reasoning in the project's closing note: "the decision was to go for the lowest possible upgrade from 1 MB to 2 MB. It would avoid any technical complications and would lower the bar so far that we could not logically go any lower. It was the last, best, offer for peace" (Bitcoin Classic, 9 November 2017). The matching specification was Gavin Andresen's BIP 109, a one-time move to 2,000,000 bytes paired with two new limits designed to stop the increase from becoming an attack surface: signature operations counted accurately and capped at 20,000, and at most 1,300,000,000 bytes hashed for signatures per block. Same 750-of-1,000 trigger, a 28-day grace period, and an expiry date of 1 January 2018 after which it was withdrawn. Classic itself moved on before that, shipping what its release notes call a "decentralized block size solution" in version 1.2.0 at the end of 2016 (Bitcoin Classic news).
Bitcoin Unlimited took a different route entirely: remove the number from the software and let operators set it. Its first proposal, by Andrew Stone in November 2015, added an option to change the size of blocks the node mines (default 1,000,000 bytes), an option for the largest block it will accept (default 16MB), and an "excessive block accept depth" (default 4) so that an oversized block is accepted anyway once enough blocks are built on top of it (BUIP001).
That third design is the one worth pausing on, because it is where the two sides were not arguing about a number at all. Under BUIP001 validity depends on each operator's settings and on how deeply a block is buried, so two nodes running the same software with different configuration can disagree about which chain exists, and can then agree again a few blocks later. Supporters called that letting the limit be discovered rather than decreed. Opponents called it making consensus a variable. Both descriptions are of the same mechanism.
Hong Kong, February 2016
On 21 February 2016 a meeting in Hong Kong produced a signed statement, published as the Bitcoin Roundtable Consensus. It is short, and what it says matters more than what it is remembered as.
The signatories agreed that SegWit "continues to be developed actively as a soft-fork and is likely to proceed towards release over the next two months". They agreed to work on "a safe hard-fork based on the improvements in SegWit", and that "the Bitcoin Core contributors present at the Bitcoin Roundtable will have an implementation of such a hard-fork available as a recommendation to Bitcoin Core within three months after the release of SegWit". That hard fork was "expected to include" an increase in non-witness data "to be around 2 MB, with the total size no more than 4 MB", and "will only be adopted with broad support across the entire Bitcoin community". Finally, the signatories agreed to "only run Bitcoin Core-compatible consensus systems" for the foreseeable future. The attached timeline expected SegWit in April 2016, hard fork code by July 2016, and activation "around July 2017" given strong community support.
The list of names is the interesting part. Five signatories are identified as "Bitcoin Core Contributor": Cory Fields, Johnson Lau, Luke Dashjr, Matt Corallo and Peter Todd. The rest are companies: AntPool, BitFury, Bitmain, BTCC, F2Pool, Huobi, OKCoin, Ledger, Blockstream, Bitfinex and others.
Read literally, the document commits five individuals to write and recommend code, and a set of companies not to run alternative consensus rules. It does not, and could not, commit the Bitcoin Core project to merge anything, and it explicitly conditions adoption on broad community support. Whether it should have been read literally is precisely what the following eighteen months were about, and the two sides have never agreed on that. What is not in dispute is the timetable: the release carrying SegWit's activation parameters, Bitcoin Core 0.13.1, was tagged on 27 October 2016, six months after the date in the statement, and no hard fork was adopted.
SegWit was a soft fork, and it did more than add space
SegWit moves signature data into a separate structure that is not covered by the transaction identifier, and replaces the byte limit on blocks with a weight limit of 4,000,000 units, where a base byte counts four and a witness byte counts one (BIP 141). Old nodes see blocks that are still under 1,000,000 bytes by their own accounting, which is what makes it a soft fork rather than a hard one.
Its capacity effect was modest and conditional. Bitcoin Core's 0.13.1 release notes put it as: "Estimates based on the transactions currently found in blocks indicate that if all wallets switch to using segwit, the network will be able to support about 70% more transactions" (release notes, 0.13.1). Maxwell's roadmap had described it as "a 4MB blocksize increase at worst" and "a 2x capacity increase" if widely used. That conditionality was a real objection: raising a hard limit delivers the space whether or not anyone changes their wallet, and SegWit's did not.
The part that mattered longest was not capacity at all. The same release notes claim SegWit "solves all known cases of unwanted transaction malleability", meaning third parties can no longer alter a transaction's identifier after it is signed. BIP 141 spells out why that was worth a consensus change: it "allows creation of unconfirmed transaction dependency chains without counterparty risk, an important feature for offchain protocols such as the Lightning Network". Building a payment channel means signing a refund for a funding transaction that has not confirmed yet. If the funding transaction's identifier can change underneath you, the refund becomes unspendable. That is why Lightning needed SegWit, and it is the clearest case in the whole episode of a soft fork buying something a size increase could not.
New York, May 2017
Fifteen months after Hong Kong, a second agreement was signed at the Consensus conference in New York. A copy was circulated to the bitcoin-dev list on 22 May 2017 by the pseudonymous developer shaolinfry. That copy reads:
We agree to immediately support the following parallel upgrades to the bitcoin protocol, which will be deployed simultaneously and based on the original Segwit2Mb proposal: Activate Segregated Witness at an 80% threshold, signaling at bit 4. Activate a 2 MB hard fork on September 21, 2017.
It names nine companies committing engineering support: Bitcoin.com, BitFury, BitGo, Bitmain, BitPay, Blockchain, Bloq, RSK Labs and Xapo.
Accounts of the second commitment differ, and the difference is worth recording. The circulated copy above dates the hard fork to 21 September 2017. Four days later Tom Zander quoted the published version on the same list as "Activate a 2 MB hard fork within six months" (bitcoin-dev, 26 May 2017). The implementation that was actually built targeted neither date, scheduling the increase for block 494,784 in November (SegWit2x announcement). The working group's charter dates the agreement itself to 21 May 2017 and set a calendar: alpha software by 16 June, nodes signalling from 21 July, "August 23 - SegWit active on network" (segwit2x.github.io).
The technical basis was Lerner's Segwit2Mb, published on bitcoin-dev on 31 March 2017, whose stated aim was disarmingly modest: "The sole objective of this proposal is to re-unite the Bitcoin community and avoid a cryptocurrency split."
BIP 148, BIP 91, and the fortnight it all resolved
While the agreements were being negotiated, a different argument was being made about who gets to trigger a soft fork at all.
On 25 February 2017 shaolinfry posted "Moving towards user activated soft fork activation" to bitcoin-dev, listing four problems with hashrate-based activation. Two of them carried: "miner signalling has a natural veto which allows a small percentage of hashrate to veto node activation of the upgrade for everyone", and, more fundamentally, "soft forks rules are actually always enforced by the nodes, not the miners" (bitcoin-dev, 25 February 2017). That is the same complaint BIP 109 had made about the 95 percent threshold, arriving from the opposite direction.
The result was BIP 148, assigned 12 March 2017: from 1 August 2017 until 15 November, every block must signal for the existing SegWit deployment, and "blocks that do not signal as required will be rejected". Nodes running it would enforce whatever miners did, and would leave the chain if enough miners did not comply.
BIP 91, by James Hilliard and assigned 22 May 2017, defused that. It offered "a way for a simple majority of miners to coordinate activation of the existing segwit deployment with less than 95% hashpower": bit 4, a threshold of 269 blocks out of a 336-block window, which is 80 percent, starting 1 June 2017. Note what it was mechanically. BIP 91 also rejected non-signalling blocks, so it was a mandatory-signalling soft fork of exactly the kind BIP 148 proposed, with miners rather than the calendar pulling the trigger. Its threshold and its version bit are the New York parameters, and the segwit2x specification describes its own deployment as "a modified BIP91" with the signal renamed.
SegWit then locked in on the schedule BIP 9 defines. The retarget period beginning at block 479,808, mined on 9 August 2017, was the first in the LOCKED_IN state, and the new rules became active one period later at block 481,824, mined at 01:57 UTC on 24 August 2017 (mempool.space). The segwit2x working group's own announcement page, written in advance, expected activation "around August 23 2017 (block height 481,824)".
The chains that left
On 1 August 2017, three weeks before SegWit went live, the hard fork that became Bitcoin Cash split off. Its specification set a default activation time of 12:20 UTC that day, required clients to be configured to accept blocks of at least 8,000,000 bytes, and required the first block after the fork to exceed 1,000,000 bytes so that the new chain could never be reorganised back into the old one (UAHF technical specification, version 1.6, 24 July 2017). It also mandated replay protection at the consensus layer, requiring a new hash-type flag and a modified signing algorithm so that a signature valid on one chain would not verify on the other. An earlier version had instead offered an opt-out marker: a transaction consisting of a single OP_RETURN carrying the 46-character string "Bitcoin: A Peer-to-Peer Electronic Cash System" would be rejected on the new chain. The dispute was over the whitepaper's subtitle, and for a few weeks the subtitle was literally the escape hatch.
SegWit2x did not get that far. On 8 November 2017 an email to the segwit2x mailing list, signed by Mike Belshe of BitGo along with Wences Casares of Xapo, Jihan Wu of Bitmain, Jeff Garzik of Bloq, Peter Smith of Blockchain and Erik Voorhees of ShapeShift, suspended it: "Although we strongly believe in the need for a larger blocksize, there is something we believe is even more important: keeping the community together. Unfortunately, it is clear that we have not built sufficient consensus for a clean blocksize upgrade at this time" (Bitcoin Magazine, 10 November 2017). Block 494,784 was mined on 17 November 2017 under the existing rules, like any other block.
Bitcoin Classic announced its own closure the next day.
What it settled
It did not settle that bigger blocks are wrong. Nothing in the outcome refutes BIP 101's argument about jurisdictions, or BIP 109's about the cost of a 95 percent threshold, or the measurement showing four megabytes was within reach of the network of the time. Those arguments were not defeated. They were left unadopted, which is a different thing, and saying so is not a concession.
What it settled was a question about method, and the answer has four parts.
An agreement is not a mechanism. Hong Kong and New York were both signed by parties controlling enormous shares of mining and commerce, and neither changed a consensus rule. Rules change when nodes enforce different code. No quantity of signatures substitutes for that step, and both documents were overtaken by mechanisms: one by a release schedule, the other by BIP 91.
Signalling is readiness, not consent. The version bit says a miner is prepared to enforce a rule. It never said whether the rule was wanted, and treating it as a ballot made a small minority of hashrate into a veto. That defect was real, both sides named it, and it was eventually fixed on the soft fork side: BIP 8 lowered the suggested threshold to 90 percent and added a lock-in-on-timeout flag, recommending it "for any softfork that is expected or found to have political opposition from a non-negligible percent of miners" (BIP 8). Taproot later activated at 90 percent without incident.
The asymmetry is not a value judgement. A soft fork carries unupgraded nodes along; a hard fork does not, so a loosening needs everybody and a tightening does not. That is a property of the rules, not a verdict about which change deserved to win, and it meant the side proposing to loosen the limit always faced the harder deployment. Anyone reading this as vindication should notice that it would have applied identically to a proposal they liked.
Users who run nodes are the last word, and that is expensive. The lesson everybody drew from August 2017 is that miners could not activate SegWit alone and could not stop it either. The part usually left out is what it cost: two years of argument, several forked implementations, two signed agreements that changed no rule, and a resolution that arrived through a deadline set by a pseudonymous developer. It worked. It was not cheap, and nothing guarantees it works twice.
The chain that most people call Bitcoin still has a one-megabyte base block limit. Whether this method can decide anything harder than that is not a settled question either: a soft fork proposal reached its mandatory signalling window in August 2026 and split off its own chain, which is the same argument with the sign reversed. If forks are new, the mechanics are here.