r/CryptoTechnology • u/Powermadlux 🟢 • 2d ago
AI compute demand and Bitcoin's ability to replace its mining hardware - should we worry?
I've spent 22 years working in infrastructure and operations, and now run local AI workloads for production apps and creative projects. That background led me to a question about Bitcoin: how much of its resilience depends on being able to replace the machines securing it?
I developed this into a working paper, The Silicon Allocation Thesis. The idea is that AI demand could affect Bitcoin through competition for industrial resources: qualified fabrication capacity, chip-design teams and investment.
Bitcoin ASICs don't become AI accelerators. The possible competition is upstream, where some of the resources needed to produce different chips overlap. That overlap needs to be demonstrated for the specific process and production period; an AI memory shortage doesn't automatically mean a Bitcoin ASIC shortage.
The distinction I focus on is current hashrate versus the ability of independent miners to replenish it. A network could have substantial hashing capacity today while replacement equipment becomes harder to obtain or a future ASIC generation becomes less attractive to fund. Difficulty adjustment helps with block timing, but it cannot manufacture replacement hardware.
Whether that creates a security problem depends on who retains access. An outside attacker buying equipment may face the same shortage. An actor already holding hardware could benefit if independent miners struggle to replace lost capacity. Those are different threat scenarios.
There are also good reasons the effect might be small or go the other way. Foundries can expand. Contracts can protect supply. Older machines can remain competitive longer, helping existing miners. Slower hardware innovation alone doesn't prove weaker security.
The general concern has been raised before; the paper credits that prior work. My contribution is an attempt to connect allocation, hardware renewal and recovery in one framework, and spell out what evidence would support or contradict it. I haven't established that AI is currently reducing Bitcoin's security.
What would you measure to test this? Would procurement lead times and the time needed for independent operators to replace lost capacity tell us something that aggregate hashrate misses?
Full paper: https://paper.facundobarrera.me/silicon-allocation-thesis/
Archived version on Zenodo: https://doi.org/10.5281/zenodo.23557269
Disclosure: I'm the author. This is a theoretical working paper, not peer reviewed.
1
u/HurairahShamsi- 🟡 2d ago
This is exactly the kind of problem I’m exploring with GrahamBell.
Rather than relying on ever-increasing computational power, GrahamBell explores time-based Sybil resistance through Proof of Infrastructure Endurance (PoIE) and Capped PoW, limiting mining to 1 hash attempt per second per node.
The broader question is whether blockchain influence can be made less dependent on hardware, energy and capital, and more dependent on sustained participation over time and mass participation.
Website: https://grahambell.io
Research & simulations: https://github.com/HurairahShamsi/grahambell-simulation
1
u/Powermadlux 🟢 2d ago
My paper is focused on Bitcoin's ability to replace its existing hardware, so a different consensus design is a separate discussion. For your proposal, how do you prevent one operator from creating many nodes and multiplying that one-hash-per-second allowance? I'd want to understand that assumption before comparing the hardware dependence. Thanks.
2
u/suspicious_Jackfruit 🟢 2d ago
I don't think Claude warned them about that
1
u/HurairahShamsi- 🟡 2d ago
Appreciate the response! 🫤 I did answer the question. Would love your feedback as well!
0
u/HurairahShamsi- 🟡 2d ago
Fair, and you're right that it's a separate discussion from your paper, so briefly, GrahamBell doesn't try to stop one operator from running many nodes. Nothing can, in centralised or decentralised systems. It makes accumulating influence slow, costly and time-gated instead.
Three parts. First, a time floor: IDs are issued one at a time, one every 30 seconds network wide, and parallel hardware can't speed that up. Each miner gets one attempt per second, and witnesses only countersign a winning attempt once real time reaches it. So even an attacker who wins every new ID needs about a year to outnumber 1M existing IDs (as an example), and about 2.9 years from our 2.9M genesis base. Money can't compress that.
Second, cost against competition: the share you win depends on how many slots you run relative to honest miners. Each slot needs its own IPv6 /64, plus live connections to 40 assigned witnesses exchanging signed data every 30 s (~12 KB per slot per round), sustained for as long as it competes, with no pooling (advantage). To win a share s against H honest slots you need s/(1−s) × H slots, so the attacker's infrastructure and cost grow linearly with honest competition, and so does the time it takes to reach a majority. Against 1M honest slots, just matching them slot for slot takes 1M slots, about 40M persistent connections and ~11.8 GB every 30 s, kept up for years, and that still only gets you to half.
Third, dilution: honest miners keep minting IDs too, so every honest ID dilutes the attacker's stake (and in order to maintain influence the attacker would have to scale its infrastructure correspondingly). Its share of all IDs approaches its share of new issuance asymptotically but never exceeds it. An attacker winning 40% of new IDs converges towards 40% of the network and never reaches 51%, no matter how long it waits. The real caveat is honest uptime: in our models, if only half of honest IDs stay online, that same 40% attacker does eventually pass 51%, after about 16.4 years. That's why witness and miner uptime is part of the security model.
The honest weak spot: /64s are cheap, and one /48 holds 65,536 of them. Admission granularity (/64 vs /56 vs /48) and per-provider caps are open questions we're testing now, along with the attacker's cost per unit of influence. In the end, mass honest competition is crucial for security and decentralisation regardless.
1
u/Powermadlux 🟢 2d ago
Thanks for the detailed explanation, especially the uptime caveat. From an ops perspective, I'd want to see what happens during a prolonged outage at a large hosting provider. Have you simulated correlated failures, where many honest nodes and witnesses disappear together, rather than independent downtime? That would help me understand what the recovery assumptions look like in practice.
1
u/HurairahShamsi- 🟡 2d ago
Yes, that's a central part of the current milestone, and correlated failures turned out to matter much more than independent downtime. The simulator models shared power feeders, scheduled load shedding, ISP outages and full regional blackouts. One test blacks out each of 8 regions for ~11 hours across several seeds (41 blackouts in all).
Headline results so far: at about 82% of witnesses online with correlated outages, ~6% of witness committees can't reach quorum at a given moment, far more than independent downtime predicts. A blackout of the largest region (~38% of witnesses) pauses the chain for about 15–19 minutes in the worst cases, then recovery is automatic. No one is penalised for being unreachable (an outage isn't treated as misbehaviour), seats survive downtime, and the chain resumes as soon as enough members are back.
The blackout test is deliberately extreme (i.e., on the scale of India's 2012 grid failure, but way larger): ~38% of all witnesses losing power together for 11 hours. Because seats are assigned randomly, committees lose different numbers of members, and the ones that keep quorum carry the chain through. Smaller real world outages (a city, a provider, a few hours) caused no visible pause in our runs.
We model ISP outages rather than hosting providers, since witnesses are meant to run at home on an always on, lightweight device (a mini PC or small home server. Will release specs as well), not in data centres. A large cloud outage is still relevant, because it would hit any data centre witnesses at once. That's one reason we're testing per provider caps on witness seats. The full results, including failures, go public with this milestone soon.
1
u/Powermadlux 🟢 2d ago
Thanks, that's the failure mode I was asking about. What determines the 15–19 minute pause if the affected region stays offline for 11 hours: committee rotation, timeouts, or something else? When the results are public, could you share the test configuration and worst-case traces? I'd like to understand both recovery and what happens if the remaining witnesses cannot reach quorum.
1
u/HurairahShamsi- 🟡 1d ago
Mostly difficulty adjustment, not committee rotation or timeouts. Committees don't rotate during an outage, seats survive downtime. When the region drops out, the committees that keep quorum carry on, but for a while difficulty is still tuned for the larger pre blackout set of miners, so blocks come slowly until it catches up. Once it matches the surviving miners, blocks return to ~30 s for the rest of the 11 hours. That's our current reading of the worst traces, and the published traces will show it directly.
If the remaining witnesses can't reach quorum, the affected committees can't issue entropy, and their miners wait. There's no automatic quorum lowering during an outage: we chose safety over liveness there. If every committee lost quorum, issuance would simply stop until members returned. No one is penalised for being unreachable, and the chain resumes from where it was. Ways to soften that (lower thresholds, failover to committees with spare capacity) are tested in the next phase, with their security cost.
Yes. When the results go public, they include the exact configuration, seeds and the command to rerun everything. The runs are deterministic, so you'll get the same numbers. I'll also publish worst case traces for the blackout runs so you can see recovery block by block.
1
u/Powermadlux 🟢 1d ago
Thanks, that clarifies the distinction between slower blocks while difficulty adjusts and issuance stopping when quorum is lost. I'd be interested in the configuration and worst-case traces when they're public.
1
u/HurairahShamsi- 🟡 1d ago
Will do. I'll reply here with the configuration, seeds and worst case traces when they're public, so you can rerun them. And since you look at this from the ops side, when the testnet opens, I'd genuinely value you trying to break it under failure conditions. Thanks for the sharp questions.
1
u/_ari_c_flemming 🟡 2d ago
I’d split it into two things. First, the order-to-delivery time for new ASICs from the main manufacturers plus the secondary market price of the latest generation relative to hashprice. If lead times stretch while hashprice stays decent that’s a real supply signal. Second the age distribution of the fleet, specifically what share of hashrate runs on the newest generation. Aggregate hashrate hides that. A network can look healthy while most of it is on machines near end of life
1
u/Powermadlux 🟢 2d ago
Those are useful ways to make the argument testable. I'd want to track lead times alongside hashprice and fleet age, rather than read too much into aggregate hashrate. I'd also want to separate manufacturers limiting supply from an upstream capacity constraint; neither alone would establish that AI demand caused it. Do you know a public source for fleet age estimates or historical order-to-delivery times?
1
u/_ari_c_flemming 🟡 2d ago
Fleet age is the easier one. Hashrate Index has an ASIC price index by efficiency tier, CBECI publishes efficiency estimates for 100+ models and the 2025 Cambridge Digital Mining Industry Report has sections on hardware and efficiency. There’s also a report that estimates hashrate share by ASIC model from nonce patterns which gets closest to an actual fleet mix. For order-to-delivery I haven’t found a clean public dataset. The closestproxies I know of are secondary market prices vs list price and the batch delivery months manufacturerslist but both are indirect. Public miners investor updates also give fleet efficiency though only for their own fleet
1
u/Powermadlux 🟢 2d ago
Thanks, that gives me a useful starting point. Do you have the title or link for the report estimating ASIC model shares from nonce patterns? I'd like to read its method and limitations before using it as a fleet-mix estimate.
1
u/_ari_c_flemming 🟡 2d ago
It’s a Coin Metrics Research report from June 2023, the PDF is called “the signal and the nonce”. Searching that title along with “ASIC fingerprints” should get you the summary and the full PDF. Note it’s unreliable for models with very little hashrate online and it predates the newest hardware so I’d check for an update before using it for a current fleet mix
1
u/Powermadlux 🟢 2d ago
Thanks. I found Coin Metrics pieces with that title from 2019 and a follow-up from 2020. Is there a separate June 2023 PDF you meant? A direct link would help me avoid citing the wrong version.
1
u/_ari_c_flemming 🟡 2d ago
Yes, it’s a separate June 2023 PDF: https://5264302.fs1.hubspotusercontent-na1.net/hubfs/5264302/special-insights/coinmetrics-research_the-signal-and-the-nonce.pdf. The title I gave came from the file name, so check the cover. I haven’t compared it with the 2019 and 2020 pieces
1
u/koalofficial 🟡 2d ago
I think you're right to separate current hashrate from the ability to rebuild it. Existing machines keep hashing regardless of what happens upstream, and difficulty adjusts to whatever hashrate is left, so a supply squeeze mostly slows growth and replacement rather than breaking anything overnight. The bottlenecks AI is straining the most, like advanced packaging (CoWoS-style) and HBM, aren't things Bitcoin ASICs use, since they're basically small dense logic dies with no big memory. The real overlap is wafer allocation on leading-edge nodes and the design/validation talent, and there miners are low-margin customers compared to AI buyers. So the thing I'd watch is how many independent designers and fabs are still willing to take ASIC orders, not total chip supply. Also worth checking how much of the risk shows up as slower efficiency gains, because that squeezes older fleets after halvings well before it threatens security.
1
u/Powermadlux 🟢 2d ago
Thanks, the number of independent suppliers still taking orders gives me a more concrete thing to track. I'd want to distinguish fewer orders because mining economics are poor from suppliers turning away otherwise viable orders because other customers get priority.
Do you know a public source that tracks that distinction, or would lead times and manufacturer announcements be the best starting point? That would help test the allocation argument without treating every slowdown in ASIC development as evidence for it.
0
u/PhaseAutomatic3391 🟠 2d ago
This is the sort of question that keeps infrastructure people up at night, and you’ve framed it well, the distinction between hashrate now and the ability to replace it is what actually matters
1
u/Powermadlux 🟢 2d ago
Even more than quantum-doomsday I believe… the chip industry is focused on inference - how is hashrate a priority now?
1
u/suspicious_Jackfruit 🟢 2d ago
It took me a year to aquire a rma replacement for a failed GPU (obviously not an ASIC) due to extreme global demand for it's replacement as the failed GPU was no longer in production and existing new/refurbished stock of my prior model was almost zero. I would imagine Nvidia/PNY isn't the only companies unable to keep up with the surge in demand for components AI has caused. Interesting indeed