What would happen to Bitcoin if the world were without internet for a day?

Written by: Liam 'Akiba' Wright & translated by: Chopper, Foresight News

Imagine the global internet backbone collapsing in a single day.

Whether it's human error, a catastrophic software vulnerability, a malicious computer virus, or direct military conflict—what would Bitcoin's fate be if the physical internet hub connecting the world suddenly went dark?

If Frankfurt, London, Virginia, Singapore, and Marseille simultaneously lost internet access, the Bitcoin network would split into three independent partitions.

Communications across the Atlantic, the Mediterranean, and major trans-Pacific shipping routes would cease, and the Americas, Europe and Africa, the Middle East, and Asia and Oceania would each form their own independent transaction histories until network connectivity was restored.

Within each partition, miners continue to produce blocks based on their remaining computing power. Following the goal of producing blocks every 10 minutes, a region with 45% hash rate produces approximately 2.7 blocks per hour, a region with 35% hash rate produces approximately 2.1 blocks per hour, and a region with 20% hash rate produces approximately 1.2 blocks per hour. Since nodes cannot exchange block headers or transaction data across partitions, each region will unknowingly extend into a valid blockchain independently. Ultimately, as time and computing power distribution change, the length of the natural fork will continue to grow. This partitioning rhythm makes chain splitting an inevitable result. We assigned approximate hash rate percentages to each region: Americas 45%, Asia and Oceania 35%, and Europe and Africa 20%, using this as a benchmark for simulation. The Americas partition adds approximately 6 blocks every two hours, the Asia-Pacific region adds approximately 4-5 blocks, and the Europe and Africa region adds approximately 2-3 blocks. After a full day, the number of chain-split blocks will exceed 100, exceeding the range of normal reorganizations, forcing the service to treat regional confirmations as temporary confirmations. The potential reorganization depth of failed partitions increases linearly with isolation time. The local mempool will split immediately. Transactions broadcast in New York cannot reach Singapore, so recipients outside the sender's partition will not see the transaction until the network recovers. The transaction fee market within each partition exhibits localized characteristics. Users compete for limited block space based on the local hash rate, therefore, transaction fees will rise fastest in regions with a low hash rate but high demand. When transaction confirmation loses global finality, exchanges, payment processors, and custodian wallets typically suspend withdrawals and on-chain settlements; Lightning Network counterparties face uncertainty—transactions confirmed in minority partitions may become invalid. Automatic Reconciliation After Network Recovery When network connectivity is restored, nodes initiate an automatic reconciliation process: each node compares different blockchains and then reassembles to the valid chain with the highest cumulative workload. The actual costs are mainly reflected in three aspects: Reorganization will cause blocks in minority partitions to become invalid, with the invalidation depth depending on the duration of the split; Transactions that were only confirmed on the failed chain need to be rebroadcast and prioritized; Exchanges and custodians need to perform additional operational checks before restoring services. During a 24-hour network split, dozens to hundreds of blocks in minority partitions may be orphaned after reconnection. Related services also require several additional hours to rebuild mempools, recalculate balances, and restore withdrawal functionality. Because fiat currency channels, compliance checks, and channel management require manual review, the full normalization of economic activity often lags behind the protocol level. Simulating isolation using "reachable hash rate percentage" 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 approximately 1.8 blocks per hour. This means that a standard 6-confirmation payment within that partition risks becoming invalid after approximately 3 hours and 20 minutes—if the remaining 70% of the network builds a longer chain, these 6 blocks may become orphaned. In a near 50/50 split scenario, the cumulative workload of the two partitions is similar. Even a brief split will result in both partitions having competing "confirmed" transaction histories, and the reconnection result will be random. In an 80/20 split scenario, the majority partition almost always wins; the approximately 29 blocks produced by the minority partition in a day will be isolated during the merge, causing many confirmed transactions in that region to be reversed.

The risk of reorganization is the product of "time" and "minority partition hash rate". The most dangerous situation is "long-term isolation + near-equal hash rate split".

The role of existing resilience tools

There are currently many tools that can improve network resilience, which will affect the actual impact after disconnection:

Alternative transmission methods such as satellite downlink, high-frequency radio relay, delay-tolerant networks, mesh networks, and Tor bridging can transmit block headers or streamline transaction flows on damaged routes.

These paths have narrow bandwidth and high latency, but even intermittent cross-partition data transmission can reduce fork depth by allowing some blocks and transactions to permeate other partitions. The diversity of node interconnections within mining pools, as well as their geographical distribution, can increase the probability of some data spreading globally through side channels, thereby limiting the depth and duration of reorganization when the backbone network recovers. During a network split, the operational guidelines for market participants are straightforward: Inter-partition settlements should be suspended, all transaction confirmations should be considered temporary, and fee estimation mechanisms should be optimized to address local fee spikes; Exchanges can switch to proof-of-reserve mode, extend confirmation thresholds to address minority partition risks, and issue clear policies—setting the required number of confirmations based on the isolation period; Wallets should clearly inform users of regional finality risks, disable automatic channel rebalancing, and queue time-sensitive transactions for rebroadcasting after network recovery; Miners should maintain diverse upstream connections and avoid manually modifying the standard "longest chain selection rule" during the coordination process. From a design perspective, the protocol itself is sustainable—nodes automatically converge to the chain with the largest accumulated workload after reconnection. However, the user experience during the split will be significantly compromised because the economic finality depends on the consistent propagation of global data. In the worst-case scenario of a multi-hub outage lasting up to a day, the most likely outcomes are: a temporary collapse in cross-border availability, a sharp and uneven increase in transaction fees, and a deep reorganization leading to the failure of regional confirmations. Once the network is restored, the software will deterministically repair the ledger, and related services will resume full functionality after operational checks. The final step is to reopen withdrawals and Lightning Network channels once the balance and transaction history on the winning chain are consistent. What if the split could never be repaired? What would happen if the backbone network hubs mentioned at the beginning could never be restored? In this dystopian scenario, the Bitcoin we know would cease to exist. Instead, there would be permanent geographical partitions, functioning as independent Bitcoin networks: sharing the same rules but unable to communicate with each other. Each partition would continue mining, adjusting its difficulty at its own pace, and developing its own independent economic system, order book, and fee market. Without restoring connectivity or manually coordinating the selection of a single chain, there would be no mechanism to reconcile the transaction histories of different partitions. Consensus and Difficulty Adjustment Before each partition completes its next round of difficulty adjustments over 2016 blocks, block times will be faster or slower depending on the reachable hash rate. After the adjustment, each partition will stabilize its local block time at around 10 minutes. Based on previous hash rate estimates, the initial difficulty adjustment times for each partition are as follows: After the initial adjustment, each partition will maintain a block time of approximately 10 minutes, followed by independent halving and difficulty adjustments.

Without transoceanic connectivity, each region would require 31, 40, and 70 days respectively to reach its first difficulty reset target.

Due to the varying speeds at which the halving height was achieved before the first difficulty adjustment, the halving dates for each partition will gradually deviate from the actual time.

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

Within each partition, the 21 million coin supply cap per chain remains in effect.

However, globally, the total Bitcoin supply across all regions will exceed 21 million – because each chain awards block rewards independently. This creates three incompatible BTC assets at the economic level: they share addresses and private keys but have different sets of unspent transaction outputs (UTXOs). The private key can control tokens across all regions 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-region payments cannot propagate, and any attempt to pay users in other regions will fail to reach the recipient. The fee market will reach local equilibrium: During the long period before the first difficulty adjustment, partitions with lower hashrate percentages will experience greater capacity constraints, which will return to normal after the difficulty adjustment. Cross-partition Lightning Network channels cannot be routed: Hash Time Locked Contracts (HTLCs) will time out, counterparties will issue committed trades, and closing channels only applies to the local partition, causing cross-partition liquidity to stagnate. Security, Markets, and Infrastructure: Each partition's security budget equals the sum of its local hashrate and fees. Regions with only the top 20% hashrate before the split will have significantly lower attack costs than the original global network. In the long term, miners may migrate to partitions with higher token prices and lower energy costs, thus altering the security landscape of each partition. Because block headers cannot be transmitted between regions, an attacker in one region cannot tamper with the transaction history of another region, thus limiting the attack to a specific area. Exchanges will become regionalized, and trading pair codes will diverge—in reality, different prices will emerge, such as BTC-A (Americas version), BTC-E (Europe and Africa version), and BTC-X (Asia and Oceania version), even though each region still refers to it as BTC. Fiat currency deposit and withdrawal channels, custody services, derivatives markets, and settlement networks will focus on chains in specific regions. Index providers and data service providers will need to choose a single chain for each platform or publish comprehensive data from multiple regional chains. Cross-chain assets and oracles that rely on global data sources will either become ineffective or split into regional versions.

Protocol rules will remain consistent without intra-partition coordination changes, but an upgrade in one partition will not take effect in other partitions, leading to a gradual deviation of the rule set in the long run.

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

Can partitions be reorganized without a hub connection?

If the communication path can never be restored, convergence at the protocol level will be impossible.

The only way to return to a single ledger is through social and operational means: for example, coordinating parties to choose a chain for one partition as orthodoxy, while abandoning or replaying transactions in other partitions.

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

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

Key Operational Points: We must treat permanent splits as "hard forks that share the history before the split": Manage private keys properly to ensure secure spending of the split-progressed tokens; Use only transaction outputs unique to a single zone to avoid accidental replay of transactions across different zones; Establish independent accounting, pricing mechanisms, and risk control systems for each zone. Miners, exchanges, and custodians should select a primary zone, issue chain identifiers, and formulate deposit and withdrawal policies for each chain. In short, if the backbone network hub can never be restored and there is no alternative path to bridge the communication gap, Bitcoin will not die; it will evolve into multiple independent Bitcoin networks that can never be reunited.