A Short, Readable History of Pool & Solo Mining

Setting the scene

If you’re new to Bitcoin hobby mining today, everything looks clean and obvious: point a Bitaxe at a pool URL, open a dashboard, watch shares roll in. Back when I came into the space — late 2014 — everything felt different.

The community lived on Bitcointalk. Code lived in long threads. Arguments, breakthroughs, bug fixes, trust relationships — all of it happened out in the open. It reminded me of very early Bugtraq mixed with EFnet IRC fights and just enough brilliance to keep the whole thing from collapsing.

And although I wasn’t around for the earliest era, you couldn’t be active in 2014 without absorbing the history that got us there.

What follows isn’t an argument for any particular mining setup — it’s simply the history as I lived it, learned it, and watched it evolve. I’m not trying to influence how anyone mines; that’s a decision every hobbyist should make for themselves based on their own priorities, whether that’s full sovereignty, ease of use, experimentation, or something in between.

People coming into the hobby for the first time still need a starting point, though. I point newcomers toward solo.ckpool.org because of the history outlined below — a simple, durable place to begin. Once someone is established, I fully expect they’ll explore other options, try containers, run nodes, experiment with different architectures, and eventually settle on whatever works best for their setup and their goals.

The very beginning — solo or nothing

In Bitcoin’s earliest days, mining literally started inside the Bitcoin client itself. There was a simple UI checkbox — “Generate Coins” — and your CPU did the rest.

I wasn’t there for that era, but you’d still hear veterans tell stories about it on Bitcointalk. It was a completely different universe.

The built-in miner worked, but it was basic — no tuning, no real visibility, and no way to push performance. As people began experimenting and wanting more control, the first dedicated mining tools appeared.

cpuminer — the first real tool

Created by: Jeff Garzik

Before specialized hardware and before the modern ecosystem, there was cpuminer.

It was simple, command-line, accessible, and you could aim it at:

• your own local bitcoind
• early pooled services once they emerged

It proved the concept: mining could happen outside the original Bitcoin client, and external tools could meaningfully contribute to the network.

Slush Pool — the first breakthrough in pooled mining

Created by: Marek Palatinus (Slush), originally mining.bitcoin.cz

Before anyone could imagine today’s global mining operations, one person made a simple but revolutionary leap: What if miners didn’t have to compete alone?

Around late 2010, Slush launched the first Bitcoin mining pool — Slush Pool. More miners were joining, GPU mining was just starting to take off, and CPU miners were going long stretches without seeing a reward.

His idea fundamentally changed everything:

• miners combined hashrate
• work was distributed
• payouts were shared proportionally

It sounds obvious now, but back then it was groundbreaking.

Slush introduced concepts still used today:

• share difficulty
• share validation
• predictable reward systems (precursors to PPS, PPLNS, etc.)
• centralized work coordination so miners could submit partial proofs efficiently

It turned mining from a lottery into something reliable.

cgminer — a tool that defined multiple eras

Created by: Con Kolivas (CK)

cgminer became the tool nearly everyone used through the hardware transition era.

It supported:

• GPUs
• FPGAs
• the early waves of ASIC hardware

cgminer wasn’t pool software — it ran on your mining hardware. But its stratum behavior, drivers, workload handling, monitoring, and tuning philosophies shaped how miners and pools interacted for years.

Even Bitmain’s first Antminer models shipped with cgminer-derived software — a fork built directly on CK’s codebase. For a time, cgminer wasn’t just the community standard; it was the industry standard.

How I entered the scene (late 2014)

By the time I arrived in late 2014, ASICs were firmly in control.

I found my way onto Bitcointalk, bought my first miner, and fell straight down the same rabbit hole everyone hits:

You start with one device. Then another. Then another “just to validate my ROI math.” Before long you’ve turned part of your home into a mini datacenter.

My real hardware lineup eventually included:

• Spondoolies SP35
• Spondoolies SP20E
• Bitmain S5s
• Bitmain C1 w/ cooling kit
• Bitcrane T110-S units
• Bitmain S4
• an early Bitmain S9

I didn’t run a polished operation — I ran a garage.

It became a roaring, overheated chamber — half sauna, half airport runway. Some guys had man caves with sports memorabilia. I had bread racks, floor-scattered miners, ziptied cables everywhere, my central A/C hacked into the garage, and a garage door permanently cracked open in winter just to manage the heat. Beautiful chaos.

CK’s pool code — the engine behind CKPool

Created by: Con Kolivas (CK)

This is the part newer miners tend to misunderstand.

Today, people hear “CKPool” and think only of the pooled-solo endpoint. But behind that URL is a lean pool engine CK built and refined over years of real traffic and real miners.

CK’s pool code (ckpool + libckpool) showed what an efficient Bitcoin pool could look like without a massive corporate footprint. It was a focused codebase and an operational model for running a minimal-trust pool in the real world. You can still see echoes of that philosophy in how modern solo setups and lightweight pools are designed today.

Over time, CK also evolved how that code was actually run in production — tightening the architecture, tuning performance, and hardening infrastructure as hardware changed and hashrate moved around. The long-lived core is ckpool and libckpool — the same codebase that powers the solo.ckpool.org deployment.

CK and Slush — at completely different moments and for completely different reasons — helped shape the future of Bitcoin mining long before anyone realized how significant their contributions would become.

solo.ckpool.org — solo mining without running the stack

The arrival of solo.ckpool.org changed everything for solo miners.

If CK’s pool code was the engine, solo.ckpool.org was the on-ramp that made it accessible. For the first time, you could solo-mine without:

• running your own node
• maintaining a mempool
• managing block templates
• hosting your own stratum server
• keeping infrastructure online 24/7

If you found the block, you got the full reward (minus a small fee).

It preserved the purity of solo mining while removing the operational burden — and for hobbyists and even some very large farms, that combination was magic.

The culture of Bitcointalk (2014–2016)

Back then, everything happened on Bitcointalk:

• firmware
• hardware sales
• escrow
• drama
• testing
• arguments
• voltage tables
• code discussions

It was messy, brilliant, exhausting, funny, chaotic, and collaborative. If you lived through it, you remember the rhythm of it all.

Modern solo mining — many paths, same foundations

By 2025, solo mining barely resembles the world of 2010–2015. The hardware evolved, the software stacks exploded, and the menu of “how to solo mine” options is wider than ever — but nearly all of it still rests on foundations built in the early eras.

Slush Pool became Braiins Pool, carrying forward the pooled-mining concepts Slush created in 2010 — predictable rewards, share validation, difficulty-based work, and coordinated distribution of block templates. The codebase is modernized, but the lineage is unmistakable.

CKPool and CK’s solo endpoint continued to evolve quietly and efficiently. The architecture, the philosophy, and the “minimal trust surface” model remain familiar, but the backend has seen years of improvements: better infrastructure, refined code, performance tuning, and long-term operational hardening that only comes from running a pool for more than a decade.

Around these pillars, the ecosystem exploded:

• hosted solo-mining services
• GUI node stacks and node-appliance platforms (Umbrel, Start9, Raspiblitz, etc.)
• Dockerized mining environments and lightweight stratum servers
• node-native block-template builders such as Ocean + DATUM
• endless experimental tools, forks, and — unfortunately — scams

If someone wants full sovereignty today, nothing stops them from running Bitcoin Core or Knots from source, maintaining their own mempool, building templates locally, and running their own stratum server — the path is still there, unchanged in principle.

What has changed isn’t the philosophy — it’s the number of choices layered on top of it.

Why this stuff still matters today

This isn’t nostalgia for old software — the early tools shaped the mining world we still live in. Every modern pool, every solo-mining setup, every Stratum implementation carries pieces of this lineage.

Slush Pool created the first workable model for pooled mining: predictable rewards, difficulty-based shares, centralized work coordination, and the beginnings of what later became modern payout systems. Even though Braiins Pool has evolved dramatically from the original codebase, the conceptual DNA still traces back to Slush in 2010.

cgminer defined how miners talk to pools. Its handling of work, stratum, hardware drivers, tuning philosophy, and monitoring expectations set the template for ASIC control software for years. Entire generations of miners were built assuming “the cgminer way” was the correct way — because for a long time, it was.

CK’s pool engine showed what a lean, efficient Bitcoin pool could look like without a massive corporate footprint. It was a focused codebase and an operational model for running a minimal-trust pool in the real world. You can still see echoes of that philosophy in how modern solo setups and lightweight pools are designed today.

And then there’s solo.ckpool.org — the first real pooled-solo setup (as most of us think of it today). It removed the operational burden for solo miners while preserving the purity of receiving the entire block reward directly. Hundreds of blocks, thousands of BTC paid out, and more than a decade of uptime have built a level of trust that simply can’t be forked or recreated.

That’s why these names still matter. That’s why people still recommend CKPool. That’s why Braiins Pool still has loyal miners. The foundation wasn’t marketing — it was engineering, history, and reliability earned over years.

When someone asks, “Why do people keep pointing new miners to CKPool?” the answer is simple: once you understand the history, the recommendation makes itself.

Closing

This isn’t the official history — it’s how I remember it, entering in late 2014 and learning from the ecosystem that came before me.

The people who actually built these tools were operating at a level the rest of us were just standing on. This page is my perspective as someone who lived through the era — not an attempt to speak for anyone who wrote the software.

Before publishing this, I ran certain sections past people familiar with the era. They offered a few corrections and historical clarifications that I really appreciated.

And for anyone just starting out with a Bitaxe or NerdQaxe today:

Welcome. The tools are cleaner now, but the rabbit hole is just as deep as ever.

More from me

I’m Mike (Proof Of Mike), a long-time hobby miner sharing real-world solo-mining notes and write-ups from the home-miner perspective. If you're interested in the different solo-mining setups that originally prompted me to write this history page, you can read that comparison here: Solo Bitcoin Mining Setups Compared.

If you found this helpful and want to explore more, you can find additional guides, articles, and solo-mining resources at ProofOfMike.com — or come say hi and talk mining or sports on X: @ProofOfMike.