We now have our halving schedule implemented until the BR goes to zero.
The data was calculated via two new scripts which are in ./contrib :
$ ./contrib/hush_halvings
1,12500000000,340000
2,312500000,2020000
3,156250000,3700000
4,78125000,5380000
5,39062500,7060000
6,19531250,8740000
7,9765625,10420000
8,4882812,12100000
9,2441406,13780000
10,1220703,15460000
11,610351,17140000
12,305175,18820000
13,152587,20500000
14,76293,22180000
15,38146,23860000
16,19073,25540000
17,9536,27220000
18,4768,28900000
19,2384,30580000
20,1192,32260000
21,596,33940000
22,298,35620000
23,149,37300000
24,74,38980000
25,37,40660000
26,18,42340000
27,9,44020000
28,4,45700000
29,2,47380000
30,1,49060000
31,0,50740000
32,0,52420000
33,0,54100000
$ ./contrib/hush_block_subsidy_per_halving
0,1250000000,1125000000,125000000
1,625000000,562500000,62500000
2,312500000,281250000,31250000
3,156250000,140625000,15625000
4,78125000,70312500,7812500
5,39062500,35156250,3906250
6,19531250,17578125,1953125
7,9765625,8789062,976562
8,4882812,4394531,488281
9,2441406,2197265,244140
10,1220703,1098632,122070
11,610351,549316,61035
12,305175,274658,30517
13,152587,137329,15258
14,76293,68664,7629
15,38146,34332,3814
16,19073,17166,1907
17,9536,8583,953
18,4768,4291,476
19,2384,2145,238
20,1192,1072,119
21,596,536,59
22,298,268,29
23,149,134,14
24,74,67,7
25,37,33,3
26,18,16,1
27,9,8,0
28,4,4,0
29,2,2,0
30,1,1,0
31,0,0,0
These show that the block subsidy for miners goes to 0 at the 31st halving
and that the Founders Reward AKA Dev Tax goes to 0 at the 27th halving. There
is also some current KMD internals code that we inherited that prevents
the FR from being less than 10000, so that code would currently set our FR
to 0 at the 14th halving and lead less HUSH being mined than the planned 21M and
even a bit less than the amount under 21M that normally happens, such as in BTC.
We have some time to deal with the bug, since halving 14 is in about 52 years.
This commit drastically improves the privacy of the HUSH anonymity set
under attacks which ingest wallet.dat's which have been obtained by
seizure, i.e. stealing someones HUSH wallet.dat and putting it into
chain analysis software. Ciphertrace is known to do this to ZEC and XMR
and we can assume all chain analysis companies are implementing new
ways to de-anonymize privacy coins with any data they can obtain.
Instead of randomly sending to a randomly chosen static address,
hushd Sietch zdust addresses are now randomly generated at run-time. These
addresses are not stored in wallet.dat in any way and their private keys
are not known except by the internal memory of hushd for a few milliseconds.
This data is not stored in long-lived data structures of hushd, only as long
as the RPC z_getnewaddress is running or the equivalent function for internals
code paths. The seeds or private keys of these addresses are never stored on disk.
This now brings hushd on par with SDL, which already does this via a
different but equivalent seed phrase technique.
With this technique, if a HUSH wallet.dat is seized, it's impossible to tell
if any of the shielded outputs are random Sietch zdust with random data payload
or a one-time-use zaddr with encrypted payload.
DenioD