What would happen to bitcoin if the entire world lost internet access for a day?

Even if World War III breaks out, Bitcoin will not disappear.

Written by: Liam 'Akiba' Wright

Translated by: Chopper, Foresight News

Imagine the global internet backbone collapsing in a single day.

Whether due to human error, catastrophic software bugs, malicious computer viruses, or direct military conflict—if the physical internet exchange hubs connecting the world suddenly go dark, what fate awaits Bitcoin?

If Frankfurt, London, Virginia, Singapore, and Marseille all go offline simultaneously, the Bitcoin network would split into three independent partitions.

Communications across the Atlantic, Mediterranean, and major trans-Pacific routes would come to a halt, with the Americas, Euro-African continent, Middle East, and Asia-Pacific regions each forming their own independent transaction histories until network connectivity is restored.

Within each partition, miners will continue to produce blocks based on remaining hash power

According to the 10-minute block production target, the region with 45% of the hash rate would produce about 2.7 blocks per hour, the region with 35% about 2.1 blocks, and the region with 20% about 1.2 blocks. Since nodes cannot exchange block headers or transaction data across partitions, each region would unknowingly extend its own valid blockchain independently.

Ultimately, as time passes and hash rate distribution changes, the natural fork length will continue to grow.

This partitioning rhythm makes chain splits inevitable. We assign approximate hash rate shares to each region: Americas 45%, Asia-Pacific 35%, Euro-African continent 20%, and simulate based on this.

The Americas partition would add about 6 new blocks every two hours, Asia-Pacific about 4-5, and Euro-African continent about 2-3.

After a full day, the number of split blocks would exceed a hundred, far beyond the range of normal reorganization, forcing services to treat regional confirmations as temporary.

The potential reorganization depth of failed partitions increases linearly with isolation time

Local mempools would immediately split. Transactions broadcast in New York would not reach Singapore, so recipients outside the sender's partition would not see the transaction at all until the network is restored.

The fee market within each partition would become localized. Users would compete for limited block space with the hash rate in their region, so in regions with low hash rate but high demand, fees would rise fastest.

When transaction confirmations lose global finality, exchanges, payment processors, and custodial wallets would typically suspend withdrawals and on-chain settlements; Lightning Network counterparties would face uncertainty—transactions confirmed in minority partitions may become invalid.

Automatic coordination after network restoration

When network connectivity is restored, nodes will initiate an automatic coordination process: each node will compare different blockchains and reorganize to the valid chain with the greatest accumulated work.

The actual costs are mainly reflected in three aspects:

• Reorganization will invalidate blocks from minority partitions, with the depth of invalidation depending on the duration of the split;
• Transactions confirmed only on failed chains need to be rebroadcast and reprioritized;
• Exchanges and custodians must perform additional operational checks before resuming services.

In a 24-hour network split, after reconnection, dozens to hundreds of minority partition blocks may be orphaned. Related services may need several more hours to rebuild mempools, recalculate balances, and restore withdrawal functions.

Because fiat channels, compliance checks, and channel management require manual review, full normalization of economic activity often lags behind the protocol layer.

Simulating isolation status by "reachable hash rate share" rather than the number of hubs makes its dynamic changes easier to understand:

• When 30% of the hash rate is isolated, the minority partition produces about 1.8 blocks per hour. This means that a standard 6-confirmation payment in this partition faces invalidation risk after about 3 hours and 20 minutes—if the remaining 70% of the network builds a longer chain, these 6 blocks may be orphaned.
• In a near 50/50 split scenario, the cumulative work of the two partitions is similar, so even a short split can result in both sides having "confirmed" competing transaction histories, and the outcome after reconnection is random.
• In an 80/20 split scenario, the majority partition will almost certainly win; the minority partition's approximately 29 blocks produced in a day will be orphaned upon merging, causing many confirmed transactions in that region to be reversed.

Reorganization risk is the product of "time" and "minority partition hash rate"; the most dangerous situation is "long isolation + near-equal hash rate split"

The role of existing resilience tools

There are already various tools to enhance network resilience, which will affect the actual impact after disconnection:

Satellite downlinks, high-frequency radio relays, delay-tolerant networks, mesh networks, and Tor bridges can transmit block headers or streamlined transaction flows over damaged routes.

These paths have narrow bandwidth and high latency, but even intermittent cross-partition data transmission can allow some blocks and transactions to penetrate other partitions, reducing fork depth.

The diversity of interconnections between mining pool nodes and their geographical distribution can increase the probability of some data being globally propagated via side channels, thus limiting the depth and duration of reorganization when the backbone is restored.

So, during network splits, the operational guidelines for market participants are straightforward:

• Suspend cross-partition settlements, treat all transaction confirmations as temporarily valid, and optimize fee estimation mechanisms for local fee spikes;
• Exchanges can switch to proof-of-reserves mode while suspending withdrawals, extend confirmation thresholds to address minority partition risks, and publish clear policies—setting required confirmation counts based on isolation duration;
• Wallets should clearly warn users of regional finality risks, disable automatic channel rebalancing, and queue time-sensitive transactions for rebroadcast after network restoration;
• Miners should maintain diverse upstream connections and avoid manually modifying the standard "longest chain selection rule" during coordination.

By design, the protocol itself can survive—nodes will automatically converge to the chain with the greatest accumulated work after reconnection.

But user experience during splits will be severely degraded, as economic finality depends on the consistent global propagation of data.

In the worst-case scenario of multi-hub disconnection lasting a day, the most likely outcomes are: temporary collapse of cross-border availability, sharp and uneven fee increases, and deep reorganizations causing regional confirmation failures.

After network restoration, the software will deterministically repair the ledger, and related services will resume all functions after completing operational checks.

The final step is: once balances and transaction histories on the winning chain are consistent, withdrawals and Lightning Network channels are reopened.

If the split can never be repaired

What if the backbone hubs mentioned at the beginning can never be restored? In this dystopian scenario, the Bitcoin we know would cease to exist.

Instead, there would be permanent geographic partitions, each like an independent Bitcoin network: sharing the same rules but unable to communicate with each other.

Each partition would continue mining, adjust difficulty at its own pace, and develop independent economic systems, order books, and fee markets. Without restored connectivity or manual coordination to select a single chain, there would be no mechanism to reconcile the transaction histories of different partitions.

Consensus and Difficulty Adjustment

Before each partition completes the next round of 2016 block difficulty adjustment, block times will be faster or slower depending on reachable hash rate. After adjustment, each partition will restabilize local block times to around 10 minutes.

Based on previous hash rate share estimates, the time for each partition's first difficulty adjustment is as follows:

After the first adjustment, each partition will maintain about 10-minute blocks, then independently proceed with halving and difficulty adjustments.

Without transoceanic connections, each region would need 31, 40, and 70 days respectively to reach its first difficulty retarget

Because the speed of reaching the halving height differs before the first difficulty adjustment, the halving dates of each partition will gradually diverge in real time.

Supply and "Definition of Bitcoin": Fees, Mempools, and Payments

Within each partition, the 21 million supply cap for a single chain remains valid. But globally, the total number of Bitcoins across all partitions will exceed 21 million—because each chain will independently issue block rewards.

This creates three economically incompatible BTC assets: they share addresses and private keys but have different unspent transaction output (UTXO) sets.

Private keys can control tokens in all partitions simultaneously: if a user spends the same UTXO in two regions, both transactions are valid on their respective local chains, ultimately forming "split tokens": they share the same pre-split history but have completely different post-split histories.

• Mempools will be permanently localized, cross-partition payments cannot propagate, and any attempt to pay users in other partitions will not reach the recipient.
• The fee market will reach local equilibrium: during the long period before the first difficulty adjustment, partitions with lower hash rate will have tighter capacity, but will return to normal after adjustment.
• Cross-partition Lightning Network channels cannot be routed: HTLCs will time out, counterparties will broadcast commitment transactions, and channel closure operations will only be valid in the local partition, with cross-partition liquidity coming to a standstill.

Security, Markets, and Infrastructure

The security budget of each partition equals its local hash rate and total fees. For regions with only 20% of the pre-split hash rate, the cost of attack will be much lower than the original global network.

In the long term, miners may migrate to partitions with "higher token prices and lower energy costs," thereby changing the security landscape of each partition.

Since block headers cannot be transmitted between partitions, an attacker in one partition cannot tamper with another partition's transaction history, so attacks will be limited to specific regions.

• Exchanges will become regionalized, and trading pair codes will diverge—in practice, there will be BTC-A (Americas version), BTC-E (Euro-African version), BTC-X (Asia-Pacific version), etc., each with different prices, even though all partitions still call it BTC.
• Fiat on/off ramps, custodial services, derivatives markets, and settlement networks will focus on the chain of a specific region. Index providers and data services must choose a single chain for each platform or publish composite data for multiple regional chains.
• Cross-chain assets and oracles that rely on global data sources will either fail or split into regional versions.

Protocol rules will remain consistent unless changed through intra-partition coordination, but an upgrade in one partition will not take effect in others, leading to gradual divergence of rule sets over time.

Mining pool software, block explorers, and wallets will need to build independent infrastructure for each partition, and multi-hosted services cannot coordinate balances across chains without manual strategies.

Can partitions reorganize without hub connections?

If communication paths can never be restored, protocol-level convergence will be impossible.

The only way to return to a single ledger is through social and operational means: for example, coordinating all parties to select one partition's chain as canonical, while abandoning or replaying transactions from other partitions.

After weeks of deep divergence, automatic reorganization to a single chain is no longer feasible.

Operational Points

We must treat permanent splits as "hard forks sharing pre-split history":

• Properly manage private keys to ensure safe spending of post-split tokens;
• Use only transaction outputs unique to a single region to avoid accidental replay of transactions across partitions;
• Establish independent accounting, pricing mechanisms, and risk control systems for each partition.

Miners, exchanges, and custodians should select a main partition, publish chain identifiers, and formulate deposit and withdrawal policies for each chain.

In short, if backbone hubs can never be restored and no alternative paths fill the communication gap, Bitcoin will not disappear—it will evolve into multiple independent Bitcoin networks that can never be merged again.