-
Notifications
You must be signed in to change notification settings - Fork 86
Conversation
Codecov Report
@@ Coverage Diff @@
## master #662 +/- ##
==========================================
+ Coverage 68.40% 68.68% +0.28%
==========================================
Files 94 94
Lines 12311 12362 +51
==========================================
+ Hits 8421 8491 +70
+ Misses 3890 3871 -19
Continue to review full report at Codecov.
|
Here are the scaling factors from HIP 15 in erlang code:
|
relevant GH Issue #673 |
ea3a6d9
to
8da40c3
Compare
ct:pal("Txn: ~p", [Txn]), | ||
|
||
%% Construct a block for the poc receipt txn WITHOUT validation | ||
{ok, Block2} = test_utils:create_block(ConsensusMembers, [Txn], #{}, false), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we disable validation so we don't need to deal with pathing?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, pretty much. Also didn't really see any need to do a poc request then receipt cycle since we only care about the rewards here. lmk if that's acceptable...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Initial impression of this looks very good. I will try to go through it more deeply soon.
@@ -604,11 +677,21 @@ poc_witnesses_rewards(Transactions, | |||
[] -> | |||
Acc1; | |||
ValidWitnesses -> | |||
ToAdd = case {WitnessRedundancy, DecayRate} of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we inline some of the documentation here? it's clear enough what it's doing, but I'm at sea wrt why
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, added 5f87842
[[blockchain_utils:addr2name(blockchain_poc_witness_v1:gateway(W)) || W <- ValidWitnesses]]), | ||
ValidWitnesses | ||
catch What:Why:ST -> | ||
lager:error("failed to calculate poc_challengees_rewards, error ~p:~p:~p", [What, Why, ST]), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is it possible to do this differently depending on how many blocks back you have? in which case we might want to determine if we need more snap history to avoid drift
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, this isn't new code, I simply moved this piece out in order to meck it in the test. I will however run a resync with revalidation with this just to be certain.
I know it's going to work |
Refer: https://github.com/helium/HIP/blob/master/0015-beaconing-rewards.md
poc_reward_decay_rate
(r) andwitness_redundancy
(n)TODO: