Open s-a-y opened 10 years ago
I know the problem. I haven't had a chance to patch. I will soon though.
Thanks, Jed, waiting
Tough to beat 97 billion
If anybody vote the g4eRqgZfzfj3132y17iaf2fp6HQj1gofjt, why don't we just vote gDSSa75HPagWcvQmwH7D51dT5DPmvsKL4q through your account?
It turns out to be a bit more complicated to get this working well. We will have to refactor some things before we can run inflation again.
@aryadega not sure what you mean?
Out of technical interest, @jedmccaleb, could you point out the underlying issue? I assume it lies somewhere in https://github.com/stellar/stellard/blob/master/src/ripple_app/transactors/InflationTransactor.cpp
@abrkn Iterating all accounts (~600K) takes a lot of time at the moment, some optimization needs to be implemented.
That was my guess. Thanks, @marco89nish
As an update on this: inflation is bundled with the backend changes that should go out shortly. Main issue was that inflation is an expensive operation that would kill nodes running on non high end hardware. With the new architecture it will run on any node even with a modest setup
I'm investigating, why Inflation doesn't happen when it supposed to: All inflations go to address g4eRqgZfzfj3132y17iaf2fp6HQj1gofjt, because it has 97 bln STR behind it.
1) First inflation happened in ledger 113 (not July 1st as it's written in stellard comments) TIME STAMP: 1405300900 DATE (M/D/Y @ h:m:s): 07 / 14 / 14 @ 1:21:40am UTC
2) Second inflation in ledger 17018 (too early) TIME STAMP: 1405635360 DATE (M/D/Y @ h:m:s): 07 / 17 / 14 @ 10:16:00pm UTC
3) Third inflation in ledger 75519 TIME STAMP: 1406800490 DATE (M/D/Y @ h:m:s): 07 / 31 / 14 @ 9:54:50am UTC
4) Fourth inflation in ledger 75521 (just 30 seconds later) TIME STAMP: 1406800520 DATE (M/D/Y @ h:m:s): 07 / 31 / 14 @ 9:55:20am UTC
And that's it, no other inflations so far. Please check, something's wrong.