We've briefly seen the paper, it's good to see time taken to do
outsider's analysis.
regarding fingerprint, problem is the data used:
- the doc takes all harvested, but balance/importance of an account could change over time... (i.e. take a look at funny outliers presented in a table above, that have high hBlks/r_imp_H, balance is very low, what does it tell you? the doc even states Balance: r_hBlks / r_imp_H has a weak correlation 0.344 should it really be surprising if you take ALL harvested blocks, but take only LATEST importance?)
- fingerprint graph on x has balance, on y has hBlks/r_imp_H,
- mind that there's correlation between balance and importance...
- as you can see pattern emerges for low amounts (10k - 100k), so emerging pattern shouldn't really be surprising,
with low amount you probably generate only few blocks (10-100) so what you have on this image is / importance x balance,
i.e. compare two accounts with same r_imp_H, where one harvested 9 blocks and other 10 blocks: (9 / 1601000) / (0.00003) = 0.1873 vs (10 / 1601000) / (0.00003) = 0.2082, thats' where the vertical gaps come from,
horizontal linearity should be obvious as well, bigger balance == bit bigger importance, i.e (10 / 1601000) / (0.000031) = 0.2014 vs (10 / 1601000) / (0.000030) 0.2082
yes, those were good explanations ...
you
insiders can easier explain the empirical studies and "phenomenons"
> ALL harvested blocks, but take only LATEST importance
yes, that is also in the doc's last statement: "
Also the statistics of current states should be replaced with the values, which are more related to the moment of the occured harvesting"It is a honest wish, that you
insiders would make a total proof against that "practical claim"
The total proof would be e.g. such a re-simulation, where the current blockchain is re-run and for each harvested block the importance of the harvester is computed. Then would be possible to get the actual importance, and then also the numbers, which set the PoI in the more correct position when compared to PoS.
or ...
maybe no re-simulation is needed, but only use of this :
Retrieving historical account data
API path: Request type: GET
/account/historical/get
=>
{
"data": [
{
"height": 17592,
"address": "NALICELGU3IVY4DPJKHYLSSVYFFWYS5QPLYEZDJJ",
"balance": 509676000000,
"vestedBalance": 100999147150,
"unvestedBalance": 408676852850,
"importance": 0.00008857563463531297, /* IMPORTANCE */
"pageRank": 0.0007605047835049349
}
]
}
Strange that the function was missed in the study
New (added in some phase?) feature in the API, or just busy, or "blindness" in reading the API version X ...
To the API should be added also
/account/future/get/moretime
/account/future/get/vacation ...