Fork Wars

When Bitcoin v0.1 began connecting peers in January 2009, a block was just another message on the wire. In main.h of that release, Satoshi defined MAX_SIZE = 0x02000000 — 33,554,432 bytes, or 32 mebibytes. The same constant is used when a block is accepted: if the serialized block is larger than MAX_SIZE, it is rejected. There is no second, tighter cap. A miner building a block in that client kept going while (fFoundSomething && nBlockSize < MAX_SIZE/2), so the generate path would have stopped around 16 MiB, still far above anything the network actually produced.

That 32 MiB figure is not a “block size policy” in the later sense. It is the maximum size of a protocol message, applied also to blocks because a block arrived as a message. Contemporary writers, including the Bitcoin Wiki's note on weight units, describe this as an implicit maximum of 32 MiB. No block in 2009 or early 2010 came anywhere close. Average size in 2009, from the Blockchain.com series used in the chart above, was about 0.0002 MB.

The interesting design tension is already visible in Satoshi's mail, even before anyone is arguing about a megabyte. On 12 April 2009 he told Mike Hearn that Visa-scale volume was already within reach of “existing hardware,” and that the system “never really hits a scale ceiling.” On 3 May 2009 he sent Martti Malmi similar arithmetic: 15 million transactions a day, at 1 KB each, would be “15GB of bandwidth for each block generating node per day, or about two DVD movies worth.” In the same letter he offered “100,000 block generating nodes” as a large-scale ballpark, with “millions of SPV clients.” Those sentences are quoted in the essay below. They do not set a block size. They show that Satoshi was already thinking about a network in which most users would not carry the full chain, and in which hardware improvement was part of the scaling story.

A quieter number also appears in the Malmi correspondence. On 4 December 2009 Satoshi described free-transaction policy: “free transactions until the block size is over 200K, with priority given to smaller transactions.” That 200 KB is not a consensus limit. It is a policy area inside a block, reserved for zero-fee transactions, and he asked Malmi not to talk about the fee machinery in public because “it's there for flood control.” The later 1 MB constant, the 500 KB generate cap, and this 200 KB free area are three different knobs. Conflating them is one reason the early history gets told backwards.

Through mid-2010 the chain is still tiny, fees are still mostly theoretical, and the only hard size bound in the protocol is that 32 MiB message cap. The next commits will shrink what a valid block can be, not enlarge it.

On Thursday, 15 July 2010, at 00:18:45, Satoshi committed static const unsigned int MAX_BLOCK_SIZE = 1000000; to the tree. The commit is a30b56e. Four days later, on 19 July, the constant shipped in version 0.3.1 rc1 (9d2174b). The miner in that release would skip a transaction once nBlockSize + nTxSize >= MAX_BLOCK_SIZE - 10000, so new blocks created by the reference client stayed under about 990 KB. Official changelogs later start at v0.3.12 and do not discuss the addition. That is the sense in which the cap was introduced quietly.

A mining policy is not yet a consensus rule. The consensus step came on 7 September 2010, in commit 8c9479c (SVN r148, released with v0.3.12). Buried in a commit message that only says “cleanup, catch some recoverable exceptions and continue,” Satoshi added, in CBlock::AcceptBlock():

if (nHeight > 79400 && ::GetSerializeSize(*this, SER_NETWORK) > MAX_BLOCK_SIZE)
    return error("AcceptBlock() : over size limit");

Block 79,400 was mined on 12 September 2010. From the next block, nodes running this code would reject a block larger than 1,000,000 bytes. A matching sigops cap was gated on the same height. Then, on 19 September 2010 (some later summaries say 20 September; the commit date is the 19th), Satoshi removed the height gate in commit 172f006 but kept the 1 MB check. After that, the rule no longer mentioned 79,400. It was simply the size limit.

Alongside the hard cap sat a softer one, already visible in the October 2010 source Garzik would patch: MAX_BLOCK_SIZE_GEN = MAX_BLOCK_SIZE/2, or 500 KB. That is the figure Mike Hearn asked about at the end of 2010, “the 500kb limit on block sizes.” It was the size the official client would produce, not the size it would eventually be willing to accept. Satoshi's answer, on 29 December 2010, is in the essay: a higher limit “can be phased in once we have actual use closer to the limit.” Neither the July commit nor the September commit explains, in its message, why 1,000,000 bytes was the number. The careful height gate does suggest he did not treat it as an emergency fork.

One more hidden constraint would matter later. Until 2013, the Berkeley DB lock limit of 10,000 effectively kept many blocks well below 1 MB (on the order of 500–750 KB of serialized data). When Bitcoin 0.8 replaced BDB with LevelDB in March 2013, that accidental cap disappeared and a short chainsplit followed. The 1 MB rule was then, for the first time, the binding consensus limit in practice as well as on paper.

On 3 October 2010, Jeff Garzik opened a Bitcointalk thread titled “[PATCH] increase block size limit.” He wanted the network to be able to “at least match Paypal's average transaction rate,” and he pasted a patch against main.h:

static const unsigned int TX_PER_MINUTE = 1400;
static const unsigned int TX_AVG_SIZE_GUESS = 256;
static const unsigned int MAX_BLOCK_SIZE =
 TX_PER_MINUTE * TX_AVG_SIZE_GUESS * 10 * 2;

That product is 7,168,000 bytes — a little over 7 MB — replacing the 1,000,000-byte constant that was then two and a half months old. MAX_BLOCK_SIZE_GEN would have remained half of the new cap. Garzik also posted a link to the patch file itself. Theymos replied the same evening that applying it would make a node “incompatible with other Bitcoin clients.”

Satoshi's first reply is at 21:07:28 UTC on 3 October, message 15139. It is short, and it is worth reading in full:

“+1 theymos. 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.”

The next day, after Garzik and others had argued about whether an incompatible change could still be “phased in,” Satoshi came back at 19:48:40 UTC on 4 October, message 15366, and sketched the mechanism:

“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. When we're near the cutoff block number, I can put an alert to old versions to make sure they know they have to upgrade.”

Two things are worth keeping in their original proportions. Satoshi is not endorsing a 7 MB cap, and he is not ruling one out forever. He is rejecting an immediate, uncoordinated patch that would fork a node off the network, and he is describing a flag-day style hard fork, announced early, with an alert to stragglers. Block 115,000 would have arrived only a couple of months later; he offers it as an illustration (“or some later time” is the spirit of the 3 October note: “if we get closer to needing it”). At the time, blocks were still tiny. The argument would be repeated, with far higher stakes, in 2015.

Satoshi Dice was announced on Bitcointalk on 24 April 2012 by Erik Voorhees, who had acquired a short-lived betting script and put it at satoshidice.com. A player sent bitcoin to a payout-specific address; a transaction came back with a win or a dust refund. Each wager was one or two ordinary Bitcoin payments. Within weeks the service was responsible for more transactions than the rest of the network combined. Forum statistics compiled that summer attributed more than half of all transactions, and a large share of new blockchain bytes, to the game. An Ars Technica report the following year, citing Lightspeed's Jeremy Liew, still put SatoshiDice in a 25–50 percent range of transaction count in June 2013.

The complaints were about spam, about “useless” data, and about a betting service crowding out payments. Fees themselves remained small in dollar terms, because bitcoin's price and the typical fee rate were still low. A house fee of 0.0005 BTC per wager was a business model, not yet a mempool auction. But average block size in the Blockchain.com series jumps from about 0.02 MB at the start of 2012 to more than 0.10 MB by December — the first time the chain's growth is obviously driven by a single application. Voorhees sold the brand in July 2013.

Metaprotocols arrived next. J.R. Willett's Mastercoin (later Omni) raised bitcoin in a 2013 crowdsale, often called the first ICO, and began writing extra protocol data into Bitcoin transactions. In January 2014, Counterparty launched by having users burn bitcoin for XCP, and built a decentralized exchange and asset layer on top of the same chain. Mastercoin and Counterparty did not fill blocks the way Satoshi Dice had, but they forced a design argument that the next phase will treat in detail: is Bitcoin a settlement rail that may carry foreign data, or a payments system that should discourage it? Tether would later be issued on Omni. Rare Pepes and other early “tokens on Bitcoin” lived on Counterparty. Both facts matter for later chapters, including inscriptions, that look new only if this decade is forgotten.

By the end of 2013, average blocks were still well under the 1 MB cap (about 0.18 MB in December), and the forgotten Berkeley DB lock limit still clipped what some miners could pack. The pressure was cultural as much as technical: a popular app had shown that “anyone may use the chain” includes uses some Bitcoiners did not like, and two metaprotocols were about to collide with a policy fight over OP_RETURN.

Metaprotocols needed a place to put data. Some early schemes stuffed it into fake, unspendable outputs, which bloated the UTXO set forever. OP_RETURN offered a provably prunable alternative: a single output that is invalid to spend, and that a node may drop from its UTXO database. Making that output standard — meaning default nodes would relay and mine it — was the fight.

In October 2013, work landed on Bitcoin Core's master branch to relay OP_RETURN outputs with an 80-byte payload, enough for a SHA-256 or SHA-512 hash plus a short tag. There was no release at 80 bytes. In February 2014, as 0.9 approached, Jeff Garzik opened PR #3737 to cut the standard relay limit to 40 bytes, and explained the controversy on the bitcoin-development mailing list. The 80-byte figure, he wrote, had been chosen as “2x SHA256 or 1x SHA512, plus some tiny bit of metadata.” It was not, he insisted, “an endorsement of data storage in chain as a good idea.” It was “a way to make data /less damaging/.” Mastercoin and others, he said, were already doing worse things to the UTXO set. The pull request merged on 26 February 2014. Bitcoin Core 0.9.0, in March, shipped the 40-byte standardness rule, with a release note that “this change is not an endorsement of storing data in the blockchain.”

For anyone developing against unreleased master, the limit had gone down, from 80 to 40. For anyone running only tagged releases, 0.9.0 was the first time OP_RETURN was standard at all, and it was 40 bytes from day one. Both statements are true; they describe different upgrade paths. Counterparty and similar protocols that wanted more than 40 bytes often kept using multisignature encoding, which is harsher on the UTXO set — the opposite of what the prunable output was for.

On 15 November 2014, Flavien Charlon opened PR #5286 to restore 80 bytes, arguing that nine months of 40-byte policy had produced “nothing catastrophic.” The change merged on 3 February 2015 and shipped in Bitcoin Core 0.11.0 in July 2015. Version 0.12.0, in February 2016, nudged the default to 83 bytes. None of this is a consensus rule. It is mempool and relay policy. A miner can include a larger OP_RETURN today, as in 2014; other nodes will still accept the block. The heat in the “war” was about defaults, about whether Core was blessing data storage, and about who got to set the default.

The same argument returns, almost word for word, in 2023–2026, after inscriptions and after Bitcoin Core 30 changes the default datacarrier policy again. That reprise belongs in Aug 2017–2026. The 2014 numbers were bytes, not kilobytes.

By mid-2015, average blocks were filling toward the cap (about 0.46 MB in August, 0.65 MB by December, in the monthly series). The argument was no longer hypothetical. On 22 June 2015, Gavin Andresen published BIP 101: a hard fork that would raise the maximum block size to 8 MB and then double it every two years, until a ceiling of 8,192 MB in 2036. The schedule was an explicit bet on hardware, in the spirit of the Moore's Law remarks Satoshi had made in 2009 — and, immediately, a political document.

Bitcoin XT, a fork of the reference client maintained most visibly by Mike Hearn, adopted BIP 101. (XT had existed earlier as a vehicle for other patches; BIP 101 is what made it the first wartime client.) Hash-power and node counts were treated as a referendum. They never reached a clean activation. Operators who announced XT support reported denial-of-service attacks. Hearn, who had been corresponding with Satoshi since 2009 and had written the first widely used Java SPV library, published “The resolution of the Bitcoin experiment” on 14 January 2016 and walked away, saying the project had failed. The essay is a primary source for his camp's mood at the moment XT stalled; it is not a proof that the project had failed, and the price history after 2016 is often thrown back at it. Both the text and the afterlife belong in the record.

BIP 101 was only one of several 2015 proposals, collected in Jan 2016–May 2017. It was the one that turned a mailing-list disagreement into a client war: if you wanted the 8 MB schedule, you ran a different binary, and if you did not, you treated that binary as an attack on consensus. After Hearn's departure, XT continued in other hands but lost momentum. Bitcoin Classic and Bitcoin Unlimited inherited the large-block side of the argument.

Scaling Bitcoin was conceived as a place for proposals, measurements and requirements, without exhibition booths. Montreal, in September 2015, gathered the engineering and research community while BIP 101 and XT were already in the news. Hong Kong, in December, was sited to be easier for Chinese miners to attend and was billed as a venue for comparing concrete proposals. Wuille's SegWit talk is the technical origin of the path that would, eventually, activate on Bitcoin in August 2017. Jeff Garzik, Peter Todd, Adam Back and a mining panel (BitFury, Bitmain, F2Pool, BW, Avalon, KnCMiner, FinalHash among those named in contemporary write-ups) were also on the programme.

What the workshop did not do is settle the political question. That is why a second meeting was convened in February. The published “Bitcoin Roundtable Consensus” statement, dated 21 February 2016, was signed by mining-pool executives the authors said represented more than 80 percent of recent hash power — AntPool, A-XBT, BitFury, Bitmain, BTCC, F2Pool, Genesis Mining, GHash.io — and by five Bitcoin Core contributors present in the room: Cory Fields, Johnson Lau, Luke Dashjr, Matt Corallo and Peter Todd. The text is specific, and it is worth reading as a bargain rather than as a prophecy:

SegWit would continue as a soft fork, “likely to proceed towards release over the next two months.” Core contributors at the table would have a hard-fork implementation “available as a recommendation to Bitcoin Core within three months after the release of SegWit,” expected to raise non-witness data “to be around 2 MB, with the total size no more than 4 MB,” and “only be adopted with broad support across the entire Bitcoin community.” The implied calendar in the post was SegWit around April 2016, hard-fork code around July 2016, and, “if there is strong community support,” activation around July 2017. Signers said they would “only run Bitcoin Core-compatible consensus systems” for the foreseeable future.

Almost none of that calendar held. SegWit did not ship in April 2016. The hard-fork recommendation contemplated in the statement did not become a Bitcoin Core release. By the time a 2 MB-style hard fork reappeared, it was under a different name, with a different coalition, as SegWit2x. Several of the Core contributors who had been in the room became critics of that later deal. The Hong Kong statement remains important as a primary source: it shows that, in February 2016, a group of large miners and some Core developers were publicly willing to pair SegWit with a later capacity hard fork. It does not show that “the community” had agreed, and it should not be cited as if it were the December workshop's official output.

BIP 101 was the loudest 2015 proposal. It was not the only one, and treating the war as “8 MB versus 1 MB” erases a spread of designs that later guests on this show still mix up — including, on one tape, BIP 102 and BIP 103. The documents themselves are short and specific.

BIP 100, from Jeff Garzik, let miners vote the cap up or down within a bound (the usual telling is 1–32 MB). BIP 102, also Garzik, was the modest one: a one-time hard fork from 1 MB to 2 MB. BIP 103, from Pieter Wuille, was the “nerdiest,” as Vlad later called it on air: a scheduled increase of 17.7 percent per year, aligned with a rough reading of Moore's Law, via a hard fork every 97 difficulty intervals. BIP 103 is the text to cite when someone claims that Core developers never contemplated a larger block; it is also a text that was not adopted, and Wuille became the lead designer of SegWit instead.

After XT stalled, Bitcoin Classic launched in January 2016 around a 2 MB bump, formalized as BIP 109. It attracted a burst of nodes and some hash power, then faded as the fight moved on. Bitcoin Unlimited, associated with Andrew Stone, Peter Rizun and others, rejected a fixed scheduled cap in favour of “emergent consensus”: miners set an Excessive Block size (EB) and an Acceptance Depth (AD), and the network was supposed to converge on a working limit without a flag-day hard fork. Unlimited became, for a time, the large-block client with the most mining-pool interest, and it later fed into Bitcoin Cash culture even though Bitcoin Cash itself launched from Bitcoin ABC.

Other names belong in the same menagerie. Adam Back discussed a 2-4-8 roadmap. Extension blocks and various “short-term 2 MB, long-term SegWit” hybrids were drafted and discarded. By early 2017 the client map was messy: Bitcoin Core with SegWit still unactivated, Classic diminished, Unlimited campaigning, and a growing camp that wanted a user-activated soft fork rather than another miner vote. No proposal in this phase became the chain's consensus rule. Their importance is documentary: they show how many people, including some who later opposed a hard fork, once put a number on a larger block.

Segregated Witness, presented by Pieter Wuille at Scaling Bitcoin Hong Kong, was specified as BIP 141 (with 141–143 and related BIPs). It moved signature data into a witness field that is covered by a new commitment in the coinbase, fixing transaction malleability for SegWit inputs, enabling cleaner layer-two protocols, and redefining block capacity in weight units: a 4 million-weight cap that discounts witness bytes, so a block of mostly SegWit transactions can serialize above 1 MB (theoretically up to nearly 4 MB in an all-witness limit case). It was designed as a soft fork: old nodes would still see valid blocks, they would just not fully understand the new rules.

Activation was supposed to be orderly. BIP 9 version-bits signalling let miners show support in a retarget window; SegWit needed a 95 percent threshold. Through 2016 and into 2017 the threshold was not met. Some large miners, notably in the Bitmain orbit, were accused of obstruction — including the “ASICBoost” controversy, in which covert optimization was alleged to interact badly with SegWit. Those allegations were denied and remain disputed; they are part of the political atmosphere, not a settled technical finding of this page.

In March 2017, a proposal circulated as BIP 148, a user-activated soft fork (UASF) associated with the pseudonym Shaolinfry. From 1 August 2017, BIP 148 nodes would reject blocks that did not signal for SegWit. The idea was that economic nodes, not miners, could force the issue — and risk a chainsplit if a minority of hash power followed them. “UASF” hats and Bitfinex contracts made it a public campaign.

A miner-friendly compromise arrived as BIP 91, by James Hilliard, using a much lower threshold (269 of 336 blocks, 80 percent) to lock in a requirement that later blocks signal BIP 141. BIP 91 locked in on 21 July 2017 and activated on 26 July. Once miners were already signalling, the original BIP 9 SegWit threshold could finally be met. SegWit locked in on 9 August 2017 at block 479,808 and activated on 24 August at block 481,824 — after, not before, the Bitcoin Cash split. The next two phases cover those August days in order.

On 23 May 2017, during Consensus in New York, Digital Currency Group published a letter later called the New York Agreement. Companies and mining pools — Coinbase, BitPay, Bitmain, ViaBTC, Xapo, ShapeShift, Gavin Andresen as a named individual, and dozens of others listed in the letter — endorsed a path: activate SegWit at an 80 percent bit-4 signalling threshold, then a hard fork to a 2 MB base-block within six months. The client work lived in the btc1 repository, with Jeff Garzik among the visible engineers. The bundle was marketed as SegWit2x.

In one reading, NYA was the Hong Kong bargain revived with more corporate letterhead and a lower SegWit threshold. In another, it was a closed-room attempt to set consensus by CEO. Many users and Core contributors who had accepted SegWit as a soft fork rejected the mandatory 2x hard fork, especially once it became clear that replay protection on the 2x side was contentious. BIP 91, not the NYA letter itself, is what actually moved miners to SegWit signalling in July. SegWit then activated on the original chain in August without waiting for 2x.

The “2” in SegWit2x was also not a simple 2 MB total. The plan was to raise the base block size to 2 MB while leaving the SegWit weight discount in place, so a full block could serialize well beyond 2 MB. Opponents treated that as a much larger, poorly specified capacity jump. A second technical fight, just as bitter, was over replay protection: without it, a transaction broadcast on one post-fork chain could be valid on the other, and users who did not want a split would still be exposed to one. Several businesses that had signed the New York letter later baulked at shipping that hard fork.

The 2x hard fork was aimed at around 16 November 2017 (block 494,784 is the figure usually given). On 8 November, a group of SegWit2x supporters announced that the fork was cancelled “for the time being due to a lack of consensus.” There was no second UTXO split of Bitcoin in November. Some people who had been waiting for 2x moved attention, and in some cases coins and development, to Bitcoin Cash, which had already existed for three months. Vinny Lingham, on this show, later called the miner side of the SegWit-then-2x sequence a hoodwink; that is one participant's memory, offered below, not a finding.

At 12:20 UTC on 1 August 2017, Bitcoin ABC nodes — led at the time by Amaury Séchet — enforced a new set of rules starting after block 478,558. Block 478,559 is the first Bitcoin Cash block. The new chain raised the block size to 8 MB, changed the signature hashing algorithm (a hard-fork fix for quadratic hashing and a form of third-party malleability, related in spirit to what SegWit did as a soft fork), and added replay protection so that transactions would not be valid on both chains. Emergency difficulty adjustment (EDA) was included because the new chain expected a minority of hash power; that algorithm would cause wild swings in block times until it was replaced in November.

The split is a true UTXO fork: anyone who held bitcoin at the last common block held equal coins on both ledgers. It is not “Bitcoin becoming Bitcoin Cash,” and it is not a rename. It is one chain becoming two. Many large-block advocates moved their ongoing on-chain-cash argument to BCH; others stayed to wait for SegWit2x; some did both. Roger Ver, Jihan Wu / Bitmain, and ViaBTC were among the most visible early backers. Bitcoin.com, under Ver, would become a BCH-leaning brand in a way that still generates naming fights years later.

On the original chain, BIP 148's flag day had arrived with the same date, but BIP 91 had already aligned miners, and a chaotic UASF split was avoided. SegWit then locked in (9 August, block 479,808) and activated (24 August, block 481,824). Lightning development could now target a malleability-stable output type on Bitcoin. Fees, meanwhile, were already rising: the monthly series shows average daily fees climbing from hundreds of thousands of dollars in the spring to more than a million in June and August, then to a blow-off in December. The war's political climax and the market's fee climax are close in time, not identical.