Delivery-date: Thu, 19 Dec 2024 11:48:17 -0800
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of mcassano@gmail.com designates 2a00:1450:4864:20::331 as permitted sender) client-ip=2a00:1450:4864:20::331;
MIME-Version: 1.0
References: <e86753f2-1c79-484d-8f61-47a5dd148b45n@googlegroups.com>
In-Reply-To: <e86753f2-1c79-484d-8f61-47a5dd148b45n@googlegroups.com>
From: Michael Cassano <mcassano@gmail.com>
Date: Thu, 19 Dec 2024 10:25:34 -0700
Message-ID: <CAAg3Je1hVqcR_DGZEXhaeO7CEU1k-SLx_1QX=XmnS2Bn11joXw@mail.gmail.com>
Subject: Re: [bitcoindev] Double Exponential Hash Rate Growth and Difficulty Adjustment
To: Anders <blabline@gmail.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: multipart/alternative; boundary="0000000000000b41e90629a2d261"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

--0000000000000b41e90629a2d261
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Anders,

Thank you for the question.

A solution is to keep miners on SHA256 (instead of switching to a hash that
allows for a larger range of difficulty targets) but to require them to
hash again to achieve a secondary difficulty target.

At max target difficulty miners would publish blocks when SHA256(header) =
=3D=3D
1 and when SHA256(SHA256(header)) <=3D secondary_target where
secondary_target adjusts up and down if primary_target is 1 (where
primary_target represents today's target difficulty).

Nodes then verify blocks by checking that SHA256(header) is =3D=3D 1 and th=
at
SHA256(SHA256(header) is less than secondary_target.

Best regards,
Mike

On Wed, Dec 18, 2024 at 6:21=E2=80=AFPM Anders <blabline@gmail.com> wrote:

> Hi,
>
> I've been looking into the long-term implications of the Bitcoin hash rat=
e
> growth for the difficulty adjustment mechanism, and I'd like to discuss a
> potential concern related to double exponential growth.
>
> As we know, the difficulty adjustment mechanism aims to maintain an
> average block time of approximately 10 minutes by adjusting the target
> value every 2016 blocks. This target value, when represented in
> hexadecimal, effectively determines the number of leading zeros required
> for a valid block hash.
>
> The Bitcoin hash rate has historically shown a strong exponential growth
> trend, driven by advancements in ASIC technology. However, some
> observations suggest that this growth might be accelerating, potentially
> exhibiting double exponential growth (meaning the rate of exponential
> growth is itself increasing exponentially).
>
> If the hash rate were to continue to grow at a double exponential rate,
> the difficulty would need to increase at an accelerating pace to maintain
> the 10-minute block time. This would mean the number of leading zeros in
> the target value would also need to increase at an accelerating rate.
>
> Since the target value is a 256-bit number (64 hexadecimal digits),
> there's a finite limit to the number of leading zeros it can have. With
> approximately 19-20 leading zeros currently observed, there are only abou=
t
> 44-45 zeros "left" before reaching this limit.
>
> My concern is that with double exponential hash rate growth, we could
> reach this limit much faster than a simple linear projection would sugges=
t,
> potentially within a decade. Once this limit is reached, the current
> difficulty adjustment mechanism would become ineffective, potentially
> leading to unstable block times and network instability.
>
> My questions for the list are:
>
> 1. Has there been more formal analysis of the Bitcoin hash rate trend to
> assess the likelihood of double exponential growth? Are there any existin=
g
> studies or analyses I should be aware of?
>
> 2. If double exponential growth continues, what are the most promising
> approaches to address this potential issue in the long term?
>
> 3. What are the trade-offs associated with different solutions, such as
> more frequent difficulty adjustments, changing the difficulty adjustment
> algorithm, or changing the proof-of-work algorithm entirely?
>
> Thanks,
>
> Anders
>
> --
> 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/e86753f2-1c79-484d-8f61-47a5=
dd148b45n%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/e86753f2-1c79-484d-8f61-47a=
5dd148b45n%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter>
> .
>

--=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/=
CAAg3Je1hVqcR_DGZEXhaeO7CEU1k-SLx_1QX%3DXmnS2Bn11joXw%40mail.gmail.com.

--0000000000000b41e90629a2d261
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Anders,<div><br></div><div>Thank you for the question.<=
/div><div><br></div><div>A solution is to keep miners on SHA256 (instead of=
 switching to a hash that allows for a larger range of difficulty targets) =
but to require them to hash again to achieve a secondary difficulty target.=
</div><div><br></div><div>At max target difficulty miners would publish blo=
cks when SHA256(header) =3D=3D 1 and when SHA256(SHA256(header)) &lt;=3D se=
condary_target where secondary_target adjusts up and down if primary_target=
 is 1 (where primary_target represents today&#39;s target difficulty).</div=
><div><br></div><div>Nodes then verify blocks by checking that SHA256(heade=
r) is =3D=3D 1 and that SHA256(SHA256(header) is less than secondary_target=
.</div><div><br></div><div>Best regards,</div><div>Mike</div></div><br><div=
 class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmai=
l_attr">On Wed, Dec 18, 2024 at 6:21=E2=80=AFPM Anders &lt;<a href=3D"mailt=
o:blabline@gmail.com">blabline@gmail.com</a>&gt; wrote:<br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width=
:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-lef=
t:1ex">Hi,<br><br>I&#39;ve been looking into the long-term implications of =
the Bitcoin hash rate growth for the difficulty adjustment mechanism, and I=
&#39;d like to discuss a potential concern related to double exponential gr=
owth.<br><br>As we know, the difficulty adjustment mechanism aims to mainta=
in an average block time of approximately 10 minutes by adjusting the targe=
t value every 2016 blocks. This target value, when represented in hexadecim=
al, effectively determines the number of leading zeros required for a valid=
 block hash.<br><br>The Bitcoin hash rate has historically shown a strong e=
xponential growth trend, driven by advancements in ASIC technology. However=
, some observations suggest that this growth might be accelerating, potenti=
ally exhibiting double exponential growth (meaning the rate of exponential =
growth is itself increasing exponentially).<br><br>If the hash rate were to=
 continue to grow at a double exponential rate, the difficulty would need t=
o increase at an accelerating pace to maintain the 10-minute block time. Th=
is would mean the number of leading zeros in the target value would also ne=
ed to increase at an accelerating rate.<br><br>Since the target value is a =
256-bit number (64 hexadecimal digits), there&#39;s a finite limit to the n=
umber of leading zeros it can have. With approximately 19-20 leading zeros =
currently observed, there are only about 44-45 zeros &quot;left&quot; befor=
e reaching this limit.<br><br>My concern is that with double exponential ha=
sh rate growth, we could reach this limit much faster than a simple linear =
projection would suggest, potentially within a decade. Once this limit is r=
eached, the current difficulty adjustment mechanism would become ineffectiv=
e, potentially leading to unstable block times and network instability.<br>=
<br>My questions for the list are:<br><br>1. Has there been more formal ana=
lysis of the Bitcoin hash rate trend to assess the likelihood of double exp=
onential growth? Are there any existing studies or analyses I should be awa=
re of?<div><br>2. If double exponential growth continues, what are the most=
 promising approaches to address this potential issue in the long term?</di=
v><div><br>3. What are the trade-offs associated with different solutions, =
such as more frequent difficulty adjustments, changing the difficulty adjus=
tment algorithm, or changing the proof-of-work algorithm entirely?</div><di=
v><br>Thanks,<br><div><br></div><div>Anders</div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com" target=
=3D"_blank">bitcoindev+unsubscribe@googlegroups.com</a>.<br>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/e86753f2-1c79-484d-8f61-47a5dd148b45n%40googlegroups.com?utm_med=
ium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">https://groups.googl=
e.com/d/msgid/bitcoindev/e86753f2-1c79-484d-8f61-47a5dd148b45n%40googlegrou=
ps.com</a>.<br>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/CAAg3Je1hVqcR_DGZEXhaeO7CEU1k-SLx_1QX%3DXmnS2Bn11joXw%40mail.gma=
il.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/=
msgid/bitcoindev/CAAg3Je1hVqcR_DGZEXhaeO7CEU1k-SLx_1QX%3DXmnS2Bn11joXw%40ma=
il.gmail.com</a>.<br />

--0000000000000b41e90629a2d261--