Inside Bitcoin’s 24-hour race to survive a global internet blackout

Imagine the world’s internet backbone collapsing in a day.

What would happen to Bitcoin if the physical internet exchange hubs that connect the world suddenly went out, whether due to human error, a catastrophic software bug, a rogue computer virus, or full-on kinetic warfare?

If Frankfurt, London, Virginia, Singapore, and Marseille go offline at the same time, Bitcoin will be split into three partitions.

Traffic on major routes across the Atlantic, Mediterranean, and Pacific Oceans has been disrupted, and until links are restored, the Americas, Europe, Africa, the Middle East, Asia, and Oceania will have to look back on their history individually.

Block generation continues within each partition according to the reachable hashrate.

With a global goal of 10 minutes, a region with 45 percent of the hashrate will generate approximately 2.7 blocks per hour, 35 percent will generate approximately 2.1 blocks, and 20 percent will generate approximately 1.2 blocks per hour. Because nodes cannot exchange headers or transactions between partitions, each region advances a valid chain without being aware of other regions.

As a result, fork depth naturally increases, increasing over time and with hashrate distribution.

Divided rhythms allow for divergence to occur mechanically. Let’s assign a rough hashrate average to each region. The modeling uses baseline distributions of 45%, 35%, and 20% for the Americas, Asia and Oceania, and Europe and Africa, respectively.

The Americas cohort adds approximately 6 blocks every 2 hours, while Asia and Oceania adds approximately 4-5 blocks per hour, and Europe and Africa approximately 2-3 blocks per hour.

After an hour, the ledger is already different by two digit blocks.

After half a day, the difference widens to the low hundreds.

After a full day, the difference between the chains reaches several hundred blocks. This goes beyond routine reorganization and forces the service to treat regional confirmations only as provisional.

Local menpools are quickly split. Transaction broadcasts in New York will not reach Singapore, so receivers outside the sender’s partition will not see anything until the route is restored.

Within each partition, the fee market is local. Users compete for limited block space with local hashrates, so prices rise fastest when hashrates are lowest and demand is high.

Exchanges, payment processors, and custodial wallets typically suspend withdrawals and on-chain payments when confirmations lose global finality and face uncertainty regarding commitment transactions that Lightning counterparties confirm in minority partitions.

Once the route is returned, the node will start auto-adjusting.

Each node compares the chains and reorganizes them into a valid chain with the most cumulative work.

Actual costs fall into three categories:

1. Reorganization depth to invalidate minority partition blocks.
2. The task of rebroadcasting and reprioritizing transactions that were previously “confirmed” only on the losing branch.
3. Operational checks that exchanges and custodians perform before restarting.

A 24-hour fracture can leave tens to hundreds of minority partition blocks orphaned upon recovery, and the service takes additional time to rebuild the menpool, recalculate balances, and re-enable withdrawals.

Full economic normalization often lags behind protocol convergence, as statutory rails, compliance checks, and channel management require human review.

Dynamics are easier to infer by modeling separation as a percentage of reachable hashrate than by counting hubs.

If 30 percent of the hashrate were separated, the minority side would add approximately 1.8 blocks per hour. This means that as the remaining 70% of the network builds longer chains, these 6 blocks can become orphaned, so a standard 6-confirmation payment within that partition is at risk after about 3 hours and 20 minutes.

With a near 50/50 split, both partitions accumulate similar work, so even short splits create conflicting “acknowledged” histories on both sides, making the outcome stochastic upon reconnection.

In an 80-20 split, the majority split will almost certainly win. A small partition’s blocks (approximately 29 after a day) become orphaned during the merge, and many transactions confirmed in that region are undone.

Resilience tools do exist, and they shape real-world impact.

Alternative transports such as satellite downlinks, high-frequency wireless relays, delay-tolerant networking, mesh networks, and Tor bridges can carry headers and minimal transaction flows across damaged routes.

These paths are narrower and have higher latency, but even intermittent propagation between partitions allows some blocks and transactions to leak, reducing fork depth.

The diversity of minor peerings, multihomed exchange infrastructures, and the geographic spread of pools increases the likelihood that at least some work propagates globally through side channels, thereby limiting the depth and duration of reorganization when the backbone returns.

The operational guidance for market participants during network disconnections is simple.

• Suspend cross-partition payments, treat all confirmations as provisional, and harden rate estimates against local spikes.
• Exchanges can switch to proof-of-reserve attestation without active withdrawals, extend confirmation thresholds to account for minority partition risk, and issue deterministic policies that map separation periods to the desired number of confirmations.
• Wallets can display clear warnings about regional finality, disable automatic channel rebalancing, and queue time-sensitive payments for rebroadcast upon recovery.
• Miners should maintain diverse upstream connections and avoid manual overrides that deviate from standard longest chain selection rules during the reconciliation process.

This protocol survives by design because when nodes reconnect, they converge on the chain containing the most accumulated work.

Since economic finality depends on consistent global propagation, the user experience is not as good during splits.

The most reliable worst-case scenario for a one-day multihub outage is a temporary breakdown in cross-border usability, a sudden and uneven price shock, and a major reorganization that disables regional verification.

Once the link is restored, the software resolves the ledger deterministically and the service restores full functionality after a behavioral check.

The final step is to withdraw and restart the channel once the balance and history are consistent on the winning chain.

This is a recoverable case, but what if the fracture does not heal?

What will happen to Bitcoin during World War III?

Now, what if the backbone hub I mentioned at the beginning never comes back?

Now, in that dystopian scenario, Bitcoin as we know it will not reappear.

You get a permanent geographic partition that behaves like a separate Bitcoin network, sharing the same rules, but with no communication between the networks.

Each partition continues to mine, adjusts difficulty on its own schedule, and develops its own economy, order book, and fee market. There is no mechanism to adjust history without restoring connectivity or adjusting manual selection of a single chain.

Its steady state is:

agreement and difficulty

• Until each partition reaches the next 2016 block retargeting, the block time will be slower or faster depending on the reachable hashrate. After retargeting, each partition will be centered locally after approximately 10 minutes.
• Using the approximate shares, the expected time to first retarget is:

After the initial retargeting, each partition will generate blocks in about 10 minutes and then continue to be halved and adjusted individually.

Half-life dates vary in real time because each region reaches half-life height at a different rate before the first retargeting.

Supply and “What is BTC”: Fees, Menpool, Payments

Within each partition, the 21 million per chain limit still applies. As each chain continues to issue its own subsidies, the total number of coins across all partitions worldwide is over 21 million. Economically, this creates three incompatible BTC assets that share an address and key but have different UTXO sets.

The key controls coins on all partitions simultaneously. If a user spends the same UTXO in two regions, both spends will be valid on their local chains, producing a permanent “split coin” with the same pre-split and post-split history.

• Menpool is forever local. Payments between partitions do not propagate. If you try to make a payment to someone in another partition, it will never reach that person.
• The rate market settles into a local equilibrium. Partitions with lower hashrates tend to have smaller capacities during long periods before retargeting, and normalize after difficulty adjustment.
• Lightning channels that span users across different partitions cannot be routed. HTLC times out, peer publishes commitment, and closure is checked only within the local partition. Fluidity between partitions gets stuck.

Security, markets and infrastructure

The security budget for each partition corresponds to the local hash rate and price. A region with a pre-split hashrate of 20% has a lower absolute cost of attack than a global network. Over time, miners may move to partitions with higher coin prices and lower energy, and the security profile may change again.

Without header paths between partitions, an attacker on one partition cannot overwrite the history on another partition. Therefore, the attack is confined within a specific area.

• Interactions will be regional. The ticker branches. You can essentially get prices for BTC-A, BTC-E, and BTC-X, even though locally they are all called BTC.
• Fiat entry, custody, derivatives and payment rails are specialized in regional chains. Index providers and data vendors must choose one chain per venue or publish multiple composites.
• Bridged assets and oracles that relied on global data feeds are split or forked into regional versions.

Protocol rules remain the same unless the partition adjusts the rule changes. Upgrades adopted in one partition do not take effect elsewhere, resulting in ruleset drift over time.

Pool software, explorers, and wallets run per-partition infrastructure. Multihomed services cannot reconcile cross-chain balances without manual policies.

Is it possible to align partitions without these hubs?

If the communication path is not restored, protocol convergence is not possible. The only way to return to a single ledger is through social and operational means, such as adjusting and selecting one partition’s chain as canonical and discarding or redoing the other partitions.

If a large divergence occurs after a few weeks, it is not practical to automatically reorganize it into a single history.

Operational points

Permanent fractures should be treated exactly like hard forks with shared pre-split history. Managing keys allows you to use split coins securely, avoid accidental replays across partitions with outputs that only exist in one region, and maintain separate accounting, pricing, and risk management for each partition.

Miners, exchanges, and custodians must choose a home partition, publish chain identifiers, and document deposit and withdrawal policies specific to each chain.

In other words, even if these hubs never return and there are no alternative paths to fill the gap, Bitcoin will not disappear. It becomes several independent Bitcoins that never recombine.