Worked example · 2010-12

Slush Pool — first Bitcoin mining pool launch — Bitcoin — 2010-12-16

Loss: structural — no direct victim loss at launch. Slush Pool's December 2010 launch as the first Bitcoin mining pool established the mining-pool architecture that, over the subsequent 15 years, became the dominant source of Bitcoin hashrate centralization risk. By the OAK v0.1 cutoff, the top three mining pools controlled approximately 65%+ of Bitcoin's total hashrate, and the mining-pool centralization trend that began with Slush Pool in December 2010 constituted the single most persistent structural risk to Bitcoin's censorship-resistance and Nakamoto-consensus security model.
OAK Techniques observed: OAK-T14.001 (Mining-Pool / Validator-Set Centralization Risk — Slush Pool's architecture established the template for pooled mining: individual miners contribute hashrate to a pool operator who constructs block templates, distributes work units, and collects/redistributes block rewards. The pool operator's control over block-template construction introduces a centralization vector — the operator decides which transactions to include, exclude, or reorder — that scales with the pool's hashrate share. The Slush Pool launch is the chronological origin of this structural risk. At v0.1, T14.001 covers MEV extraction and validator concentration; the Slush Pool case extends the T14.001 framing backward to the mining-pool centralization origin point). OAK-T14 (broadly — Miner-Influence / Consensus-Layer Attack Surface — the mining-pool architecture Slush Pool established is the substrate on which all subsequent T14-class attacks — block-reordering MEV, transaction-censorship attacks, hashrate-rental 51% attacks — operate).
Attribution: unattributed Slush Pool was launched by Marek "Slush" Palatinus as a legitimate service. The operator-side risk the architecture introduced — pool-operator transaction-censorship capability — was an unintended structural consequence of the pooled-mining design, not a malicious operator action. No attribution is relevant.
Key teaching point: The Slush Pool launch (December 2010) established the mining-pool architecture whose structural centralization risk — pool-operator control over block-template construction — became the dominant hashrate-centralization concern in proof-of-work blockchain security over the subsequent 15 years. The architecture solved an immediate user problem: individual (solo) miners faced extreme variance in block-reward income, and pooled mining smoothed that variance by distributing rewards proportionally across many participants. The structural trade — income-smoothing in exchange for pool-operator control over block-template construction — was understood by protocol designers but widely accepted because the alternative (persistent solo-mining variance) made individual mining economically unviable as difficulty increased. The Slush Pool architecture is the canonical example in Bitcoin's history of a legitimate service whose design introduced a structural centralization risk that scaled with the service's success.

Summary

On December 16, 2010, Marek "Slush" Palatinus launched Slush Pool (originally "Bitcoin Pooled Mining" or "BPM") — the first Bitcoin mining pool. The pool's architecture was straightforward: miners connected to the pool server, received work units (partial-hash targets easier than the network target), submitted shares proving they had performed work, and received block-reward distributions proportional to their submitted shares when the pool mined a block.

The pooled-mining architecture solved a genuine and pressing user problem. As Bitcoin's network hashrate increased through 2010 — from CPU mining (2009) through early GPU mining (mid-2010) — individual miners faced increasingly extreme variance in block-reward timing. A solo miner with 1% of network hashrate could expect a block roughly every 100 blocks (~16.7 hours at 10-minute block intervals), but actual arrival times followed a Poisson distribution: a miner could go days or weeks without a block and then find two in an hour. Pooled mining smoothed this variance — participants received small, frequent payouts proportional to their contributed work — and made mining income predictable enough to be economically viable for individual participants.

The structural trade was immediate and understood at the time: the pool operator constructs block templates and selects which transactions to include. In a decentralized solo-mining model, each miner independently decides which transactions to include in their candidate blocks. In a pooled-mining model, the pool operator makes that decision for all pool participants. As a pool's hashrate share grows, the operator's transaction-selection power scales proportionally — a pool with 51% of hashrate can, in principle, censor any transaction, reorganize the chain, or extract value through transaction-ordering manipulation.

At Slush Pool's launch in December 2010, the pool's hashrate share was small and the centralization risk was theoretical. By the OAK v0.1 cutoff, approximately 65%+ of Bitcoin's total hashrate was concentrated in the top three mining pools, and the theoretical centralization risk Slush Pool's architecture introduced had become the dominant structural concern in Bitcoin security discourse. The architecture Slush established — pool operator as block-template constructor, miners as blind-hash contributors — became the universal mining-pool design across all proof-of-work blockchains.

Timeline (UTC unless noted)

When	Event	OAK ref
2010-09	First GPU Bitcoin miner released; GPU mining begins to dominate CPU mining, increasing network hashrate and individual-miner variance	(precursor — hashrate increase creates demand for variance-smoothing)
2010-11-27	Marek "Slush" Palatinus proposes the pooled-mining concept on BitcoinTalk: "Bitcoin Pooled Mining"	(design publication — pooled-mining proposal)
2010-12-16	Slush Pool launches as the first operational Bitcoin mining pool; miners begin contributing hashrate to the pool and receiving proportional payouts	T14.001 (mining-pool centralization — architecture origin)
2010-12 → 2011-06	Slush Pool's hashrate grows; other mining pools launch (DeepBit, BTC Guild), establishing the pooled-mining model as the dominant mining architecture	T14.001 (pool proliferation — centralization surface expands)
2011 → 2014	Mining-pool hashrate concentration increases; top-3 pool concentration becomes a recognized security concern in Bitcoin protocol discourse	T14 (miner-influence surface — hashrate-concentration risk recognized)
2013-04	BTC Guild becomes the first mining pool to exceed 40% of network hashrate; the "51% attack via single-pool dominance" threat becomes a concrete concern	T14.002 (pool-level majority-hashrate risk)
2014-06	Ghash.io temporarily exceeds 50% of Bitcoin hashrate; the community discusses emergency responses (temporary pool-hashrate reduction, miner redistribution); Ghash.io voluntarily reduces its hashrate	T14.002 (51% hashrate threshold crossed — voluntary mitigation)
2015 → 2025	Bitcoin mining-pool hashrate concentration stabilizes at 50–70% top-3; mining-pool centralization becomes a permanent feature of the Bitcoin security model	T14.001 (structural centralization — permanent risk surface)
Continuing	The Slush Pool architecture — pool operator controls block-template construction, miners contribute blind hash — remains the universal mining-pool design across all PoW chains through the OAK v0.1 cutoff	(architectural permanence — the Slush design is universal)

Realised extraction

No direct victim loss at launch. The structural consequence — hashrate centralization via pool-operator control of block-template construction — is a persistent protocol-level risk that scales with pool concentration. The risk is probabilistic and structural, not a discrete extraction event.

What defenders observed

Pre-event: Bitcoin mining before Slush Pool was solo-mining only. Solo miners had full control over their block templates — each miner independently decided which transactions to include — but faced extreme income variance. The defender trade was already visible before Slush Pool's launch: income predictability (pooled mining) vs. decentralized block-template construction (solo mining).
At-event: Slush Pool's launch was widely welcomed by the mining community as a practical solution to income variance. The centralization concern was noted by protocol designers at the time but was widely considered a manageable future concern — the pool's hashrate share was small, and the 51% attack was considered a theoretical threat rather than a near-term operational risk.
Post-event (long-tail): the mining-pool centralization trajectory that Slush Pool initiated — from 0% pooled hashrate in 2010 to 65%+ top-3 pool concentration by 2025 — validated the early centralization warnings. The structural risk Slush Pool's architecture introduced — pool-operator control over block-template construction — proved to be the most persistent and consequential security concern in Bitcoin's design space over the subsequent 15 years. Defenders learned that architectural centralization vectors introduced at the service-design layer (pooling) can become protocol-level security concerns as the service's adoption scales.

What this example tells contributors writing future Technique pages

Slush Pool is the chronological origin anchor for T14.001 mining-pool centralization risk. Every subsequent T14.001 sub-pattern — pool-operator transaction censorship, hashrate-rental 51% attacks, block-reordering MEV extraction at the mining-pool layer — operates on the architectural substrate that Slush Pool established in December 2010. Contributors writing T14.001 historical framing should treat Slush Pool as the chronological anchor.
The pooled-mining architecture is a "legitimate service with structural centralization risk" class. This class — a service that solves a genuine user problem while introducing a structural risk that scales with adoption — recurs across blockchain infrastructure (liquid staking, restaking, bridge relayers, MEV-Boost relays). Contributors writing infrastructure-risk classification should treat Slush Pool as the foundational example of this class.
The December 2010 launch date anchors the T14 surface chronologically. The T14 Tactic (Miner-Influence / Consensus-Layer Attacks) is often framed around post-2020 MEV extraction, but the structural substrate — pool-operator control over transaction inclusion — was established in December 2010. Contributors writing T14 historical scope should preserve the 2010 origin point.

Public references

See citations in corresponding technique file.

Discussion

The Slush Pool launch (December 2010) is the chronological origin anchor for the mining-pool centralization risk surface that OAK's T14 Tactic covers. The event established the architectural template — pool operator controls block-template construction, miners contribute blind hash — that became the universal mining-pool design across all proof-of-work blockchains and the substrate for all subsequent miner-influence attacks (censorship, reordering, hashrate-rental 51% attacks).

The case is structurally distinct from most OAK examples in that it is a service-launch event rather than a compromise or exploitation event. The "loss" is structural (hashrate centralization risk scaling with pool adoption) rather than discrete (stolen funds). The case is documented in OAK because the structural risk it established is the load-bearing security concern in proof-of-work blockchain design — a concern whose operational significance has only increased over the 15 years since Slush Pool's launch as mining-pool hashrate concentration has reached levels (65%+ top-3) that would have been considered alarming in 2010.

For OAK's year-coverage strengthening, the Slush Pool launch provides a fourth 2010 anchor and demonstrates that the T14 mining-influence surface — often framed as a post-2020 MEV phenomenon — has its structural origin in December 2010, predating Ethereum's existence by nearly five years.