From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 16 Nov 2025 15:00:11 -0800 Received: from mail-oa1-f62.google.com ([209.85.160.62]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vKlj8-0005Yy-Vu for bitcoindev@gnusha.org; Sun, 16 Nov 2025 15:00:11 -0800 Received: by mail-oa1-f62.google.com with SMTP id 586e51a60fabf-3e82b0276d4sf6080590fac.1 for ; Sun, 16 Nov 2025 15:00:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1763334004; x=1763938804; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:message-id:to:from:date:sender:from:to:cc:subject:date :message-id:reply-to; bh=Gw7j0r0q6CFTgScwdM/UQHawdpSZbuN/VP0fN+ngMvQ=; b=guIEQc0FabxgkHuUIYroMJnNcMJlJLVeMJkiPELjceuJGahLulAUPVik6Cuvj/wY6N mrYqFV0ersVXarX5saWuGCn999xv/aK6Dc0vKI/5pLEBqMXZUubV0zoh4WkE0LHTFwC5 NuKfFrHAFn08exlMpobyoNKhhjxoayxlYnYyd7dldQI6L9nUFftpmoq5/BsvuZAXlfBn VgTOiqVtru9YXAMYRKqUhU5Sjm3leQO6kUwTqXbVs2IKxMjis55BYns0VI18BMdSA660 ylsp3jFuj/r0hSZgLvEh4AMW0Wn3ksKdPj3GTRVWRA/apJgx+w2LDlqKioAUvQh+tI7F 7kag== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1763334004; x=1763938804; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:message-id:to:from:date:from:to:cc:subject:date:message-id :reply-to; bh=Gw7j0r0q6CFTgScwdM/UQHawdpSZbuN/VP0fN+ngMvQ=; b=MuPV8zR9nAIMU2xyw+Z/shBbI8kOm/gAlvqJpGexN+9Opy4Fj3PbHzBNG2lO5MddzK AUseEYxQStR++b/AaW0Mk1iW5lTtzcgSKWCAMWjwS2js27TQXiW6IQnqSeYpjc+oNFNT MIyAs45mIuMFPnDBO7IlfGbTFjNEt24ztCtlgMSB+r1qeB0dXfyqEr5OyYfVpFInzF2N 7o57EG06DNyyh25CzLQcdTpKhMpBrkukKGgMhlqyWNLz5A4xTqdj5drIyi986SZmvHPt 3mIXsL+92bqvUCOXabaLNOV0jZlkmXTKZ50sguAtVBtxd0UNaf0RuHD4L40Wh/OxoNop Vlwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763334004; x=1763938804; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:message-id:to:from:date:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=Gw7j0r0q6CFTgScwdM/UQHawdpSZbuN/VP0fN+ngMvQ=; b=MO6rwC5omOyDGUt0SOciyLpbAyzqOvudRpgmIGbWM5Sk+5a/ZPodyTKIFt41CHU1vz ajdu9sQgarhG515x6elKRA6bC0UNSYzYmRZ4l1Dp4+7thLTPVJN5pJROHfmrRZ52bwEK ma70YLBUm2nUxumJw/4P95YMOEvNBbgLG7W69JLTjAk5aQtib3sV0yFvyVv/1WtDy5zw 79BCBQzB0p6pML1bhEiHfyzcfHOpg1dx1FyttzU2oVmu9R431k0zQuVX2b06eI7mNEs9 aRECG4wBh4XOugvYRMzmyFwN/tUZpvEaqpVNpr0sdG3Nio5pDZwZ7/rZG9zTOfp07pEm I4Pg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCX0rZmmo4w/bc+D/ahbEiaOWxwpM30F2DI2v3ifx/Wc9XiYrPv+ckF+IPbQFeKGAypLlAvT3MvTVk7W@gnusha.org X-Gm-Message-State: AOJu0YziHssiVaRibrQrfZOVnkmKGR/UDSg9Cx0a35QLPkxAPnehK/5t FU4lphlO8xTn9nFN99hm091/LUp+O0IIQjgP2tFxw2obHilSA9rDBrPM X-Google-Smtp-Source: AGHT+IGdCBc36MDN9sRLlSr12Wt3pZPYo6fbhySiKiPbdGUWBLBr0nf0JOcNu/pNxZ4i/HAgdHBV1Q== X-Received: by 2002:a05:6871:822:b0:3ec:4475:9baf with SMTP id 586e51a60fabf-3ec4475bd84mr658937fac.26.1763334004329; Sun, 16 Nov 2025 15:00:04 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+be/36oTIDkhACbnOCkUgnnN+azEx26UT1fiuSpFw7bMQ==" Received: by 2002:a05:6870:5490:b0:3ec:461d:1e8f with SMTP id 586e51a60fabf-3ec461d226bls166339fac.2.-pod-prod-03-us; Sun, 16 Nov 2025 15:00:00 -0800 (PST) X-Received: by 2002:a05:6808:4494:b0:450:c79d:92de with SMTP id 5614622812f47-450c79d9f90mr980749b6e.41.1763333999942; Sun, 16 Nov 2025 14:59:59 -0800 (PST) Received: by 2002:a05:690c:6303:b0:785:e55d:2dfd with SMTP id 00721157ae682-78929f9dfd3ms7b3; Sun, 16 Nov 2025 14:54:06 -0800 (PST) X-Received: by 2002:a05:690c:a4c8:b0:788:14f8:17a0 with SMTP id 00721157ae682-78929f0bd92mr78418887b3.32.1763333645215; Sun, 16 Nov 2025 14:54:05 -0800 (PST) Date: Sun, 16 Nov 2025 14:54:04 -0800 (PST) From: Alexandre To: Bitcoin Development Mailing List Message-Id: Subject: =?UTF-8?Q?=5Bbitcoindev=5D_Improve_Bitcoin=E2=80=99s_resilience_to_large?= =?UTF-8?Q?=2Dscale_power_grid_failures_and_Carrington=2Dtype_solar_storms?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_137012_1371551363.1763333644824" X-Original-Sender: alexandre.lg99@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_137012_1371551363.1763333644824 Content-Type: multipart/alternative; boundary="----=_Part_137013_1353686096.1763333644824" ------=_Part_137013_1353686096.1763333644824 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =20 Hi, I=E2=80=99m submitting this feature request to explore how Bitcoin could be= tter=20 withstand extreme, long-lasting infrastructure failures caused by major=20 solar events. Before explaining the request itself, I want to provide a=20 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= =20 particles and electromagnetic energy. When this material reaches Earth, it= =20 can disturb the magnetic field and induce strong electric currents in long= =20 conductors such as power lines. In extreme cases, this can damage=20 transformers, overload electrical grids, interrupt satellite operations,=20 and disrupt long-distance communication systems. The most famous historical= =20 example is the Carrington Event of 1859, the largest geomagnetic storm ever= =20 recorded. It triggered worldwide telegraph failures, fires in equipment,=20 and intense auroras seen far from polar regions. Modern research suggests= =20 that a Carrington-level event striking today could cause regional or=20 continental power grid failures lasting days to months, as well as major=20 internet and satellite disruptions. The issue for Bitcoin is that these types of events could fragment the=20 network into isolated regions unable to communicate for extended periods.= =20 Each region might continue mining independently, creating separate versions= =20 of the chain. When connectivity eventually returns, deep chain splits and= =20 long reorgs could occur. Although Bitcoin=E2=80=99s consensus rules can han= dle this=20 mechanically, the practical impact on users, operators, and services would= =20 be significant. The purpose of this feature request is not to propose consensus changes,=20 but to explore whether Bitcoin Core could improve resilience and=20 operational clarity in such extreme scenarios. Specifically: Degraded communication support Consider improving documentation or optional tooling for running nodes over= =20 degraded or intermittent communication channels such as HF/VHF radio links,= =20 mesh networks, or intermittent satellite reception. These channels exist=20 today in experimental form but may benefit from more formal guidance or=20 optional integration. Operator guidance Document best practices for wallets, miners, and node operators during=20 extreme, high-latency, or partitioned network conditions to minimize user= =20 disruption during future reconnection events. This request is simply to consider whether these improvements fall within= =20 Bitcoin Core=E2=80=99s scope, or whether they should be handled entirely by= =20 external projects. If this discussion belongs on the mailing list first,=20 I=E2=80=99m willing to move it there. Thanks for your time and any feedback. --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= d9f4f899-14d1-4787-8046-acd59ff1ba98n%40googlegroups.com. ------=_Part_137013_1353686096.1763333644824 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi,
I=E2=80=99m submitting this feature request to explore how Bitcoin could be= tter=20 withstand extreme, long-lasting infrastructure failures caused by major=20 solar events. Before explaining the request itself, I want to provide a=20 brief overview of what these events are, because their scale matters.

A large solar storm occurs when the Sun emits an intense=20 burst of charged particles and electromagnetic energy. When this=20 material reaches Earth, it can disturb the magnetic field and induce=20 strong electric currents in long conductors such as power lines. In=20 extreme cases, this can damage transformers, overload electrical grids,=20 interrupt satellite operations, and disrupt long-distance communication=20 systems. The most famous historical example is the Carrington Event of=20 1859, the largest geomagnetic storm ever recorded. It triggered=20 worldwide telegraph failures, fires in equipment, and intense auroras=20 seen far from polar regions. Modern research suggests that a=20 Carrington-level event striking today could cause regional or=20 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= =20 fragment the network into isolated regions unable to communicate for=20 extended periods. Each region might continue mining independently,=20 creating separate versions of the chain. When connectivity eventually=20 returns, deep chain splits and long reorgs could occur. Although=20 Bitcoin=E2=80=99s consensus rules can handle this mechanically, the practic= al=20 impact on users, operators, and services would be significant.

The purpose of this feature request is not to propose=20 consensus changes, but to explore whether Bitcoin Core could improve=20 resilience and operational clarity in such extreme scenarios.=20 Specifically:

Degraded communication support
Consider improving documentation or optional tooling for running nodes=20 over degraded or intermittent communication channels such as HF/VHF=20 radio links, mesh networks, or intermittent satellite reception. These=20 channels exist today in experimental form but may benefit from more=20 formal guidance or optional integration.

Operator guidan= ce
Document best practices for wallets, miners, and node operators during=20 extreme, high-latency, or partitioned network conditions to minimize=20 user disruption during future reconnection events.

This = request is simply to consider whether these=20 improvements fall within Bitcoin Core=E2=80=99s scope, or whether they shou= ld be handled entirely by external projects. If this discussion belongs on=20 the mailing list first, I=E2=80=99m willing to move it there.

Thanks for your time and any feedback.


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