-
Notifications
You must be signed in to change notification settings - Fork 64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Invalid Supply Curve #20
Comments
The PR #33 was created in order to tidy up the subsidy related parts of the source code in |
Thank you for the detailed commentary. Contextual data even a noob can understand. |
…eeds tests updated
Have begun working on this in PR #56 , I figure it'll be a two-pronged solution:
Any feedback on the initial suggestion would be appreciated. |
? |
Closing this as it was fixed in #105 We might have to look into changing the curve parameters (slightly) so that we reach 21 bln coins when the supply gets set to zero. We can still use the simulation scripts I created. But for this, we will open another issue in the near future. |
I think I have the algorithmic decay math all sorted out once we choose a date and a block height to implement. :) |
Awesome! Have you tried to enter those in the python script that I provided? :) |
Reopening this issue as a feature enhancement request. #105 indeed resolves the issue, but we still need a long term algorithmic delay solution at some point in the future. |
Yes indeed, though trying to create an algorithm that adjusts decay rate based on block/emission counts at specific time intervals so that it mints out on Jan 9th, 2035 has proved challenging. |
// (Period I) 1440 * 72000 = 103,680,000
// (Period II) 4320 * 16000 = 69,120,000
// (Period III) 61440 * 8000 = 491,520,000 < 67200 ( 664,320,000 dgb )// (Period IV)
80,640,000 decreasing it by 0.5% for 33.0158730159 times < 400000 ( 2,527,174,765 dgb )// (Period V)
197,113,440 decreasing it by 1% for 12.8493013972 times < 1430000 ( 2,414,225,248 dgb )
15,394,279,987 dgb for Period VI to get 21B(Period VI)
validation.cpp
it will take approximately 214 months to reach 15,394,279,987 dgb. 214 * 175200 = 37,492,800 blocks 37,492,800 + 1,430,000 = 38,922,800 blocks Fix: In validation.cpp add on line 1249 before else.
|
From my understanding the code to fix this has already been discussed and
that it would be implemented after the major core update as it would be
easier to do.
…On Fri, Jul 19, 2024, 5:48 PM Jan ***@***.***> wrote:
// (Period I)
1440 * 72000 = 103,680,000
------------------------------
5760 - 1440 = 4320
// (Period II)
4320 * 16000 = 69,120,000
------------------------------
67200 - 5760 = 61,440
// (Period III)
61440 * 8000 = 491,520,000
< 67200 ( 664,320,000 dgb )
// (Period IV)
consensus.patchBlockRewardDuration = 10080;
400000 - 67200 = 332,800
332800 / 10080 = 33.0158730159
8000 * 10080 = 80640000
80,640,000 decreasing it by 0.5% for 33.0158730159 times
Total approximately 2,527,174,765.77 DGB
< 400000 ( 2,527,174,765 dgb )
// (Period V)
consensus.patchBlockRewardDuration2 = 80160;
1430000 - 400000 = 1,030,000
1,030,000 / 80160 = 12.8493013972
2459 * 80160 = 197,113,440
197,113,440 decreasing it by 1% for 12.8493013972 times
Total approximately 2,414,225,248.44 DGB
< 1430000 ( 2,414,225,248 dgb )
Block 1,430,000 ( 5,605,720,013 dgb )
------------------------------
*15,394,279,987 dgb for Period VI to get 21B*
(Period VI)
consensus.workComputationChangeTarget = 1430000;
nSubsidy = 1,078.5
SECONDS_PER_MONTH (60 * 60 * 24 * 365 / 12)
Seconds per month = 2,628,000
BLOCK_TIME_SECONDS 15
Block per month 175200
nSubsidy first month 188,953,200
validation.cpp
nSubsidy *= 98884;
nSubsidy /= 100000;
Each month the subsidy is reduced to 98.884% of its value
from the previous month.
With the current code it cost 624 months ( 52 years ) for the value to
drop below 1. ( nSubsidy = 0; )
first month block x subsidy
175200 * 1,078.5 = 188,953,200
1 188953200
2 186844482.288
3 184759297.865666
4 182697384.101485
5 180658481.294913
6 178642332.643661
7 176648684.211358
8 174677284.895559
9 172727886.396125
10 170800243.183944
11 168894112.470011
12 167009254.174846
13 165145430.898255
14 163302407.88943
15 161479953.017384
16 159677836.74171
17 157895832.083673
18 156133714.597619
19 154391262.34271
20 152668255.854965
21 150964478.119624
22 149279714.543809
23 147613752.9295
24 145966383.446806
25 144337398.60754
26 142726593.23908
27 141133764.458532
28 139558711.647175
29 138001236.425192
30 136461142.626687
31 134938236.274973
32 133432325.558144
33 131943220.804916
34 130470734.460733
35 129014681.064151
36 127574877.223475
37 126151141.593661
38 124743294.853476
39 123351159.682911
40 121974560.74085
41 120613324.642982
42 119267279.939966
43 117936257.095836
44 116620088.466647
45 115318608.279359
46 114031652.610961
47 112759059.367823
48 111500668.265278
49 110256320.807438
50 109025860.267227
51 107809131.666644
52 106605981.757245
53 105416259.000834
54 104239813.550384
55 103076497.231162
56 101926163.522062
57 100788667.537156
58 99663866.0074415
59 98551617.2627985
60 97451781.2141456
61 96364219.3357958
62 95288794.6480083
63 94225371.6997365
64 93173816.5515675
65 92133996.758852
66 91105781.3550232
67 90089040.8351012
68 89083647.1393814
69 88089473.637306
70 87106395.1115136
71 86134287.7420691
72 85173029.0908676
73 84222498.0862136
74 83282575.0075714
75 82353141.4704869
76 81434080.4116763
77 80525276.074282
78 79626613.993293
79 78737980.9811279
80 77859265.1133785
81 76990355.7147132
82 76131143.344937
83 75281519.7852075
84 74441378.0244046
85 73610612.2456522
86 72789117.8129908
87 71976791.2581978
88 71173530.2677563
89 70379233.6699681
90 69593801.4222113
91 68817134.5983394
92 68049135.376222
93 67289707.0254233
94 66538753.8950196
95 65796181.4015512
96 65061896.0171099
97 64335805.2575589
98 63617817.6708846
99 62907842.8256775
100 62205791.299743
101 61511574.6688378
102 60825105.4955336
103 60146297.3182035
104 59475064.6401323
105 58811322.9187484
106 58154988.5549752
107 57505978.8827017
108 56864212.1583707
109 56229607.5506833
110 55602085.1304177
111 54981565.8603622
112 54367971.5853606
113 53761225.022468
114 53161249.7512172
115 52567970.2039937
116 51981311.6565171
117 51401200.2184304
118 50827562.8239927
119 50260327.2228769
120 49699421.9710696
121 49144776.4218725
122 48596320.7170044
123 48053985.7778026
124 47517703.2965224
125 46987405.7277332
126 46463026.2798117
127 45944498.906529
128 45431758.2987321
129 44924739.8761183
130 44423379.7791008
131 43927614.860766
132 43437382.6789199
133 42952621.4882231
134 42473270.2324146
135 41999268.5366208
136 41530556.6997521
137 41067075.6869829
138 40608767.1223162
139 40155573.2812311
140 39707437.0834126
141 39264302.0855617
142 38826112.4742868
143 38392813.0590738
144 37964349.2653345
145 37540667.1275334
146 37121713.2823901
147 36707434.9621587
148 36297779.987981
149 35892696.7633151
150 35492134.2674365
151 35096042.0490119
152 34704370.219745
153 34317069.4480926
154 33934090.9530519
155 33555386.4980158
156 33180908.384698
157 32810609.4471248
158 32444443.0456948
159 32082363.0613049
160 31724323.8895407
161 31370280.4349335
162 31020188.1052796
163 30674002.8060247
164 30331680.9347094
165 29993179.3754781
166 29658455.4936478
167 29327467.1303386
168 29000172.5971641
169 28676530.6709797
170 28356500.5886916
171 28040042.0421218
172 27727115.1729317
173 27417680.5676018
174 27111699.2524674
175 26809132.6888098
176 26509942.7680027
177 26214091.8067118
178 25921542.5421489
179 25632258.1273785
180 25346202.126677
181 25063338.5109433
182 24783631.6531611
183 24507046.3239119
184 24233547.686937
185 23963101.2947508
186 23695673.0843014
187 23431229.3726806
188 23169736.8528815
189 22911162.5896033
190 22655474.0151033
191 22402638.9250948
192 22152625.4746907
193 21905402.1743932
194 21660937.8861269
195 21419201.8193178
196 21180163.5270142
197 20943792.9020527
198 20710060.1732658
199 20478935.9017322
200 20250390.9770688
201 20024396.6137647
202 19800924.3475551
203 19579946.0318364
204 19361433.8341211
205 19145360.2325323
206 18931698.0123373
207 18720420.2625196
208 18511500.3723899
209 18304912.028234
210 18100629.2099989
211 17898626.1880153
212 17698877.5197571
213 17501358.0466366
214 17306042.8908361
it will take approximately 214 months to reach 15,394,279,987 dgb.
214 * 175200 = 37,492,800 blocks
37,492,800 + 1,430,000 = 38,922,800 blocks
------------------------------
Fix: In validation.cpp add on line 1249 before else.
else if (nHeight > 38922800 )
{
// End subsidy
return 0;
}
—
Reply to this email directly, view it on GitHub
<#20 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BJURTIXVD4NLIUFPOS23TGDZNGXXNAVCNFSM42I6RWC2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMRUGA4DANJRGEZQ>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Hard cap was implemented, corrected supply curve was not. No harm in discussing possible solutions; Jan's methodology above was quite a bit different than what I had in mind, but that's a good thing. I was thinking a dynamic emissions curve that adjusts over time, doesn't assume 15 second block times and hits cap on Jan 9th, 2035. |
There is no code in DigiByte 8.22 dev that stops at 21.000.000.000 DGB? The code I see gives 33 years of extra coins. If you want to change the supply curve you need a hardfork. At the start of the new curve. |
There is no hard cap. What has been implemented was the infinite supply fix, which is essential when reward is less than 1 the reward turns to 0. When the supply curve is fixed that will result in the hard cap. |
Supply curve change need an hardfork. It is not so hard to make a new curve. But when will this new curve start? |
Ahh I get it. Should the supply chain fix be added to the new core
protocol? That way before it's released with the hard fork we can do a 3
week notice to have everyone who needs to, update their nodes. Or is the
majority of running nodes dgb node 8 or older and this is too risky?
…On Sat, Jul 20, 2024, 2:58 AM Jan ***@***.***> wrote:
There is no hard cap. What has been implemented was the infinite supply
fix, which is essential when reward is less than 1 the reward turns to 0.
When the supply curve is fixed that will result in the hard cap.
Supply curve change need an hardfork. It is not so hard to make a new
curve. But when will this new curve start?
( Hardfork means every dgb 8 node or older will stop working. If they
agree.. Else you split the network in 2 )
—
Reply to this email directly, view it on GitHub
<#20 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BJURTITYRE3TJGYW4CFARGDZNIYGFAVCNFSM42I6RWC2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMRUGEYDMOBTGQ4A>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Yes all nodes are running DGB 7/8rc4 atm. DGB 9 can start with the new curve after X months. There is always a small risk with hard forks. Miners need to accept the changes and switch. Also all exchanges need to update their software. |
So "when the reward is less than 1 the reward turns to 0" isn't a functional hard cap? It just stops emitting coins at that point, but is not a "hard cap." |
Well it is a hard cap, but not 21b as everyone is expecting. Perhaps I should've been more clear. It's not the expected hard cap. |
Fix 1: Fix 2: ( End date not 01/06/2035. )
Fix 3: ( Total supply not 21B. )
|
DISCLAIMER
Infinite Supply Curve
In fact, people were already noticing that something is a little off regarding DigiByte's Supply Curve, as can be seen in this PR: #9
However, things are a bit different as they initially seemed.
The supply curve in its current version happens to be INFINITE.
DigiByte's maximum ever circulating supply is ∞ due to a little bug in the implementation.
The max total supply was supposed to be 21 Billion DigiBytes in the year 2035, however, in the following I am going to show what it really is like:
Supply Curve Simulation
The following plot illustrates the supply chain starting in the Genesis Block up to BlockHeight
110,579,600
:There are multiple jumps in the logarithmical graph due to many hardforks that DigiByte had, which basically means there are multiple ranges to consider if we want to calculate the maximum total supply. Let me elaborate on this for a second:
1440
blocks each block emits72000 DGB
digibyte/src/validation.cpp
Line 1226 in 3832a2d
5760
) each emit16000 DGB
digibyte/src/validation.cpp
Line 1230 in 3832a2d
67,200
a constant amount of8000 DGB
is emitted per blockdigibyte/src/validation.cpp
Line 1222 in 3832a2d
67,200
to block height400,000
the subsidy is decreased by 0.5% for every10080th
block.digibyte/src/validation.cpp
Lines 1179 to 1185 in 3832a2d
400,000
to block height1,430,000
the consensus was altered in a way that the decay factor was set to0.99
(-1%
) for every80160
blocksdigibyte/src/validation.cpp
Lines 1187 to 1193 in 3832a2d
0.98884
(-1.116%
) per month.digibyte/src/validation.cpp
Lines 1201 to 1210 in 3832a2d
So far so good. With this configuration it will take almost infinite time to reach rock-bottom (an emission of
0
per block).Why is the supply infinite?
Take a look at this line:
digibyte/src/validation.cpp
Lines 1238 to 1241 in 3832a2d
The supply will never be less than
1 DGB
with the current consensus due to this line.To put in a nutshell, empirical tests have shown that we reach this limit at block height
110579600
, which is a total supply of22,391,673,982 DGB
(not taking the genesis block into account).From there on, every block will emit exactly
1 DGB
.Non-Logarithmic plot of supply chain
Here is another plot (y-Axis cut off a bit) that shows how the supply chain looks:
How to proceed?
We should update the consensus (supply curve parameters) so that we reach a total of 21 billion DGB in year 2035. I am going to propose a valid solution soon.
The text was updated successfully, but these errors were encountered: