So why did Luke Dashjr say "Hashrate is irrelevant at this point"?

I won't pretend to know what his opinion is, I'll just give you mine.

1) Mining isn't decentralized — pools are (allegedly, not really).

Why are pools not decentralized? Because the interests of "rival" countries converge more often than most realize (More context: https://controlplanecapital.com/p/rivalry-between-countries-is-curated ).

Hashrate aggregates into ~5–7 top pools; 2–3 could cross 51% at times.

Miners "vote with feet", but:

- Payout variance pushes them to big pools.

- Pools integrate with regulated fiat ramps and insurers; they may adopt OFAC/blacklist templates to avoid headaches.

Template power: Pools select transactions. If major pools adopt "policy clients" (e.g., template filters, blacklists), settlement becomes steerable — even if blocks remain valid under consensus.

So what? Incentives favor pool compliance with state policy — especially when insurance, utilities, and public listings are involved.

2) Hardware & energy are choke-points (supply-chain centralization)

- ASIC oligopoly. 2–3 manufacturers dominate. Firmware signing, remote management, and replacement cycles create vendor leverage.

- Jurisdictional energy. Large industrial miners rely on permits, grid interconnects, subsidies. In a low Gross Consent Product environment, regulators swap "ideals" for "stability" — conditional access > rights.

- Policy carrot/stick: cheap power for curtailment agreements, transaction policies, ESG attestations; penalties for non-compliant operators.

So what? If you need the grid and the power plant, the power plant owns you, and guess who owns the power plant.

I have just described the current state of mining "decentralization". Of course this could improve/worsen in the future.

Unless mining decentralization improves significantly, increasing hashrate is irrelevant at this point.

True. The elephant in the room is miner centralisation. Will they stop mining compliant blocks using black lists?

Reply to this note

Please Login to reply.

Discussion

Yes, I expect major pools to drift toward OFAC/blacklist templates (or "risk-graded" inclusion policies) unless the miner–pool protocol surface changes (Stratum V2 with job negotiation/Ocean's DATUM + non-custodial pooling) and enough hashrate actually uses it.

Security against reorgs/51% still scales with hashrate. So hashrate increases are not completely irrelevant.

But censorship-resistance does not scale with hashrate if template control remains centralized.

So marginal hashrate under the same pool topology is mostly irrelevant for freedom. Marginal hashrate under miner-templating topology is highly relevant.

What I expect (base case path)

- Soft censorship becomes normal: not outright bans, but risk-weighted delays and fee penalties.

- Pools posture "we follow law", insurers and utilities quietly codify it; most retail never notices — TXs just "feel slower unless you KYC".

- Effective Free Hashrate (EFH) stagnates unless miner-templating spreads; raw hashrate hits ATHs; headlines say "record security", while settlement becomes more steerable.

- Result: BTC functions as supervised SoV with compliant MoE corridors; non-compliant MoE becomes niche/expensive.

So the real metric you care about is Effective Free Hashrate (EFH).

EFH ≈ total hashrate × share using miner-controlled template selection (Stratum V2 job negotiation ON/Ocean's DATUM, or non-custodial pools) × (1 − censorship correlation across pools).

If Effective Free Hashrate (EFH) isn't rising, censorship cost isn't rising, no matter what the difficulty says.

TL;DR

With today's pool topology and perimeter levers, large pools are likely to adopt OFAC/blacklist-style templates (explicitly or implicitly).

Without miner-level template control becoming mainstream, more hashrate mostly strengthens the appearance of security, not the censorship-resistance Bitcoiners actually care about.

nostr:nevent1qvzqqqqqqypzq9qghtgynw4c5w9ewcr44llyz0p4yxa7aa3vcn8r24ffnayhruk2qqsqvvzc5pzgp7uf82ny4vdx3cq2jjhh5lss0j2tnxrg9zhxtalvfystnm33d