Improve Bitcoin’s resilience to large-scale power grid failures and Carrington-type solar storms

[Alexandre]

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.

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.

[Edil Guimarães de Medeiros]

I don't see any specific measure that would require specific support from Bitcoin Core, maybe you can point to more specific requirements.

The canonical approach is to maintain specific projects that solve specific problems using one of the node interfaces (e.g. RPC).

But of course, anyone is free to contribute patches that might help handle this kind of situation.

As you said, reorgs are expected to be gracefully handled already by the node implementations.

Most software that is tested in testnet probably also was exposed to harsh conditions like deep reorgs and long periods without any block being mined.

Having said that, the potential problem you describe is not specific to Bitcoin and having alternative critical communication mechanisms is desirable.

But they probably fall under the economically not viable kind of infrastructure that humans have relied on governments to implement and maintain, which is far from an ideal approach.

And by the way, this is the mailing list.

Regards.

--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/d9f4f899-14d1-4787-8046-acd59ff1ba98n%40googlegroups.com.

--

Edil