You're hashing blocks you didn't build. Every transaction in that block was chosen by a pool operator sitting in a data center somewhere, and your machines have no say in the matter. They just churn through nonces on someone else's template. That arrangement has always been Bitcoin's quiet centralisation problem, and for a long time the only proposed fixes required a fork, a fight, or both.
Stratum V2's header-only mining mode changes the equation without touching the consensus rules at all.
The Problem Is Older Than Most People Realise
When mining pools emerged around 2010, they solved a real problem: variance. A solo miner with a small rig could work for years without finding a block. Pools let miners combine hashrate and share rewards proportionally. Sensible engineering. The side-effect, though, was that the pool operator became the one constructing the block template, deciding which transactions go in, in what order, and what gets left out.
That's a lot of power in very few hands.
At various points, the top three or four pools have collectively controlled well over 50% of global hashrate. If a government, a regulator, or a sufficiently motivated attacker leaned on those operators, they could exclude specific addresses or transaction types from the majority of blocks without ever touching Bitcoin's protocol. No fork needed. No on-chain vote. Just a policy change in a data center, quiet as closing a valve.
What Stratum V2 Actually Is
Stratum V2 is a redesigned mining communication protocol. The original Stratum (sometimes called V1) has been the industry standard since roughly 2012: a loosely specified, plaintext JSON protocol that gets the job done but was never designed with security or miner autonomy in mind. V2 replaces it with a binary protocol, adds encrypted authenticated connections between miners and pools, and dramatically reduces the bandwidth a single share submission requires.
Useful improvements, all of them. But the part that matters for censorship resistance is a specific operational mode called Job Negotiation, which enables what the spec calls header-only mining.
The distinction is worth stating plainly. In standard Stratum V2 operation, the pool still builds the block template and sends it down to miners, same as before. Header-only mining is an opt-in sub-protocol on top of V2 where the miner's own node constructs the template instead. Those are different things, and conflating them is a mistake the marketing around V2 deployment has encouraged.
How Header-Only Mining Actually Works
Picture two miners, call them Priya and Sven, both pointing hashrate at the same mid-sized pool. The pool runs Stratum V2. Priya uses the default mode: she receives a template from the pool, hashes it, submits shares. Sven has set up a Bitcoin full node locally and opted into Job Negotiation.
Here is what happens on Sven's side.
Sven's node builds a candidate block template from its own mempool, picks transactions, orders them, computes a Merkle root. His mining firmware opens a Job Negotiation session with the pool's Job Negotiator service and sends a description of the template (not the full template itself), along with a proposed coinbase transaction that includes the pool's payout address. The pool checks that the coinbase is correct, that the fee total is plausible, and that the block's version and timestamp look valid. If everything checks out, the pool signs off. Sven's hardware starts hashing the header of his own block.
When Sven finds a valid proof-of-work, the full block goes to the pool or directly to the Bitcoin network depending on configuration, and the pool credits his share like any other.
The pool never saw Sven's transaction list until after the work was done. It could not have selectively excluded a transaction from his block even if it wanted to. The pool's approval step only validates the coinbase output and the header fields. It does not inspect or control the transaction set. The censorship surface has been removed from the pool's hands entirely, for that miner, without any change to Bitcoin's consensus rules.
The Real Tradeoffs (And Why Adoption Is Slow)
Header-only mining is not free. Sven needs a synced, well-connected full node and firmware that supports Job Negotiation, and not every ASIC manufacturer has shipped it. He takes on some variance in fee revenue because his mempool might differ slightly from the pool's view at the moment a block is found. If his node goes offline, his mining rig needs a fallback mode or it stops producing shares.
The infrastructure burden is real. A hobbyist with two miners in a garage can probably manage it. A large-scale operation with thousands of machines needs to roll out node infrastructure at scale and keep it running. That's not impossible, but treating it as a minor configuration change is wishful thinking.
Pool operators have their own concerns. A pool accepting externally negotiated jobs loses the ability to guarantee its own fee-optimisation strategy. Some pools have raised questions about DoS vectors: a miner submitting malformed or deliberately unprofitable templates creates work for the pool's Job Negotiator. The spec includes mitigations, but implementation quality varies.
Adoption has consequently been uneven. Some pools have deployed full V2 support including Job Negotiation. Others support V2's encrypted transport but not the Job Negotiation extension, which is a bit like installing a secure front door and leaving the back window open. A few have stayed on V1 entirely. The mining firmware ecosystem is catching up, but the majority of global hashrate has continued operating in pool-controlled template mode.
Why This Matters More Than It Looks
The argument for header-only mining is not that it eliminates pool centralisation. Pools will still exist; variance reduction is a genuine service. The argument is that it makes transaction censorship by pool operators structurally harder to enforce, even if pools retain majority hashrate.
A pool operator who wants to censor a specific transaction today can simply never include it in any template they distribute. Done. With Job Negotiation, that same operator would need to actively inspect and reject every externally negotiated template containing the forbidden transaction, then identify which miners submitted it, then decide whether to penalise them. That's a much noisier, more legally and operationally fraught intervention. It raises the cost and the visibility of the attack substantially.
Does it make censorship impossible? No. A determined, coordinated effort across multiple large pools could still be effective.
The question worth asking before you point hashrate anywhere: does your pool actually have Job Negotiation deployed, or just the encrypted transport layer? Only one of those gives you meaningful template independence, and the marketing rarely bothers to specify which.
Bitcoin's censorship resistance has always been most fragile at the infrastructure layer, not the protocol layer. Stratum V2's header-only mode is the most concrete mechanism the industry has produced for patching that gap. The plumbing exists. Whether enough miners bother to connect it is a different problem entirely.