helium/blockchain-core

PoC reward is not correct with Beacon and invalid witness

AndyGanquan opened this issue · 4 comments

Invalid reward issue: From rewards distributed for a beacon with varying number of witnesses in HIP15, if there are invalid witness, the reward of beacon(TX) will be reduced (TX scale )by invalid. But I found that all the reward of beacon keep the same if valid witness more than 4. And the reward of witness(RX) is not as doucument expressed. the whole rewards distributed need to be correct when invalid witness there.

Beacon reward issue: from rewards distributed for a beacon with varying number of witnesses in HIP15, the reward of TX will increase when the valid witness increase while it will decrease the reward of TX will decreas when the valid witness decrease. but I found that all the reward of TX are same at same block.

vihu commented

Thanks for the report @AndyGanquan

Can you also please refer to hip17 which has the methodology for constructing TxScale based on Hotspot densities and it does not reduce the TxScale depending on whether the witnesses were invalid. blockchain-core at present is running hip17 based tx_scale calculation. I am not opposed to factoring in invalid witnesses (as mentioned in HIP15) + density based calculation (as mentioned in HIP17). So for example we could do new_tx_scale = hip17_tx_scale * (invalid_witness_count / total_witness_count) but that process would need to come through an amendment to HIP15/17.

From my opinion, HIP15 and HIP17 are compatible with each other, HIP17 rules should not break HIP15 rules.
new_tx_scale = hip17_tx_scale * (invalid_witness_count / total_witness_count) should be the correct implementation for current HIP.

@Carniverous19 Would you like make some comments on this topic?

I'm not sure if this would be a good idea, I would agree that in HIP15 it mentions the use of scaling the transmitter based on the number of valid witness / total witnesses.. however, I feel that this would benefit "bad actors" more than help the "good actors". A quick example, where I could see this be an issue, imagine if you had a "miner farm" that has the Man in the Middle software created by Carniverous19 and made it where they would be invalid witnesses to every hotspot that's not in the farm.

This would result in the "good actors" getting invalid witnesses from the farm resulting in reduced rewards while the farm would simply miss out on 4 beacon rewards (HIP 15 example shows 1.0 total reward unit) a day max from that good neighbor. The farm would then get perfect beacon rewards and witness rewards. I don't think invalids should be used during reward calculations because rain could cause a good witness to be invalid one day while it was a great witness every other day..

closing, stale.