Please describe the feature you’d like to see added.
Hi, This is a feature request to explore options for improving Bitcoin’s resilience during large-scale, long-duration power or network outages (e.g., Carrington-type solar storms). Such events could isolate regions for days or weeks, causing separate chain histories that later need reconciliation.
The request is to consider small, consensus-compatible improvements in documentation, defaults, or optional tools to help nodes operate on degraded communication channels (radio, mesh, intermittent links) and safely resync after long partitions.
This is not a consensus change proposal, just a request to evaluate whether these resilience tools should be better supported or documented.
Thanks for any feedback.
Is your feature related to a problem, if so please describe it.
Hi, I’m submitting this feature request to explore how Bitcoin could better withstand extreme, long-lasting infrastructure failures caused by major solar events. Before explaining the request itself, I want to provide a brief overview of what these events are, because their scale matters.
A large solar storm occurs when the Sun emits an intense burst of charged particles and electromagnetic energy. When this material reaches Earth, it can disturb the magnetic field and induce strong electric currents in long conductors such as power lines. In extreme cases, this can damage transformers, overload electrical grids, interrupt satellite operations, and disrupt long-distance communication systems. The most famous historical example is the Carrington Event of 1859, the largest geomagnetic storm ever recorded. It triggered worldwide telegraph failures, fires in equipment, and intense auroras seen far from polar regions. Modern research suggests that a Carrington-level event striking today could cause regional or continental power grid failures lasting days to months, as well as major internet and satellite disruptions.
The issue for Bitcoin is that these types of events could fragment the network into isolated regions unable to communicate for extended periods. Each region might continue mining independently, creating separate versions of the chain. When connectivity eventually returns, deep chain splits and long reorgs could occur. Although Bitcoin’s consensus rules can handle this mechanically, the practical impact on users, operators, and services would be significant.
The purpose of this feature request is not to propose consensus changes, but to explore whether Bitcoin Core could improve resilience and operational clarity in such extreme scenarios. Specifically:
-
Degraded communication support Consider improving documentation or optional tooling for running nodes over degraded or intermittent communication channels such as HF/VHF radio links, mesh networks, or intermittent satellite reception. These channels exist today in experimental form but may benefit from more formal guidance or optional integration.
-
Partition detection and recovery Provide tools or clearer operational instructions for node operators to detect long-lived network partitions, understand their implications, and safely resynchronize after extended isolation periods without risking accidental unsafe behavior.
-
Operator guidance Document best practices for wallets, miners, and node operators during extreme, high-latency, or partitioned network conditions to minimize user disruption during future reconnection events.
This request is simply to consider whether these improvements fall within Bitcoin Core’s scope, or whether they should be handled entirely by external projects. If this discussion belongs on the mailing list first, I’m willing to move it there.
Thanks for your time and any feedback.
Describe the solution you’d like
No response
Describe any alternatives you’ve considered
No response
Please leave any additional context
No response
