Quick answer: ASIC mining decentralization cannot be represented by one pool chart, manufacturer count, country estimate, or machine total. It is a control-topology question. Measure ownership, physical sites, template authority, work coordination, hardware supply, firmware, connectivity, energy counterparties, and reward custody separately, then ask whether several layers share a common operator or failure mode.
Bitcoin proves that sufficient work was committed to a valid block header. It does not place an ASIC model, machine owner, site, firmware version, energy contract, or jurisdiction on-chain. Most decentralization claims therefore combine protocol evidence with incomplete off-chain observations. A defensible analysis makes that boundary visible.
Define decentralization before measuring it
“Decentralized” can refer to independent decision makers, geographic distribution, low concentration in an observed market, resistance to a common outage, permissionless entry, or the ability to change coordinators. Those are related but not interchangeable.
Start with a threat or failure scenario. Transaction censorship is sensitive to template and job control. A grid emergency is sensitive to energy and geography. A compromised update is sensitive to firmware authority and controller access. A supply interruption is sensitive to design, fabrication, packaging, components, and repair. Reward seizure is sensitive to credentials and custody. The relevant topology and threshold change with the question.
Protocol boundary: what proof of work reveals
The Bitcoin whitepaper explains proof of work, network propagation, incentives, and the probability of a competing chain catching up. A valid header commits to a block and demonstrates work below the target. It does not attest to the make or location of the device that searched for it.
Bitcoin Core estimates network hashrate from accumulated proof of work over elapsed block time. The revision-pinned estimator implementation is a model over observed blocks, not a meter attached to every machine. The hashrate measurement guide explains the estimator, window sensitivity, and why a headline hash rate is not an inventory.
Coinbase tags and payout patterns may support block attribution, but labels are conventions and inferences. A label can describe a coordinator while thousands of separately owned devices contribute work, or one owner can distribute work across coordinators. Attribution quality needs a documented rule and an “unknown” category.
Control topology: ten layers to keep separate
| Layer | Control being measured | Evidence and limitation | Common-mode question |
|---|---|---|---|
| Capital and ownership | Who owns or finances hashing equipment? | Asset records, financing disclosures, surveys; mostly off-chain and incomplete. | Can one owner redirect or retire a material share? |
| Physical site and hosting | Who controls access, cooling, maintenance, and power state? | Site records and contracts; ownership can differ from operational control. | Can one host disconnect many nominal owners? |
| Energy and grid | Which utilities, grids, tariffs, and counterparties supply load? | Contracts and modeled estimates; country is an imperfect energy proxy. | Do sites share a grid event, contract, or fuel constraint? |
| Connectivity | Which networks, relays, DNS, VPNs, or gateways carry work? | Network measurement and operator disclosure; routes change. | Can one outage isolate several sites or coordinators? |
| Pool and payout coordination | Who sets share targets, accounts for work, and calculates payouts? | Block attribution, endpoint observation, operator terms; not ownership proof. | How quickly can operators switch without losing control or balances? |
| Template authority | Who selects transactions and constructs the candidate block? | Job captures, software configuration, protocol evidence; often unobservable publicly. | Can a coordinator impose a common transaction policy? |
| Job distribution | Who converts templates into work and sends jobs to devices? | Protocol traces and endpoint configuration; may differ from template author. | Can one credential or service redirect a large fleet? |
| Hardware supply | Who controls design IP, fabrication, packaging, boards, PSUs, and critical parts? | Supply disclosures and component inspection; controller openness is not die openness. | Which failure or restriction affects several product lines? |
| Firmware and remote control | Who signs, distributes, updates, and administers code? | Firmware builds, signatures, network behavior, and access policy. | Can one key, service, or account change many devices? |
| Reward custody | Who controls payout credentials, balances, and destination keys? | Wallet and account controls; a payout address may not disclose beneficial control. | Can one custodian freeze or redirect accumulated rewards? |
Measurement table: match each metric to a layer
| Metric | Unit and window | What it approximates | Required caveat |
|---|---|---|---|
| Attributed block share | Share of blocks over stated rolling and fixed UTC windows | Observed coordinator attribution | Labels are probabilistic and do not establish hardware ownership or template authority. |
| HHI | Sum of squared entity shares for one layer and window | Concentration sensitive to both large and small shares | Depends on correct entity resolution; unknown observations need an explicit treatment. |
| Threshold entity count | Minimum resolved entities needed to exceed a stated percentage | Coordination exposure for a defined scenario | The threshold must match the threat; a majority-work threshold does not describe every failure. |
| Template-authority share | Share of observed jobs or templates over time | Transaction-selection concentration | Public observation is limited; protocol capability is not proof of use. |
| Ownership or site share | Estimated hashrate, machines, or capacity by owner or site | Capital or physical concentration | Private data, nameplate versus realized output, and sampling bias can dominate. |
| Hardware and firmware share | Sampled models, control boards, builds, or update authorities | Common-mode equipment and control exposure | The blockchain cannot supply these fields; samples may overrepresent public operators. |
| Geographic and energy share | Estimated work or capacity by site, grid, jurisdiction, and counterparty | Physical and policy correlation | Country inference, VPNs, seasonal movement, and modeled electricity use add uncertainty. |
| Custody share | Rewards or balances under common key/account control | Financial control concentration | Pool identity and payout address do not necessarily reveal beneficial custody. |
How to calculate and report concentration
For shares s1 ... sn expressed as decimals, HHI = sum(si^2). Report the value only for a named layer, observation window, attribution method, and entity-resolution rule. Combining sites, owners, and pools into one HHI produces a number without a coherent unit.
A threshold entity count is the smallest number of resolved entities whose combined share exceeds a stated threshold. Define why the threshold matters before calculating it. A majority threshold is relevant to a sustained competing-work scenario, but firmware compromise, grid failure, legal process, or supply interruption can have different thresholds and correlations.
Publish numerator, denominator, unknown share, observation count, UTC start and end, last retrieval time, exclusions, and confidence grade. Show several windows when block-count variance matters. Do not rank named entities on an evergreen page or imply that a short window is durable market structure.
Pool share is not ownership share
A pool typically coordinates work submissions and payouts. Machines can be owned and operated by many parties, and operators can sometimes redirect them. Conversely, related owners or hosted fleets may appear under different labels. Pool attribution therefore measures one observable coordination layer, subject to label quality.
Switchability is also not binary. Measure contractual lock-in, payout thresholds, account custody, network compatibility, configuration authority, latency, firmware restrictions, and the time required to redirect work. Nominal access to several endpoints does not establish independent control if one remote account controls every device.
Template authority and the control plane
Transaction selection begins with a block template, not with silicon performing SHA-256. BIP 22 defines getblocktemplate, and BIP 23 specifies related extensions. They establish technical interfaces, not current adoption rates.
The revision-pinned Stratum V2 Job Declaration specification describes modes in which a downstream participant can declare work. Separate four questions: does the specification permit custom jobs, does deployed software implement them, is the feature enabled, and does measurable work actually use it? Treating the first as proof of the fourth overstates decentralization.
Control-plane evidence can include captured jobs, template comparisons, node and proxy configuration, authentication ownership, and software reproducibility. Public data are incomplete, so a responsible report may conclude “not observed” rather than assigning control to a pool label by assumption.
Hardware supply is more than a manufacturer count
An ASIC system includes algorithm-specific logic and physical design, licensed IP, masks, wafer fabrication, packaging and test, substrates, memory and power components, hashboards, controllers, networking, power supplies, cooling, firmware, and service tooling. Several branded products can share a foundry, package supplier, component, or firmware lineage.
Measure common dependencies at the narrowest available level. A diverse final-assembly market can still have concentrated fabrication. An inspectable controller does not make the ASIC die open. An available schematic does not guarantee component supply, reproducible firmware, or permissionless fabrication. Record whether evidence concerns source code, hardware description, board files, masks, build tooling, signing keys, or documentation.
Firmware, updates, and remote administration
Firmware can set frequency, voltage, thermal protections, fan behavior, pool endpoints, authentication, and update policy. A topology audit should identify who can sign or distribute updates, whether builds are reproducible, how rollback works, which outbound connections occur, and who owns administrative credentials.
Open source can improve inspectability and the ability to fork a component. It does not by itself prove that the binary on a machine matches the source or that operators control the update path. Conversely, closed components do not establish that one actor can remotely control every installation. Test the specific dependency and distinguish potential access from demonstrated use.
Geography, hosting, energy, and connectivity
Country share is an incomplete proxy. Two sites in different countries may depend on one owner, firmware service, network gateway, insurer, lender, energy trader, or coordinator. Several sites in one jurisdiction may have distinct grids, counterparties, and operating control. Report site, balancing area or grid, contract counterparty, connectivity, and legal exposure where evidence permits.
Electricity consumption and geographic distribution are estimated, not read directly from the blockchain. The CBECI methodology is useful as an example of modeled bounds, assumptions, and data limitations. It should not be converted into a claim about a particular machine, energy source, or current regional share without the corresponding dated dataset and method.
Hosting separates beneficial ownership from physical control. Review access rights, curtailment authority, maintenance permissions, network administration, default remedies, and the ability to remove or redirect equipment. A map of owner addresses cannot substitute for operating contracts.
Reward custody is a separate concentration dimension
A machine owner may still rely on another party’s account, payout balance, destination configuration, or signing process. Measure who can change the payout address, how often funds settle, whether balances are held, which credentials authorize changes, and whether one custodian serves otherwise separate operators.
This layer affects financial loss and coercion without changing the validity of blocks. It should not be folded into hashrate share, but it belongs in a complete operational topology.
Home mining: count independent controls, not devices
A home operator can diversify ownership, siting, energy, connectivity, maintenance, and operational decisions. If the operator independently controls firmware, job configuration, template path, and payout keys, more layers may become independent. If many small machines share a remote controller, one template source, one credential authority, or one custodian, the device count can overstate resilience.
Small shares still matter to entry, experimentation, fault diversity, and the set of operators able to respond. Their contribution to a specified attack or outage should be stated in the same units as the scenario. Do not claim that every additional home machine guarantees censorship resistance or materially changes a majority-work threshold.
Repairability and open components: conditional benefits
Repair can extend useful life, reduce replacement dependence, distribute technical knowledge, and make older equipment available to more operators. Its decentralization effect depends on access to diagnostics, parts, firmware, documentation, tools, and skilled labor. A single remote diagnostic service or scarce component can remain a common dependency.
For open components, name the artifact and freedom provided: inspect, modify, reproduce, fabricate, or redistribute. Board files, enclosure designs, and controller firmware affect different layers from ASIC design IP and wafer fabrication. Avoid describing the whole miner as open when only a subset is documented.
ASIC resistance does not guarantee decentralized control
A proof-of-work algorithm is a consensus rule. Changing it is technically possible only through compatible rule adoption; it is not an automatic setting that one group can impose on unchanged nodes. A transition would strand or redistribute installed capital, create implementation and activation risk, and start a new optimization cycle.
A stable, valuable workload can motivate specialized implementations. General-purpose devices may broaden initial access but also introduce concentrated component supply, cloud, rental, or botnet exposure. The relevant question is not whether specialization can be declared away, but which topology and attack costs result under a particular design and adoption path.
Research evidence without frozen rankings
Gencer and coauthors provide an academic network-measurement study that illustrates how decentralization results depend on data collection and metrics. Bonneau and coauthors survey proof-of-work incentives and security research. These sources support methodology and threat framing; their historical observations are not current rankings.
For any updated dataset, preserve a snapshot or version, retrieval timestamp, raw observation count, labeling method, unresolved share, and transformation code. Separate direct observations from estimates and operator disclosures. Do not silently replace missing values with zero or carry a dated country, pool, model, or efficiency share into evergreen copy.
How this guide differs from nodes versus miners
This article measures who controls mining-related layers and how those layers correlate. It does not determine which blocks a full node considers valid or imply that more reachable nodes equal more hashpower. For the transaction lifecycle, consensus versus policy, chainwork, majority-hash boundaries, and what a local node changes, read Bitcoin Nodes vs Miners: Validation, Block Production, and Security.
A repeatable topology audit
- State the failure or attack scenario and the affected decision.
- Choose one control layer and unit; do not mix pool, owner, site, and manufacturer shares.
- Set UTC observation windows before looking at results.
- Define entity resolution, labels, affiliates, unknown observations, and confidence grades.
- Calculate layer-specific shares, HHI, and a scenario-appropriate threshold count.
- Map cross-layer dependencies such as a shared host, firmware key, grid, network, lender, or custodian.
- Run sensitivity cases for unknown observations and alternative entity groupings.
- Publish source versions, methods, limitations, and the next review trigger.
Sources and revision record
Methodology reviewed 2026-08-29 against the Bitcoin whitepaper; BIP 22 and BIP 23; Bitcoin Core commit ca7162cde58e69214a3309c17fac6d666b5f055a; Stratum V2 specification commit 0f38d51dcd569e8f76575bf03cdf12848f4a4bef; the cited peer-reviewed measurement literature; and the cited energy-estimation methodology. This evergreen page embeds no current entity share, pool ranking, manufacturer ranking, country ranking, machine count, network hashrate, price, or profitability figure.
Frequently asked questions
Does ASIC mining necessarily centralize Bitcoin?
No single conclusion follows from the hardware category alone. Specialized hardware can increase the work committed to Bitcoin while also creating capital, semiconductor, firmware, and supply dependencies. The decentralization result depends on who controls ownership, sites, templates, pools, firmware, energy, connectivity, and rewards, and on how correlated those controls are.
Can the blockchain reveal an ASIC manufacturer or location?
No. Bitcoin block data can show proof of work and may contain evidence used to attribute a block to a coordinator, but it does not identify the hashing-device model, owner, firmware, physical site, grid, energy contract, or jurisdiction. Those dimensions require off-chain evidence with a stated sampling method and confidence level.
Is pool block share the same as mining ownership?
No. Pool-attributed block share usually estimates the coordinator associated with found blocks. Independent operators can contribute machines to one pool, and one owner can use several pools. The label does not by itself disclose hardware title, financing, hosting control, energy exposure, or payout-key ownership.
Is pool share the same as block-template control?
Not always. A coordinator may construct templates, but compatible job-declaration arrangements can separate transaction selection from share accounting and payouts. Capability, deployment, adoption, and actual use must be measured separately; a protocol specification alone is not evidence of current template independence.
Which metrics can measure mining concentration?
Useful measures include time-windowed attributed block share, HHI, an explicitly defined threshold entity count, and layer-specific shares for ownership, templates, sites, hardware, firmware, hosting, geography, energy counterparties, and custody. Every result needs a unit, window, entity-resolution rule, source, uncertainty, and known blind spots.
When does home mining improve decentralization?
It can improve a layer when it adds independently controlled ownership, siting, energy, connectivity, firmware, template choice, or custody that can survive a common failure. More machines do not automatically mean more independent authority if the same remote credentials, host, firmware service, coordinator, template source, or payout custodian controls them.
Do repairability or open components guarantee decentralization?
No. Repair can reduce replacement dependence and extend equipment life, while inspectable components can reduce some control risks. Neither reveals or opens every semiconductor layer, and neither guarantees diverse ownership, firmware authority, template choice, energy supply, hosting, or custody. The affected dependency must be named and measured.
Would an ASIC-resistant algorithm solve mining centralization?
Not necessarily. A proof-of-work rule change would require compatible participant adoption and would strand or redistribute existing capital. Stable workloads can still attract specialization, while general-purpose hardware can introduce other concentrated supply or botnet risks. The change would move trade-offs rather than guarantee decentralized control.
