If a global Internet shutdown were to occur for a day, how would Bitcoin survive the Internet outage crisis?

Original Article Title: Inside Bitcoin's 24-Hour Race to Survive a Global Internet Blackout

Original Article Author: Liam 'Akiba' Wright, CryptoSlate

Original Article Translation: Chopper, Foresight News

Imagine a scenario where the global internet backbone collapses within a day.

Whether due to human error, a catastrophic software vulnerability, a malicious computer virus, or direct military conflict— if the physical Internet exchange hubs connecting the world were to suddenly plunge into darkness, what fate would await Bitcoin?

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

Communication across the Atlantic, Mediterranean, and major trans-Pacific routes would come to a standstill, with the Americas, Europe/Africa, the Middle East, and Asia each forming their own independent transaction histories until network connectivity is restored.

Within each partition, miners would continue to produce blocks based on remaining hashrate

Targeting a block time of 10 minutes per block, the region with 45% hashrate would produce approximately 2.7 blocks per hour, the 35% hashrate region around 2.1 blocks, and the 20% hashrate region around 1.2 blocks. Since nodes cannot exchange block headers or transaction data across partitions, each region would autonomously extend a valid blockchain in ignorance of the others.

Over time, as hashrate distribution and time progress, the natural fork length would continuously increase.

This partitioning rhythm leads to chain splits being an inevitable outcome. We have allocated approximate hashrate percentages to each region: Americas 45%, Asia 35%, Europe/Africa 20%, used as a benchmark for simulation.

The Americas partition would see approximately 6 new blocks every two hours, Asia with 4-5, and Europe/Africa with 2-3.

After a full day, the number of blocks in the chain split would exceed one hundred, surpassing the normal bounds of reorganizations, forcing services to treat regional confirmation as temporary.

The potential reorganization depth of a failed partition increases linearly with isolation time

The local mempool will immediately split. A transaction broadcasted in New York cannot reach Singapore, so the recipient outside the sender's partition will not see the transaction at all until the network recovers.

Each partition's fee market will exhibit localization characteristics. Users must compete with the local hashrate for limited block space, so in regions with low but high-demand hashrate proportion, fees will rise the fastest.

When transaction finality is lost globally, exchanges, payment processors, and custodial wallets usually pause withdrawals and on-chain settlements; counterparties in the Lightning Network will face uncertainty—transactions confirmed in minority partitions may become invalid.

Automatic Reconciliation After Network Recovery

Upon network reconnection, nodes will initiate an automatic reconciliation process: each node will compare different blockchains and then reorganize to the valid chain with the most accumulated work.

The actual costs are mainly reflected in three areas:

· Reorganization will cause blocks in minority partitions to become invalid, with the depth of invalidation depending on the duration of the split;

· Transactions that were only confirmed on the failed chain need to be rebroadcasted and prioritized;

· Exchanges and custodians need to perform additional operational checks before resuming services.

During a 24-hour network split, after reconnecting, dozens to hundreds of blocks in minority partitions may be orphaned. Related services will also need several additional hours to rebuild the mempool, recalculate balances, and restore withdrawal capabilities.

Due to the manual review required for fiat channels, compliance checks, and channel management, the full normalization of economic activities often lags behind the protocol layer.

Simulating the isolated state through "reachable hashrate proportion" rather than the number of hubs makes it easier to understand its dynamic changes:

· When 30% of the hashrate is isolated, a minority partition produces approximately 1.8 blocks per hour. This means that a standard 6-confirmation payment within the partition will face the risk of invalidation 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, where two partitions have similar accumulated work, even a brief split will result in both having a competitive transaction history marked as "confirmed," leading to random outcomes upon reconnection.

· In an 80/20 split scenario, the majority partition almost inevitably wins; a minority partition that produces approximately 29 blocks in a day will be orphaned upon merging, causing many confirmed transactions in that area to be reversed.

Reorganization risk is the product of "time" and "minority partition hash rate," with the most dangerous scenario being "long-time isolation + near-equal hash rate split."

Role of Existing Resilience Tools

There are currently various tools in place to enhance network resilience, which impact the actual impact of disconnection:

Alternative transmission methods such as satellite downlinks, high-frequency radio relays, delay-tolerant networking, mesh networks, and Tor bridges can deliver block headers or compacted transaction flows over damaged routes.

These paths have narrow bandwidth and high latency, but even intermittent inter-partition data transfers can reduce fork depth by allowing some blocks and transactions to permeate to other partitions.

Node interconnect diversity within mining pools and the geographical distribution of mining pools can increase the probability of partial data propagation globally through side channels, thereby limiting the depth and duration of reorganizations when the backbone network is restored.

Therefore, during a network split, market participants' operational guidelines are clear and concise:

· Suspend cross-partition settlements, consider all transaction confirmations as temporarily valid, and optimize fee estimation mechanisms for local fee spikes;

· Exchanges may switch to a reserve proof-of-reserve mode and extend confirmation thresholds to address minority partition risk while issuing explicit policies—setting required confirmation counts based on isolation duration when withdrawals are suspended;

· Wallets should clearly warn users of regional finality risks, disable automatic channel rebalancing, and queue time-sensitive transactions to rebroadcast after network recovery;

· Miners should maintain diversified upstream connections and avoid manually modifying the standard "longest chain selection rule" during coordination.

From a design perspective, the protocol itself can survive—nodes will automatically converge to the chain with the most accumulated work once they reconnect.

However, the user experience during a split will be greatly diminished because economic finality depends on consistent global data propagation.

In the worst-case scenario of a multi-hub disconnection lasting a day, the most likely outcomes are: temporary cross-border unavailability, severe and uneven fee spikes, and deep reorganizations leading to regional confirmation failures.

After network recovery, software will deterministically reconcile the ledger, and services will resume full functionality upon completion of operational checks.

The final step is: once the balance and transaction history on the winning chain are consistent, reopen withdrawals and Lightning Network channels.

If the Split Is Irreparable

What would happen if those backbone network hubs mentioned at the beginning were irreparably unable to recover? In this dystopian scenario, the Bitcoin we know would cease to exist.

In its place would be permanent geographical partitions, each operating as an independent Bitcoin network: sharing the same rules but unable to communicate with each other.

Each partition would continue to mine, adjust difficulty at its own pace, and develop distinct economic systems, order books, and fee markets. Without restoring connectivity or selecting a single chain through manual coordination, 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 blocks for difficulty adjustment, the block time would vary based on the reachable hash rate being either faster or slower. After adjustment, each partition would re-stabilize its local block time to around 10 minutes.

Based on the estimated past hash rate distribution, the initial difficulty adjustment times for each partition would be as follows:

After the initial adjustment, each partition would maintain approximately 10-minute block times, followed by independent halvings and difficulty adjustments.

Without cross-continental connections, each region would need 31 days, 40 days, and 70 days respectively to reach their first difficulty readjustment target.

Due to the different speeds at which the halving heights are reached before the initial difficulty adjustment, the halving dates for each partition would gradually deviate based on actual time.

Supply and the “Definition of Bitcoin”: Fees, Mempool, and Payments

Within each partition, the 21 million coin supply cap per chain remains in effect. However, from a global perspective, the total Bitcoin supply across all partitions would exceed 21 million coins—because each chain would independently issue block rewards.

On an economic level, this creates three mutually incompatible BTC assets: they share addresses and private keys but have different Unspent Transaction Output (UTXO) sets.

A private key can control tokens in all partitions simultaneously: if a user spends the same UTXO in two regions, those transactions would be valid on their respective local chains, ultimately creating “split tokens”: they share the pre-split history but have entirely different post-split histories.

· The mempool will be permanently localized, and cross-shard payments will not propagate; any attempts to pay users in other shards will not reach the intended recipients.

· The fee market will form a local equilibrium: during the long period before the first difficulty adjustment, shards with a small percentage of hash rate will be more congested, but will return to normal after the adjustment.

· Cross-shard Lightning Network channels will be unable to route: Hash Time Locked Contracts (HTLCs) will timeout, counterparties will publish commitment transactions, and channel closure operations will only be effective within the local shard, leading to a liquidity deadlock across shards.

Security, Markets, and Infrastructure

The security budget of each shard is equal to the local hash rate and fee sum. The hash rate of a shard comprising only 20% of the original network means that the cost of attack would be significantly lower than the original global network.

In the long run, miners may migrate to shards with a "higher token price and lower energy cost," thereby altering the security landscape of each shard.

Since block headers cannot be passed between shards, an attacker in one shard cannot tamper with the transaction history of another shard, confining any attack behavior to a specific region.

· Trading platforms will be regionalized, and trading pairs will diverge—resulting in variations like BTC-A (Americas Edition), BTC-E (Euro-Africa Edition), BTC-X (Asia-Pacific Edition), with each shard still referring to them as BTC.

· Fiat on/off ramps, custody services, derivative markets, and settlement networks will focus on chains from specific regions. Index providers and data service providers will need to choose a single chain for each platform or provide composite data for multiple regional chains.

· Cross-chain assets and oracle services relying on global data sources will either fail or split into regional versions.

Protocol rules will remain consistent without local coordination changes within a shard, but upgrades in one shard will not be effective in others, potentially leading to gradual rule divergence over time.

Mining pool software, block explorers, and wallets will need to build independent infrastructure for each shard, and multi-host services will lack cross-chain balance coordination without manual strategies.

Can Shards reorganize without a hub-like connection?

If the communication path cannot be restored indefinitely, protocol-level convergence will be impossible.

The only way to return to a single ledger is through social and operational means: for example, coordinating parties to choose the chain of a specific shard as the orthodox one while abandoning or replaying transactions from other shards.

After weeks of deep disagreement, it is no longer feasible to automatically reorganize back to a single chain.

Operational Highlights

We must treat the permanent split as a “hard fork of the shared pre-split history” to handle:

· Properly manage private keys to ensure the safe spending of post-split tokens;

· Only use transaction outputs unique to each partition to avoid accidentally replaying transactions across partitions;

· Establish separate accounting, pricing mechanisms, and risk control systems for each partition.

Miners, exchanges, and custodians should choose a main partition, publish chain identifiers, and develop 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 perish; it will evolve into multiple independent Bitcoin networks that can never be reunited.