From: "Edil Guimarães de Medeiros" <jose.edil@gmail.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Improve Bitcoin’s resilience to large-scale power grid failures and Carrington-type solar storms
Date: Wed, 19 Nov 2025 14:04:36 -0300 [thread overview]
Message-ID: <CANJiN3LnCFJxJpGxScLTqT2JF4iQNsX3hipiNiBK_OLMkkXb1g@mail.gmail.com> (raw)
In-Reply-To: <d9f4f899-14d1-4787-8046-acd59ff1ba98n@googlegroups.com>
[-- Attachment #1: Type: text/plain, Size: 4863 bytes --]
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.
Em dom., 16 de nov. de 2025 às 20:00, Alexandre <alexandre.lg99@gmail.com>
escreveu:
> 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
> <https://groups.google.com/d/msgid/bitcoindev/d9f4f899-14d1-4787-8046-acd59ff1ba98n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
Edil
--
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/CANJiN3LnCFJxJpGxScLTqT2JF4iQNsX3hipiNiBK_OLMkkXb1g%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 5975 bytes --]
prev parent reply other threads:[~2025-11-19 21:46 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-16 22:54 Alexandre
2025-11-19 17:04 ` Edil Guimarães de Medeiros [this message]
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=CANJiN3LnCFJxJpGxScLTqT2JF4iQNsX3hipiNiBK_OLMkkXb1g@mail.gmail.com \
--to=jose.edil@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