Skip to content
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

Reward fudge factor #867

Merged
merged 5 commits into from Oct 4, 2019

Conversation

@jagerman
Copy link

commented Oct 3, 2019

Adds a 1 atomic unit fudge factor.

The second commit is because I wasn't entirely sure how to handle the partial_block_reward variable when things are off by 1, but it turns out that it is not used at all so I just banished it completely.

jagerman added 4 commits Oct 3, 2019
If the thread's rounding mode is different (because RandomX changed it
in the current thread or in the thread that generated the block) then
the reward calculation can be up to 1 atomic unit off.  This lets those
pass rather than rejecting the block.

(I tested LOKI's reward calculations up to height 10M to verify that the
maximum error in reward values is never off by more than 1).
This variable is not actually used anywhere.
- fix the broken error message which was printing "base(base+fees)" instead
  of "total(base+fees)".
- improve the error message wording to actually indicate what the values
  signify.
- don't use base_reward as a temporary value (the intermediate value
  assigned to it is completely replaced later anyway).
- use some better variable names to describe what is happening here
// emission. This modifies the emission curve very slightly.
CHECK_AND_ASSERT_MES(money_in_use - fee <= base_reward, false, "base reward calculation bug");
if(base_reward != money_in_use)
partial_block_reward = true;
base_reward = money_in_use - fee;

This comment has been minimized.

Copy link
@Doy-lee

Doy-lee Oct 4, 2019

Collaborator

If someone generates a block template with no block reward, then this overflows. We either enforce that miners must take all the block reward (potential HF code) or I prefer personally, re-adding the base reward calculation bug sanity check.

This comment has been minimized.

Copy link
@jagerman

jagerman Oct 4, 2019

Author

Fixed.

@Doy-lee Doy-lee merged commit a3ebf5e into loki-project:dev Oct 4, 2019
1 check failed
1 check failed
continuous-integration/travis-ci/pr The Travis CI build failed
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.