Turn staking requirement into integer math variant #877

Doy-lee · 2019-10-08T07:43:33Z

Original comment and data points for the algorithm from @jagerman

x = 385824 429024 472224 515424 558624 601824 645024 688224 731424 774624 817824 861024 904224

y =  20458380815527 19332319724305 18438564443912 17729190407764 17166159862153 16719282221956 16364595203882 16083079931076 15859641110978 15682297601941 15541539965538 15429820555489 15341148800970

So, e.g., for H=450000 you'd get i=1, so:  intlsr = 19332319724305 + (450000 - 429024) * (18438564443912 - 19332319724305) / (472224 - 429024)
= 18898.351882603

versus 18872.560735094 from the LSR.

This is a linear step-down approximation of the staking requirement to remove the use of floating point math.

Will write some unit tests- to verify later.

src/cryptonote_core/service_node_rules.cpp

Executing RandomX has side effects on the current rounding mode depending on the hash program it generates and doesn't reset the rounding mode after the fact. So explicitly set it after.

jagerman · 2019-10-09T00:42:50Z

src/cryptonote_core/service_node_rules.cpp

@@ -77,11 +77,8 @@ uint64_t get_staking_requirement(cryptonote::network_type m_nettype, uint64_t he
  uint64_t base = 0, variable = 0;
  if (hf_version >= cryptonote::network_version_11_infinite_staking)
  {
-    auto round_method = std::fegetround();
-    std::fesetround(FE_TONEAREST);


I think this fesetround should stay: I don't think there's any particular guarantee as to what rounding mode the thread is in without an explicit call, and I'm assuming it's essentially a no-op if setting it to the mode it's already in.

And updated.

Instead of implicitly relying on the mode we expect it to be

Turn staking requirement into integer math variant, courtesy of Jagerman

6194ab1