search

helium / HIP

Helium Improvement Proposals
Apache License 2.0
583 stars 407 forks source link

HIP5: POC fairness/epoch reward limit #24

Closed jamiew closed 4 years ago

jamiew commented 4 years ago

Authors: @tjain-mcc

Original PR: https://github.com/helium/HIP/pull/19

Rendered view: https://github.com/helium/HIP/blob/master/0005-poc-fairness.md

Summary from HIP:

Proof of coverage challenge participation rewards are too concentrated for the top few hotspots. This has led to a concentration of mining rewards which are not ideal for the proliferation of the Helium Network.

I propose that we cap the number of challenges any given hotspot can participate in during a single Epoch.

Carniverous19 commented 4 years ago

Some potential concerns:

  1. PoC paths are planned well before they are executed so you dont get the receipts on whether a certain hotspot successfully completed a previous PoC before a new one is planned. So you cant really determine "hotspot H already passed X challenges this epoch so I wont send another". I think that would require significant changes to how PoC paths are calculated.
  2. Since a lot of PoC paths fail early in the chain you really cant assume a planned PoC is executed, the 4th and 5th slot has like a < 5% chance of even reaching there.
  3. Its possible this could penalize neighboring hotspots. For example, a subset of hotspot owners invest $$ and effort into upgrading their antennas and roof mounting with low loss cabling this could allow these "tent-pole" hotspots to communicate with neighbors that otherwise woudl be isolated. If you limit the PoC's these "tent-pole" hotspots can participate in you possibly limit cause the nearby hotspots to be ineligible to participate in a PoC if they are targeted after other neighbors.

You could implement the cap a posteriori by only considering the first X successful receipts from a hotspot in an epoch so those that are "tent-poles" can still be targeted and verify their neighbors they just wont be rewarded after a certain number. This could cause some issues as some malicous hotspot owners (or malicous DIY owners) could just not forward potential challenge messages after X + some margin (Not sure why they would do this, slightly decrease # of PoC receipts thus slightly increasing the reward for each receipt?) The general issue doing this after the fact is hotspots are being asked to do work they will not be rewarded for.

A modified version of this is to reward hotspots based on the length of time between successful PoC's. If a hotspot passed a PoC 5 minutes ago the knowledge gained by it passing a PoC again is small (If you were up and running 5 min ago, its likely you are still up and running). If it has been an hour since your last PoC then the knowledge of a passed PoC is higher since the odds that a hotspot is no longer reachable after an hour is higher than 5 minutes. So you basically pro-rate rewards based on last valid receipt. This give a hotspot a reward each time it does work and can all be calculated a posteriori when rewards are calculated. It is significantly more complicated math than just capping # of reciepts.

tjain-mcc commented 4 years ago

I tried to update my HIP to say that hotspots would not be rewarded for participating in more than 1 challenge per epoch rather than participate in more than 1 challenge per epoch. Not sure why it isn't showing up

Carniverous19 commented 4 years ago

You shouldn't limit to 1 challenge, especially not this early, why not 2 or 3 or 5? certainly there is advantage to some redundancy and those hotspots that can reach more than 1 hotspot should get some reward. With just 1 PoC rewarded you will get hotspots paired off with yagi's pointed at eachother. You want to encourage wide, omidirectional reach.

Still some limit may be worthwhile. Certainly 20 PoC's in an epoch is a bit extreme but I would leave the limit as a generic number "N" for now without more analysis into what "N" should be. I would say 1 is too low to encourage healthy, redundant coverage

tjain-mcc commented 4 years ago

I think limiting rewards to 1 challenge is ok but the hotspot should be able to join as many challenges as possible. But there is nothing the network gains by rewarding a hotspot for more than 1 challenge per epoch. The network already knows that the hotspot is providing useful coverage, why does it need to pay for that info again in the same epoch?

Carniverous19 commented 4 years ago

@tjain-mcc Why would a hotspot care to participate in more than 1 challenge? a single PoC verifies a point in time and coverage along a line. There is certainly some value in verififying at different points in time and along different lines. It also gives the hotspot a reason to forward PoC packets. A lot of PoC packets are pretty large compared to organic LoRa sensors so it is somewhat easy to detect them and just drop them late in an epoch or after a hotspot determines it has participated in a few already. with only 1 challenge per epoch reward it is in a hotspots best interest to prevent future PoC's from going through it and not participate. DIY makes this easier to control

tjain-mcc commented 4 years ago

What about diminishing rewards for multiple challenges in an epoch? More technical complexity which I dislike but addresses your concern.

Carniverous19 commented 4 years ago

@tjain-mcc Yes I like that, it also acts as a soft limit you could do something like each additional PoC is worth X% the previous. This could even be some relative high percentage like 80% and still be effective. For example:

PoC/Epoch Reward % Total Reward %
1 100 100
2 80 180
3 64 244
4 51 295
5 41 336
10 13 446
15 4 482
20 1.4 494

With each PoC worth 80% the previous a hotspot performing 20 PoCs per epoc would be rewarded 5x the amount as one PoC (while doing 20X the work).

At low end there is still significant reward for each additional POC in the 1-4 range so it still encourages redundant coverage and more regular verification.

could be 90% or 75% or 50% we should look at these numbers a bit more if this is a direction people want to go for this HIP but In general I like it! even more than a hard cap.

lthiery commented 4 years ago

To visualize:

image

As for the idea, to be clear, I think it is implying that a Miner wouldn't earn anything for doing over 20 POCs / epoch (but would probably do the work still). The table makes it easy to implement the decaying reward structure for end of epoch calculation (I would think) so I like that.

Does the table version number add a chain var?

Carniverous19 commented 4 years ago

Hi @lthiery ,

So with the chart I just gave some example counts to make it easier to understand (like your chart!). My idea is this would continue for any number of PoC's so the 50th PoC would earn 0.0018% the reward of the first PoC. It is essentially a geometric sum which is asymptotic to 1/(1-X%) so an 80% will plateau at 5x (500%). 95% will plateau at 20x (2,000%) even with an infinite number of PoC's. This has the advantage that a hotspot gets rewarded for every PoC just a smaller and smaller amount. An example of various possible decay values:

Zoomed in on 10 challenges per epoch:

I would say this would introduce a single chain var which would be this "X%" or the decay for each additional PoC. It shouldnt be too difficult to implement as well although you would have to match receipts to hotspot participants and perform the weighing in order get a sum of the "effective" PoCs per epoch to know how to divide up rewards. This is also a bit more complicated as they actually split PoC into 3 segments (RF receipt, RF transmit, and Delivering receipt over P2P). Should each segment be weighted seperately (ie if I receive RF 3x the 3rd gets 64% weight but if I only successfully transmit once that gets 100%).

Overall though I think this is definitely a good way to address these tent-pole hotspots getting extremely high rewards without providing much additional value. Like you say after a few PoC's we know they are there providing coverage, after that they are just a vessel for other hotspots to prove coverage.

lthiery commented 4 years ago

Fair enough! Decaying function is succinct.

I have an aversion for floating point calculations from doing mostly embedded development so I always like a good look-up table, but in this case, brevity/simplicity seems nicer.

Carniverous19 commented 4 years ago

For justification beyond "owner XXX is getting too much reward we want more!" I do think there is less valuable in verifying a hotspot every minute or even multiple times a minute. The hotspot is doing work (participating in the PoC and is providing extra, redundant verification of its location but the value to the network of this repetitive verification is diminished the more often it is verified.

Its like a 5 year old sitting in a car during a road trip asking "are we there yet". Asking every 30-40 minutes seems reasonable, time has passed, things might have changed. Asking every 10 seconds is annoying as obviously the answer is the same as it was 10 seconds ago.

A modification to the proposed decay that may acknowledge that the work of verifying neighbors by participating in a path is still valuable would be to set a lower limit on the incremental value of PoC of something like 1-15% of the normalized value of a PoC. This would eliminate the asymptote and end up giving constant but small reward for each additional PoC once the decay hits this min threshold.

anthonyra commented 4 years ago

For justification beyond "owner XXX is getting too much reward we want more!" I do think there is less valuable in verifying a hotspot every minute or even multiple times a minute. The hotspot is doing work (participating in the PoC and is providing extra, redundant verification of its location but the value to the network of this repetitive verification is diminished the more often it is verified.

Its like a 5 year old sitting in a car during a road trip asking "are we there yet". Asking every 30-40 minutes seems reasonable, time has passed, things might have changed. Asking every 10 seconds is annoying as obviously the answer is the same as it was 10 seconds ago.

A modification to the proposed decay that may acknowledge that the work of verifying neighbors by participating in a path is still valuable would be to set a lower limit on the incremental value of PoC of something like 1-15% of the normalized value of a PoC. This would eliminate the asymptote and end up giving constant but small reward for each additional PoC once the decay hits this min threshold.

With this when you mention PoC I'm assuming you're talking about PoC challengees? Or will this also affect the PoC witness group?

anthonyra commented 4 years ago

My HIP 5 that builds off of my proposed HIP 10 distribution of the Data Network Transfer pool: See HIP 10 for full post: https://github.com/helium/HIP/issues/32

This proposal for HIP 5 suggests a change to the Beneficiary for the PoC challenger reward pool specifically by applying a restriction to what a Rural / Single Hotspot should be considered and splitting the Consensus Group into two individual parties. It also recommends a change in the limitation on a hotspot in regards to being a challenger.

The current limitation for being a challenger is that each hotspot on the network can only be a challenger for a PoC proof once an epoch. Removing the grouped hotspots will drastically reduce the overall PoC proofs being submitted to the blockchain. To compensate I suggest allowing the Consensus Group Candidates (currently at 2528) the ability to fill in the rest.

For Example: If there are only 1600 hotspots that now meet the new definition of Rural / Single Hotspots on the network they would only supply 1600 PoC proofs that epoch. The remaining 5400 proofs could come from the Consensus Group Candidates meaning most will average roughly 2 challenges created per epoch.

With the 33.45% each challenger will earn roughly 0.16 HNT per epoch.

This will provide virgin coverage area hotspots (Rural / Single Hotspots) better incentives than currently and also provide known good hotspots (Consensus group worthy hotspots an additional incentive for having a high S word)

New Definitions: Rural / Single Hotspot: Are hotspots that have not successfully been a challengee or witness to any PoC proof before. Consensus Group Candidate: Meets the requirements to be a Consensus Group Selectee but doesn't get selected for the current Consensus Group. Consensus Group Selectee: One of the members of the Consensus Group.

New HIP 10 with HIP 5 Proposed Distribution: Per Month Reward Pool % HNT Beneficiary
PoC Challengers 33.45 1,672,500 Rural / Single Hotspot, Consensus Group Candidate
PoC Witnesses 8.55 427,500 Grouped Hotspot, Consensus Group Candidate, Consensus Group Selectee
PoC Challengess 18 1,963,604 Grouped Hotspot, Consensus Group Candidate, Consensus Group Selectee
Consensus Group 6 300,000 Consensus Group Selectee
Data Network Transfer 0.0010 50 Rural / Single Hotspot, Grouped Hotspot, Consensus Group Candidate, Consensus Group Selectee
HST Holders 34 1,700,000 N/A
Total 100 5,000,000 ---

With the HIP 10 distribution and the new limitation on the beneficiary per reward pool in regards to PoC challengers the max a grouped hotspot could acquire per month is now at 24.55% instead of 58%. Consensus Group and Rural/Single hotspots will have an increased reward pool in the interim where network traffic hasn't reached its max at 32.5%. However, once data traffic does catch up than those rural hotspots will become useless in terms of minting HNT.

Carniverous19 commented 4 years ago

Interesting idea @anthonyra and I need to read it again but there are some general concerns that have been mentioned before about such a large percentage going to challenge creation:

At the end of the day, significant reward for challenge creation just wont happen, and I think there is enough to encourage growth of the network into new areas as long as more than one hotspot can be deployed.

TLDR: challenge creation is very easy to game, provides almost no value to the network and shouldnt be highly rewarded. Also lots of rural areas just arent valuable and its ok that the network doesnt motivate growth in those areas.

Carniverous19 commented 4 years ago

With this when you mention PoC I'm assuming you're talking about PoC challengees? Or will this also affect the PoC witness group?

Good point, I was talking about challengees but we should look at witness as well.

anthonyra commented 4 years ago
  • One is that its a very low value activity that will completely break when you allow DIY hardware. DIY hardware will allow me to "claim" to deploy thousands and thousands of hotspots in the vast swaths of rural areas in the USA (and soon around the world) with an AWS account. So heavily rewarding challengers will block allowing DIY.

This would be invalid if HIP 9 is implemented or the like.

DIY Hotspots will fall under 4 levels: https://github.com/helium/HIP/blob/7b715a0614d4c529144e1d6c0083ee8b38c05b29/0009-non-helium-hotspots.md

Level I: Network Observer - Which can only be rewarded with PoC witnesses. Meaning that they have to have active hotspots near them participating in PoC challenges.

Level 2: Network Participant - PoC challenges are then activated. To get to this point, however, requires specific requirements to be met which will require significant work to abuse.

Level 3A: Organic Network Challenger (OEM hotspots) Level 3B: Governance Network Challenger - If they could get to this point then I feel the path for abusers is really arduous but relatively straightforward for "good actors"

Level 4: Consensus Candidates

New HIP 10, HIP 5, and HIP 9 Proposed Distribution: Per Month Reward Pool % HNT Beneficiary
PoC Challengers 33.45 1,672,500 Rural / Single Hotspot, Consensus Group Candidate, DIY LVL 3-4
PoC Witnesses 8.55 427,500 Grouped Hotspot, Consensus Group Candidate, Consensus Group Selectee, DIY LVL 1-4
PoC Challengess 18 1,963,604 Grouped Hotspot, Consensus Group Candidate, Consensus Group Selectee, DIY LVL 2-4
Consensus Group 6 300,000 Consensus Group Selectee, DIY LVL 4
Data Network Transfer 0.0010 50 Rural / Single Hotspot, Grouped Hotspot, Consensus Group Candidate, Consensus Group Selectee, DIY LVL 1-4
HST Holders 34 1,700,000 N/A
Total 100 5,000,000 ---

With this break down above, as the network grow which it will the rewards are also minimized. For example, the Challenger pool rewards at 33.5% (which it'll decrease with network growth) is only 0.16 HNT per epoch with 7000 units. That's the most a rural hotspot will see until more neighbors show up.

anthonyra commented 4 years ago
  • This also heavily rewards hotspots that are in the wrong country! You noticed a few hotspots showing up in the UK, mainland Europe, some in Asia before Helium went live there. These are US hotspots that someone imported. These will never provide any meaningful RF coverage because they use the wrong frequencies for their region yet will get a slice of 50% of the HNT for hotspot owners just for existing... These hotspots should not be rewarded.

Sounds like there should be a validation check during the assert_location step that should check Frequency to suggested location placement.

anthonyra commented 4 years ago
  • Single lone hotspots aren't reliable coverage. I get the motivation to encourage people to seed new areas but a single hotspot in a new town does not provide any meaningful coverage. There is no redundancy to the coverage and anyone relying on getting LongFi in that area is 100% dependent on a single individual to maintain that coverage. That hotspot owner may move, or decide to place the hotpsot differently. Or even with the hotspot staying in position someone might park a car in between the single hotspot and a sensor blocking coverage. You need redundancy even over the same area for the coverage to really be reliable, thus I like PoC as it (ignoring gaming for now) ensures overlap in RF coverage from hotspots in different locations.

Imagine if you are a newcomer to Helium and created a "lone wolf" hotspot. You see with my proposed distribution roughly 40HNT a week. That means an ROI of about 6.4 weeks for that first hotspot. You then understand that once you complete a successful challenge and witness you fall out of that reward pool. However, you also know that the PoC challenger reward is capped at 1 PoC proof per epoch. Whereas the PoC challengee and witness pools are capped at 20 PoC per epoch. You should theoretically see a jump as much as 20x the rewards as before. If you can't motivate a neighbor with those numbers than those numbers should motivate you in re-investing that 7 weeks of return into a second hotspot to start getting to that 20x reward.

The 40 HNT a week is also dependent on the network not increasing. If you incentive "lone wolfs" and then them growing into grouped hotspots. It wouldn't be crazy to think the network could double to 14,000 and that reward pool now shrunk to 20 HNT a week and so on.

Carniverous19 commented 4 years ago

@anthonyra I know HIP 9 well (see comments on that HIP). HIP9 alone is not effective at trusting DIY, it just means an exploiter just needs access to 1 real hotspot in an environment. It is only effective if PoC is super bulletproof which if it is, kind of eliminates the need for HIP9 anyway as you have bulletproof PoC to determine validity of a hotspot with. So I think HIP9 doesnt do anything. we have to wait for the mystery new PoC algo. Lets move discussion on "lone wolfs" to your HIP12 and keep this one focused on limiting PoC rewards.

EDIT: for those following HIP12 issue is: https://github.com/helium/HIP/issues/38

anthonyra commented 4 years ago

@anthonyra I know HIP 9 well (see comments on that HIP). HIP9 alone is not effective at trusting DIY, it just means an exploiter just needs access to 1 real hotspot in an environment. It is only effective if PoC is super bulletproof which if it is, kind of eliminates the need for HIP9 anyway as you have bulletproof PoC to determine validity of a hotspot with. So I think HIP9 doesnt do anything. we have to wait for the mystery new PoC algo. Lets move discussion on "lone wolfs" to your HIP12 and keep this one focused on limiting PoC rewards.

EDIT: for those following HIP12 issue is: #38

It can be a pretty solid start.. I haven't really put too much thought into HIP 9 because I feel that 10 and 5 should be implemented first. With that being said. If you can make the first two successful while keeping in mind DIY is on the horizon I think it'll work.

anthonyra commented 4 years ago

@tjain-mcc Yes I like that, it also acts as a soft limit you could do something like each additional PoC is worth X% the previous. This could even be some relative high percentage like 80% and still be effective. For example:

PoC/Epoch Reward % Total Reward % 1 100 100 2 80 180 3 64 244 4 51 295 5 41 336 10 13 446 15 4 482 20 1.4 494 With each PoC worth 80% the previous a hotspot performing 20 PoCs per epoc would be rewarded 5x the amount as one PoC (while doing 20X the work).

At low end there is still significant reward for each additional POC in the 1-4 range so it still encourages redundant coverage and more regular verification.

could be 90% or 75% or 50% we should look at these numbers a bit more if this is a direction people want to go for this HIP but In general I like it! even more than a hard cap.

Reading this over again to see how implementing this HIP along with HIP 10.. I noticed something. If you rewarded a hotspot that was a PoC challengee for up to 20 challenges. Couldn't that mean the first 1400 hotspots (based on 7000 on the network) to first reach 20 will collect the entire reward pool for that epoch?

anthonyra commented 4 years ago
The below table shows the rewards based on the following network data: Network Stats
Network Size 6,894
"Lone Wolf" Hotspots 3,518*
Grouped Hotspots 3,376
HNT Oracle Price $1.69
DC Price $0.00001
Block Time 77 sec
Epoch Time 38.5 mins
Epoch per Week 262

*Includes hotspots that are new to the network because this number is based on a hotspot score == 0.25

Current HIP 10 HIP 5
PoC Challenger 0.95% 2.0727% 2.0727%
PoC Challengee 18% 39.2721% 39.2721%
PoC Witness 8.55% 18.6542% 18.6542%
Data Network Traffic 32.5% 0.0010% 0.0010%

The above HIP 10 intentions were to prevent the DC arbitrage that was occurring by ensuring that the DC spent to move data was rewarded to the hotspot moving that data. However, with the new distribution of the remaining 32.5% is supposed to distributed rationally across all PoC reward pools.

If you were to take the above table but look at the hotspots that benefit from each reward and potential gains there are issues that arise taking into account network size also.

"Lone Wolf" % Reward HNT per epoch Network Size HNT per Hotspot HNT per Week
PoC Challenger 2.0727% 70.9829278 HNT 6,814* 0.01041722 HNT 2.73 HNT
PoC Challengee 39.2721% 1,344.9359 HNT 0** 0 HNT 0 HNT
PoC Witness 18.6542% 638.842026 HNT 0** 0 HNT 0 HNT
Total: 2.73 HNT

*Since all hotspots on the current network can perform 1 PoC proof (1 challenger reward) per epoch the overall HNT reward pool needs to be divide by the entire network size. **"Lone Wolf" hotspots due to not being close to any other hotspot or due to physical barriers (building, hills, tree, etc) can't have a successful challengee or witness of a PoC proof.

"Grouped" / Consensus Group % Reward HNT per epoch Network Size HNT per Hotspot HNT per Week
PoC Challenger 2.0727% 70.9829278 HNT 6,814* 0.01041722 HNT 2.73 HNT
PoC Challengee 39.2721% 1,344.9359 HNT 3,374 0.39861763 HNT 104.4 HNT
PoC Witness 18.6542% 638.842026 HNT 3,374 0.18934263 HNT 49.6 HNT
Total: 156.73 HNT

*Since all hotspots on the current network can perform 1 PoC proof (1 challenger reward) per epoch the overall HNT reward pool needs to be divide by the entire network size.

Concerns: This switches the ideal reward scheme back to what was occurring in Port Huron before the DC percent was changed. It also greatly reduces the onboard of new people in the act of building out the network. Companies or Patrons with money will be able to instantly tap into the resources provided by having more than one hotspot in a location.

HIP 5: Introduces and 80% decrease with every additional PoC receipt (successful challengee or witness). This could result in the first 1400 hotspots to be rewarded with the full reward pool. Which is indeed the worst-case scenario however if you have a bigger grouping of hotspots (Port Huron) is it more or less likely that those will be picked for PoC proofs? Because an island of 4 hotspots will at most be picked 4 times per epoch. Since that island can only receive a max of 1 per hotspot to initiate the PoC proof.

"Grouped" / Consensus Group % Reward HNT per epoch Network Size HNT per Hotspot HNT per Week
PoC Challenger 2.0727% 70.9829278 HNT 6,814* 0.01041722 HNT 2.73 HNT
PoC Challengee 39.2721% 1,344.9359 HNT 1,400 0.9606685 HNT 251.7 HNT
PoC Witness 18.6542% 638.842026 HNT 1,400 0.45631573 HNT 119.6 HNT
Total: 374.03 HNT

*Since all hotspots on the current network can perform 1 PoC proof (1 challenger reward) per epoch the overall HNT reward pool needs to be divide by the entire network size.

Carniverous19 commented 4 years ago

@anthonyra this seems off topic. Disuss HIP10 in the HIP10 issue or Discord. Discuss concerns about "lone wolfs" which has nothing to do with PoC in HIP12 issue.

This HIP has nothing to do with the percentage of Helium distributed to PoC or Witness just "given a total of X HNT to be distributed for PoC this epoch how should it be divided among the set of all PoCs performed this epoch". That X% of HNT could be 0.1% could be 99% doesnt matter as far the proposals in this HIP go.

anthonyra commented 4 years ago

@anthonyra this seems off topic. Disuss HIP10 in the HIP10 issue or Discord. Discuss concerns about "lone wolfs" which has nothing to do with PoC in HIP12 issue.

This HIP has nothing to do with the percentage of Helium distributed to PoC or Witness just "given a total of X HNT to be distributed for PoC this epoch how should it be divided among the set of all PoCs performed this epoch". That X% of HNT could be 0.1% could be 99% doesnt matter as far the proposals in this HIP go.

This HIP is about PoC rewards no?

The only new concept is a limitation on how many times a given hotspot can successfully participate in a proof of coverage challenge in a given Epoch. I propose that a hotspot can only successfully participate in a challenge X times per Epoch.

Carniverous19 commented 4 years ago

@anthonyra It is about how hotspots that participate in many PoC's per epoch should be rewarded relative to those that perform 1 to a few PoCs per epoch. Nothing to do with lone wolves nothing to do with DC arbitrage. Nothing to do with what percentage of the 5M HNT per month should go to PoC (as I said above, could be 0.1%, could be 99% doesnt effect this HIP).

Purely "hotspot A did 1 PoC this epoch, hotspot B did 10 PoC this epoch, how much more should hotspot B be rewarded than hotspot A"

anthonyra commented 4 years ago

@Carniverous19 All I'm trying to do in the above table is trying to determine your 100% reward and what 494% would mean. If you don't agree with how I tried to determine that could you edit your above table or make a new one to show what the rewards of Hotspot A with 1 PoC that epoch is, than Hotspot B at 10 PoC, and than Hotspot C at 20 PoC in terms of HNT would be?

Carniverous19 commented 4 years ago

ah I see what you are talking about, When I say reward % its " relative reward compared to 1 PoC" ignoring HNT amounts entirely. so 100% doesnt mean 100% of HNT mined per epoch it means 100% of value of 1 PoC whatever that is.

So in the table, a hotspot that performs 20 PoC in an epoch will earn 494% of the HNT of a hotspot that performed 1PoC in that epoch. and that 20th PoC earned 1.4% as much as the first PoC. So that could be 0.0000100 HNT vs 0.0000494 HNT or it could be 1.00 HNT vs 4.94 HNT. Its all normalized by the value of 1PoC in an epoch.

More specifically with my X% = 80% like the first table Hotspot B's HNT earned / Hotspot A's HNT earned = 4.46 Hotspot C's HNT earned / Hotspot A's HNT earned = 4.94 Hotspot C's HNT earned / Hotspot B's HNT earned = 1.107

Note hotspot C earns only 10.7% more than hotspot B even though it participated in double the # of PoC's.

You cant put raw HNT numbers to any of this as it all depends on how many successful PoC hops there were in a given epoch as well as the distribution of HNT to PoC which changes over time. Thats why the best way to think about it is in ratios.

anthonyra commented 4 years ago

I'm curious on what max PoC number would best represent the network.

The reason I bring this up is that the current person making the max from PoC rewards is only averaging 12 PoC per hotspot of the 36 they own. With the average sitting at around 3 which would be consistent with a hotspot with 2-3 neighbors.

Carniverous19 commented 4 years ago

Good questions @anthonyra certainly a good next-step is to apply some of these %X's to real-world data and see how the distribution of HNT changes and look closer at the big winners and big looser to make sure "work" and "proof" are being rewarded appropriately. Good to know ~12PoCs/epoch is high so analysis can focus on like the 1-20 PoC range and dont have to worry about 1-100+ PoC range (depending on future PoC algorithm changes).

Im waiting for an ETL instance to load and once that is done (probably another few days). I'll pull some sample epochs and show distribution changes at various percentages.

jamiew commented 4 years ago

As discussed on last community call, we're retiring this HIP as no longer applicable: https://docs.google.com/document/d/1bMm2alBigBj3detA775Dn0Gz9UM5XczAeK9vnjBB3l0/edit#heading=h.afj80v7w0lhh

Thank you for your participation

stefanv commented 3 years ago

@jamiew I looked at the notes you linked, but they don't explain why the HIP wasn't relevant any longer. Do you have another document or discussion that explains it?

stefanv commented 3 years ago

Related:

https://github.com/helium/HIP/blob/master/0015-beaconing-rewards.md https://github.com/helium/HIP/blob/master/0017-hex-density-based-transmit-reward-scaling.md