1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
|
Delivery-date: Wed, 18 Dec 2024 17:21:30 -0800
Received: from mail-yb1-f188.google.com ([209.85.219.188])
by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
(Exim 4.94.2)
(envelope-from <bitcoindev+bncBCXKXQ5DHYIJB2UNXMDBUBGG35YXU@googlegroups.com>)
id 1tO5EH-0000bv-Jh
for bitcoindev@gnusha.org; Wed, 18 Dec 2024 17:21:30 -0800
Received: by mail-yb1-f188.google.com with SMTP id 3f1490d57ef6-e35e0e88973sf517899276.0
for <bitcoindev@gnusha.org>; Wed, 18 Dec 2024 17:21:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=googlegroups.com; s=20230601; t=1734571283; x=1735176083; 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=HSi5G5urQE+JIjxpwoKhr89k0PfjTK3aMtTBSKJZi5I=;
b=RgTQ0FqViRGpWHNCHG1PKA8qpfbQlmL9sgFAEzdKgasDQOsw9/njRAmGNcDxu/nJ4J
XAbzGeHmaOpOozA0RRPypvHzPF+oVim5+Hzfbvj0etNvVHK90WQAOD+FtQ4FcnovDoI5
yE3MbcAIEDrf9ptC538X3of04ArgyHI/kdxHdY+KoQrPZZaMd+il+umPpClaVnCx7H/s
MNST4Q6IuEhh3OwwYtBbDpKpUZAvq/PMi8gs0rPhVxOHud686y5n/XZl4xOxn6R9839g
Pc8OL3VhPAcs+H8+fUb7+wkQErM1UurB+GLiTHt7wOXcmpa05pZxaI8uAwutR+tXOQww
7fOg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1734571283; x=1735176083; 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=HSi5G5urQE+JIjxpwoKhr89k0PfjTK3aMtTBSKJZi5I=;
b=XleBuafc4UZ9FAek8HURLJHnmttc6ObFk1/4H6seiP0R/W9cTIYB4mZJI6WmFvt3jY
o6XkJ4bQEZHXdrIIl49wrFi4eyKvpN7zKxRmEsOJGgFHEHIvAloaKB38IRi6o+Qpb3s8
h8LUIH8YlrYJTcRD1SCM99/n2x31klr53MFOO8ffE9pjGajj3Yxy2QW+FydgJORl6Go5
2SrUuAeCMITPxin6EQqV8ftXeFKNeq+2yJSv4UI93/Zcr+4Ob9l6zUBRoROjUHCnSWJU
bNjl8onJy3CaafQCuz2kKp5h3a7YEq4LWFayxFXEUEsItDE/42HhOTn0Vv3LyJrzMStR
1v7Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1734571283; x=1735176083;
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=HSi5G5urQE+JIjxpwoKhr89k0PfjTK3aMtTBSKJZi5I=;
b=YUf+pNq0Yoy0p1apFuJtlLrHSmyFoILACwvLVD81KaYPjWgRYK+Hz0l667i7vLrIcE
+jGboUGf+t3gH9VONil9yI9cjYwRc+44cLtOMfnO5yOzUR72e2tFtQFdKzPlf+4HuAm7
ng1FSHlPI4prW+6Yp1t3VSpnTA8usdZeLEKweUvlbr8Cm9vptsc43gWGrWqlspqXteYQ
xBqfuwmJilwO6wIq30oQJJQck9z5LGMvPzgTKgXMT7RYrQ8setNJ5/Jz3MkkUIt3I/8t
RpqnhG2CPpK8d27nI9yyjnznXZw8MN4xDdH2jRK5bplS7wXViOQy4LtaE5vFV2qh1/G6
7C1Q==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCX1kBb+kvDPBTN6t8APDDjXSNAnk/UP3HUmgXytuxoSRCKM1SI+cOwUVDAu/9aMjb1v3CSd9aZpfNk8@gnusha.org
X-Gm-Message-State: AOJu0Yxgcczqxa3IPQDCKnzjDBFCvwrmdITFyGh2QtvU9N4C8nBMCYAb
utT+Act7J80jCM2qoYTHc4zVrnZeMF6LgCKE0Ow9YB295DrD9+E4
X-Google-Smtp-Source: AGHT+IHGhNLEUUsLRsKebhgJZ7lRkHtHgKw0p5gWxzaZ+PRCJl+8aJDedc3ZWW13xiBqgXLLuJEGEQ==
X-Received: by 2002:a25:8744:0:b0:e48:368b:83f3 with SMTP id 3f1490d57ef6-e5376762564mr1303974276.18.1734571282677;
Wed, 18 Dec 2024 17:21:22 -0800 (PST)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a25:264c:0:b0:e38:273e:46a with SMTP id 3f1490d57ef6-e537612941fls445113276.2.-pod-prod-01-us;
Wed, 18 Dec 2024 17:21:20 -0800 (PST)
X-Received: by 2002:a05:690c:d81:b0:6f2:8db8:d546 with SMTP id 00721157ae682-6f3ccc3c4a8mr30523397b3.11.1734571280095;
Wed, 18 Dec 2024 17:21:20 -0800 (PST)
Received: by 2002:a0d:d082:0:b0:6ef:b1a3:15f0 with SMTP id 00721157ae682-6f2f8461dd4ms7b3;
Wed, 18 Dec 2024 17:19:01 -0800 (PST)
X-Received: by 2002:a05:690c:4c0a:b0:6ef:7036:3b25 with SMTP id 00721157ae682-6f3d2686809mr42106487b3.31.1734571140597;
Wed, 18 Dec 2024 17:19:00 -0800 (PST)
Date: Wed, 18 Dec 2024 17:19:00 -0800 (PST)
From: Anders <blabline@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <e86753f2-1c79-484d-8f61-47a5dd148b45n@googlegroups.com>
Subject: [bitcoindev] Double Exponential Hash Rate Growth and Difficulty Adjustment
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_Part_17030_2112598000.1734571140101"
X-Original-Sender: blabline@gmail.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
<https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.5 (/)
------=_Part_17030_2112598000.1734571140101
Content-Type: multipart/alternative;
boundary="----=_Part_17031_1393692434.1734571140101"
------=_Part_17031_1393692434.1734571140101
Content-Type: text/plain; charset="UTF-8"
Hi,
I've been looking into the long-term implications of the Bitcoin hash rate
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 about
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 suggest,
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 existing
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-47a5dd148b45n%40googlegroups.com.
------=_Part_17031_1393692434.1734571140101
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi,<br /><br />I've been looking into the long-term implications of the Bit=
coin hash rate growth for the difficulty adjustment mechanism, and I'd like=
to discuss a potential concern related to double exponential growth.<br />=
<br />As we know, the difficulty adjustment mechanism aims to maintain an a=
verage block time of approximately 10 minutes by adjusting the target value=
every 2016 blocks. This target value, when represented in hexadecimal, eff=
ectively determines the number of leading zeros required for a valid block =
hash.<br /><br />The Bitcoin hash rate has historically shown a strong expo=
nential growth trend, driven by advancements in ASIC technology. However, s=
ome observations suggest that this growth might be accelerating, potentiall=
y exhibiting double exponential growth (meaning the rate of exponential gro=
wth is itself increasing exponentially).<br /><br />If the hash rate were t=
o 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. T=
his would mean the number of leading zeros in the target value would also n=
eed to increase at an accelerating rate.<br /><br />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 about 44-45 zeros "left" before reachin=
g this limit.<br /><br />My concern is that with double exponential hash ra=
te growth, we could reach this limit much faster than a simple linear proje=
ction would suggest, potentially within a decade. Once this limit is reache=
d, the current difficulty adjustment mechanism would become ineffective, po=
tentially leading to unstable block times and network instability.<br /><br=
/>My questions for the list are:<br /><br />1. Has there been more formal =
analysis of the Bitcoin hash rate trend to assess the likelihood of double =
exponential growth? Are there any existing studies or analyses I should be =
aware of?<div><br />2. If double exponential growth continues, what are the=
most promising approaches to address this potential issue in the long term=
?</div><div><br />3. What are the trade-offs associated with different solu=
tions, such as more frequent difficulty adjustments, changing the difficult=
y adjustment algorithm, or changing the proof-of-work algorithm entirely?</=
div><div><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" 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/e86753f2-1c79-484d-8f61-47a5dd148b45n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/e86753f2-1c79-484d-8f61-47a5dd148b45n%40googlegroups.com</a>.<br />
------=_Part_17031_1393692434.1734571140101--
------=_Part_17030_2112598000.1734571140101--
|
