From: Alexandre <alexandre.lg99@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] Improve Bitcoin’s resilience to large-scale power grid failures and Carrington-type solar storms
Date: Sun, 16 Nov 2025 14:54:04 -0800 (PST) [thread overview]
Message-ID: <d9f4f899-14d1-4787-8046-acd59ff1ba98n@googlegroups.com> (raw)
[-- Attachment #1.1: Type: text/plain, Size: 3117 bytes --]
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.
--
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+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/d9f4f899-14d1-4787-8046-acd59ff1ba98n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 3527 bytes --]
next reply other threads:[~2025-11-16 23:00 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-16 22:54 Alexandre [this message]
2025-11-19 17:04 ` Edil Guimarães de Medeiros
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d9f4f899-14d1-4787-8046-acd59ff1ba98n@googlegroups.com \
--to=alexandre.lg99@gmail.com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox