BIP-110: a decentralization lesson written into Bitcoin history
BIP-110, titled Reduced Data Temporary Softfork, proposed temporary consensus restrictions intended to limit large arbitrary-data fields in Bitcoin transactions. Its supporters argued that Bitcoin should remain primarily a monetary network and that large data inscriptions impose costs on node operators and compete with financial transactions for block space.
The concern itself was not irrational. Bitcoiners can legitimately disagree about inscriptions, arbitrary data, relay policy and how much burden node operators should be expected to carry. The crucial historical question was not whether the concern was sincere—it was whether enough of the Bitcoin economy was willing to adopt the new consensus rule.
Policy is not the same thing as consensus
This distinction is one of the most important lessons from BIP-110. A node can say, “I do not want to relay this transaction,” while still accepting a valid block containing that transaction after a miner includes it. That is policy. A consensus rule says, “A block containing this transaction is invalid.” Consensus disagreements can split the chain.
| Decision | Local policy | Consensus rule |
|---|---|---|
| Relay a transaction? | Node operator can choose | Not normally required for block validity |
| Keep transaction in mempool? | Node operator can choose | Does not by itself change Bitcoin rules |
| Put transaction in a candidate block? | Miner/template builder can choose | Block still must satisfy consensus |
| Reject an otherwise-valid block? | No longer merely policy | This changes the accepted consensus set |
A UASF is not automatically wrong. Bitcoin history includes successful user pressure, most famously around SegWit. But BIP-110 demonstrated that the phrase “users decide” does not mean a small subset of users can unilaterally command miners, exchanges, businesses and other users. Bitcoin consensus ultimately emerges from voluntary coordination among economically relevant participants enforcing compatible rules.
The mining-pool problem: concentrated coordination
Bitcoin's physical hashrate is enormous and spread across many facilities and owners, but the public face of block production is concentrated in a relatively small number of mining pools. That matters because traditional pools often construct the candidate block template and tell participating ASICs what work to perform.
At the time this page was prepared on August 17, 2026, Hashrate Index's current pool table showed approximately:
Snapshot only. Pool shares fluctuate continuously. The five figures above total about 79.35% of the observed window, illustrating concentration at the coordination layer—not necessarily common ownership of 79.35% of the world's ASIC hardware.
A mining pool is not necessarily one giant miner
This is frequently misunderstood. If a pool has 20% of reported hashrate, the pool company does not necessarily own 20% of all Bitcoin mining machines. Independent companies, farms and individuals can point their ASICs at the same pool because pooling reduces payout variance.
But concentration still matters. If the pool builds the template, the operator can influence which transactions its participants attempt to confirm. A few pool operators can therefore become attractive pressure points for governments, regulators, sanctions regimes, banks or commercial partners that want certain transactions filtered.
Template concentration
If a few pools choose most block templates, transaction-selection authority is more centralized than the ASIC ownership chart suggests.
Regulatory chokepoints
Large identifiable pool companies can be easier to regulate, sue, sanction or pressure than thousands of independent home miners.
Payout dependence
Miners join pools for predictable revenue. That economic need can keep hashrate concentrated even when miners philosophically prefer independence.
What 51% of hashrate can—and cannot—do
A majority of hashrate is dangerous because it can potentially reorganize recent history, censor transactions by refusing to include them, or attempt double-spend strategies. But hashrate does not grant the power to create arbitrary bitcoins, spend coins without keys, rewrite the 21-million limit by itself, or force validating nodes to accept blocks that violate the nodes' consensus rules.
That is why Bitcoin's decentralization is layered. Miners propose blocks. Full nodes independently validate them. Wallet owners control keys. Markets decide what they value. Developers publish software, but users decide what to run.
Governments, Wall Street and corporations: influence is real, control is different
Government pressure
Governments can exert substantial influence around Bitcoin's edges. They can regulate exchanges, require identity verification, pressure public mining companies, control access to electrical grids, restrict imports of mining equipment, enforce sanctions, tax mining income and regulate custodians. A mining industry dominated by a handful of giant, publicly visible facilities is easier to pressure than a geographically dispersed mixture of industrial, commercial and home miners.
But a government cannot simply issue a regulation that causes independent full nodes around the world to accept an invalid transaction or an inflationary block. To gain that kind of control, it would need much broader technical, economic and social coordination.
Wall Street and institutional investors
Institutional investment changes Bitcoin's market structure. ETFs, large custodians, public mining firms, derivatives markets and corporate treasuries can influence price discovery, liquidity and public perception. Concentrated custodial holdings can create operational or political chokepoints.
However, owning a billion dollars of bitcoin does not provide a billion dollars' worth of protocol votes. Bitcoin is not proof-of-stake. A large investment company cannot change the 21-million limit merely because it owns a large quantity of BTC.
Corporate mining
Large professional miners are not automatically enemies of Bitcoin. They contribute enormous proof-of-work security and can develop efficient energy infrastructure. The risk appears when mining hardware ownership, pool selection, template construction, firmware, energy supply and custody all become concentrated in the same small set of organizations.
Bitcoin does not need to eliminate profitable mining. Bitcoin needs profitable mining to remain contestable: new entrants must be able to join, miners must be able to switch pools, independent operators must be able to validate the chain, and users must be able to withdraw to wallets they control.
Should Bitcoin abandon SHA-256 ASICs for CPU/GPU mining?
At first glance, switching Bitcoin to a CPU-friendly or GPU-friendly proof-of-work algorithm seems like a direct way to destroy industrial ASIC dominance. Everyone already owns a CPU; millions own GPUs. Why not make ordinary computers miners again?
Because the cure would introduce new and potentially larger risks.
| Issue | Keep SHA-256 ASIC PoW | Fork to CPU/GPU-oriented PoW |
|---|---|---|
| Existing security capital | Preserves global SHA-256 mining infrastructure | Strands existing Bitcoin ASIC investment on the fork |
| Hard-fork risk | No algorithmic chain split required | Very likely creates competing chains if old miners continue SHA-256 |
| Hardware purpose | ASICs are specialized for SHA-256 | CPUs/GPUs are general-purpose and rentable |
| Cloud concentration | Industrial miners can centralize | Large cloud providers and data centers own huge general-purpose fleets |
| Botnet incentive | Consumer computers cannot efficiently mine SHA-256 BTC | CPU-friendly PoW can create incentives for malware mining |
| Long-term specialization | Specialization is explicit | ASIC resistance may reduce, not permanently eliminate, specialization |
| Consensus stability | Preserves Bitcoin's long-established PoW rule | Changes one of Bitcoin's deepest consensus assumptions |
Why SHA-256 ASICs can actually help Bitcoin
An Antminer has very little alternative economic purpose. A Bitcoin SHA-256 ASIC represents sunk capital dedicated to proof of work. That specialization makes the security resource less interchangeable with cloud-computing workloads, AI workloads, video rendering or general corporate computing.
A CPU/GPU network can be more accessible at the hardware level, but its computing power is also more general-purpose and may be easier to rent or redirect. Large cloud providers, universities, data centers and compromised computer networks already possess enormous pools of general-purpose computation.
RandomX is a serious example of a CPU-oriented PoW design. Its own documentation states that it is optimized for general-purpose CPUs and uses random code execution plus memory-hard techniques to minimize the efficiency advantage of specialized hardware. That is a valid design goal for Monero. It does not follow that Bitcoin should abandon its existing SHA-256 security ecosystem to pursue the same tradeoff.
“ASIC resistant” is not the same as “centralization resistant”
Even if an algorithm prevents a large ASIC advantage, economics still rewards cheap electricity, low cooling costs, access to capital, bulk hardware purchasing and professional operations. GPU farms can become industrial. CPU farms can become industrial. Cloud computing is already industrial.
And miners would still join pools because solo-mining variance does not disappear merely because the hashing device is a CPU. Millions of CPUs can still point to three pools.
Why keeping SHA-256 is the better course
Bitcoin's SHA-256 proof of work has accumulated a massive ecosystem of hardware, firmware, energy contracts, engineering expertise, repair infrastructure and operational knowledge. That installed capital raises the cost of attacking the existing network. Throwing it away to reset mining hardware would exchange a known centralization challenge for a new and unpredictable security environment.
The better strategy is to make SHA-256 mining itself more distributed and sovereign: more owners, more locations, more energy sources, more independent nodes, more miner-created templates and easier pool switching.
What can actually make Bitcoin more decentralized?
1. Run a full node
Your own node verifies Bitcoin's rules. Do not outsource consensus verification to an exchange, explorer or pool when you can verify locally.
2. Expand home mining
Home, farm, workshop, hydro, solar and heat-reuse mining spreads physical hashrate across many owners and jurisdictions.
3. Self-custody
Decentralized money held entirely by centralized custodians recreates a chokepoint. Withdraw to wallets whose keys you control.
4. Build your own templates
Use protocols that let the individual miner—not merely the pool—choose valid transactions for candidate blocks.
5. Switch pools when needed
Miners should treat a pool as replaceable infrastructure. Censorship or unacceptable policy should cause hashrate to leave.
6. Preserve software choice
Core, Knots and compatible tooling should be evaluated on merits. Diversity is useful when consensus compatibility is respected.
DATUM: turn the pool into a payout coordinator
OCEAN's DATUM—Decentralized Alternative Templates for Universal Mining—is designed to let miners create block templates from their own Bitcoin node. The miner can still participate in a supported pool for payout smoothing, while transaction selection moves back toward the miner.
validates chain and maintains your mempool
creates/distributes your mining work
performs proof of work
The crucial idea is that the pool can become more like an accountant than a block editor. Pooling can remain useful for low-variance payments without requiring one corporation to dictate every transaction its members attempt to confirm.
Stratum V2 Job Declaration
Stratum V2 attacks the same centralization problem from the mining-protocol layer. Its Job Declaration Protocol is explicitly designed to prevent pools from unilaterally imposing work on miners. In the design, pools can focus on accounting for shares and distributing rewards while miners declare custom work. The specification also provides fallback behavior if a pool rejects valid custom work.
Solo mining still has a role
True solo mining gives the individual miner maximum independence. The miner runs the node, constructs the template, performs the work and—if lucky enough to find a valid block—receives the full subsidy and transaction fees.
The disadvantage is brutal payout variance. A single modern home ASIC represents only a tiny fraction of global hashrate. Solo mining is therefore excellent for sovereignty and experimentation but can go extraordinarily long periods without any reward. Pooling exists because that financial variance is real.
That is why miner-selected templates plus pooled payouts may be one of the most practical decentralization advances available today.
Make pool failure survivable
A healthy mining setup should avoid a single point of failure. Miners can configure alternative pools, keep local node infrastructure maintained, understand how to change Stratum endpoints, and periodically verify that the pool's policies still match their own expectations.
What BIP-110 should teach the next generation of Bitcoiners
Lesson 1: Consensus is hard to change—and that is a feature. A monetary system intended to last generations should not change fundamental rules merely because one developer, corporation, government, mining pool or online faction demands it.
Lesson 2: Node operators matter, but they cannot ignore economic reality. A node can enforce any rule its owner chooses. If almost nobody else accepts that rule, the node can isolate itself onto a minority chain. Sovereignty includes accepting the consequences of your own rules.
Lesson 3: Miners are powerful but not kings. Miners choose and order valid transactions and provide proof of work. They cannot force independently validating nodes to accept invalid blocks.
Lesson 4: Users are powerful when they take custody. Bitcoin held entirely through custodians gives those custodians leverage. Self-custody turns economic ownership into direct control of keys.
Lesson 5: Pool decentralization should focus on template authority. A pool with 25% of hashrate is much less threatening if thousands of participating miners independently construct 25% worth of candidate blocks.
Lesson 6: Do not throw away SHA-256 merely to reset the hardware market. Bitcoin's specialized proof-of-work infrastructure is part of its security. Decentralize ownership and decision-making around that infrastructure instead.
Lesson 7: Freedom requires exit. The ability to change software, move an ASIC to another pool, broadcast through another peer, withdraw from a custodian, move jurisdictions, or run your own node is more important than trying to design a system in which no powerful institution ever exists.
A practical decentralization blueprint
For an individual Bitcoiner
Learn self-custody, back up recovery material securely, run a full node if practical, use your own node with your wallet, avoid leaving long-term holdings on exchanges, and understand what software rules your node is enforcing.
For a home miner
Keep SHA-256 hardware productive. Point it toward smaller or decentralization-focused pools when economically reasonable. Experiment with DATUM, Stratum V2 or true solo mining. Keep a fallback pool configured so a local server failure does not leave the ASIC idle.
For a mining company
Diversify pool relationships, support miner-created templates, avoid building dependence on one custodian or one jurisdiction, and make censorship policy transparent. Industrial miners can strengthen Bitcoin decentralization if they refuse to become captive hashpower.
For wallet and node developers
Make self-hosting, self-custody and miner-directed block construction easier. Good decentralization technology is technology ordinary people can actually operate.
For the Bitcoin community
Watch concentration without confusing size with guilt. Large organizations are not automatically hostile; small organizations are not automatically trustworthy. Judge systems by whether users can verify them and exit them.
Conclusion: decentralization is something Bitcoiners do
BIP-110 became an important 2026 case study because it showed both sides of Bitcoin sovereignty. Node operators were free to enforce a controversial rule. The rest of the network was free not to follow them. When the mandatory-signaling fork attracted insufficient mining support, the minority chain stalled and the proposal was subsequently marked Closed.
The mining-pool concentration problem is more enduring. A small number of pools currently coordinate a large majority of observed hashrate, which creates legitimate concerns about transaction censorship, regulation and infrastructure dependence. But replacing SHA-256 with CPU or GPU proof of work would not automatically solve that problem. It could destroy existing security capital, create a contentious hard fork and simply replace ASIC concentration with cloud, GPU-farm or general-purpose computing concentration.
The more promising route is evolutionary rather than destructive: keep SHA-256, spread ASIC ownership, expand home mining, run independent nodes, move block-template authority to miners, use protocols such as DATUM and Stratum V2, maintain the ability to switch pools, and keep bitcoin in self-custody.
Bitcoin's defense has never been that powerful actors disappear. Its defense is that the system gives independent participants enough tools to route around them.
Important disclaimer
Educational and historical material only. This page is not financial, investment, legal, tax, cybersecurity or mining-business advice. Bitcoin mining can lose money. Bitcoin prices are highly volatile. Running experimental node or mining software can create operational risks, including following an unintended chain or losing mining revenue.
Pool market-share statistics change continuously. Verify current data before relying on any figures. Software, consensus proposals and mining protocols also evolve; check primary sources and release documentation before changing a production node or miner.
No statement on this page should be interpreted as an accusation that a named company, pool, government, financial institution or developer is acting maliciously. The discussion concerns structural concentration risk and how decentralized systems can reduce dependence on trusted intermediaries.
Sources & further reading
The most important claims on this page are grounded in primary protocol documentation and current mining data, with contemporary reporting used for the BIP-110 chain-split history.
- Bitcoin BIPs — BIP-110: Reduced Data Temporary Softfork. Primary specification. The repository shows status Closed; its August 9, 2026 changelog says it was marked closed following a chain split with stalled mining.
- CoinDesk — Controversial Bitcoin fork BIP-110 mines two blocks, then stops. Contemporary reporting on the minority chain and reported miner support.
- Hashrate Index — Bitcoin Mining Pool Data. Current and historical pool share data. Figures on this page were captured August 17, 2026 and will change.
- Stratum V2 — Job Declaration Protocol Specification. Primary specification describing custom work, miner-side job declaration and pool share/reward coordination.
- OCEAN — DATUM Setup Guide. Describes creating block templates with the miner's own Bitcoin node and mining via DATUM-supported pools or solo.
- OCEAN DATUM Gateway source repository. Open-source implementation of miner-side template creation and block submission.
- Bitcoin Developer Reference — Block Chain. Technical reference for Bitcoin's 80-byte block header and SHA-256d proof-of-work construction.
- RandomX official source repository. Primary documentation for a CPU-optimized, memory-hard proof-of-work design intended to minimize specialized-hardware advantage.
- BTC.TedLee.ca — Bitcoin Education. Main educational site.
Last substantive update: August 17, 2026. Because mining-pool shares and software status change rapidly, time-sensitive values should be independently rechecked.