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

HIP 54: H3Dex-based PoC Targeting #347

Closed
hiptron opened this issue Feb 3, 2022 · 6 comments
Closed

HIP 54: H3Dex-based PoC Targeting #347

hiptron opened this issue Feb 3, 2022 · 6 comments

Comments

@hiptron
Copy link
Collaborator

hiptron commented Feb 3, 2022

HIP 54: H3Dex-based PoC Targeting

Summary

This HIP serves as both an explanation of the current Proof-of-Coverage (PoC)
targeting behaviour as well as a proposal for a more scalable replacement using
an H3-based index. We are proposing it as a HIP to communicate and acknowledge
that this is a change to the current implementation but we believe it still
falls within the original intent of PoC.

Rendered view

https://github.com/helium/HIP/blob/main/0054-h3dex-targeting.md

@chinsang26
Copy link
Contributor

When will this be implemented? Clodpi devices in India are sending 1 beacon or no beacons in a day as against the 3 beacons a day standard.

@23rdstudios
Copy link

Curious if this is going to solve the issue of hotspots witnessing other hotspot that are to close over and over again. If there is a min distance already implemented why allow hotspots to even talk to those hotspots at all - seems inefficient and wasting time and energy.

@Siegfried-B
Copy link
Contributor

For someone who is not into the subject matter, the example picture is not self-explanatory at all.

What are we seeing here?

To me, this looks just like a part of the hotspot map showing a few hexes occupied with one hotspot and one massively overcrowded hex. That is probably not the intended interpretation.

  • Are we supposed to see how many of these 395 hotspots are active / inactive? I don't see how.
  • Are we supposed to be able to conclude from the picture how often the hex is targeted? And how this is skewed bc of the ratio of inactive hotspots? I don't see how.
  • Is it even supposed to be an example of mis-targeting - or just an example of a hex with a huge number / high ratio of inactive hotspots (which causes mis-targeting)?

So maybe

  • there should be one or two explanatory sentences after "An example of such mis-targeting is here." Like: "We see a hex here that [insert hex properties you want people to know about]".

or

  • the sentence "An example of such mis-targeting is here" should be changed to "An example of a hex with a huge number of inactive hotspots, that causes mis-targeting is here." - if that is what the example is supposed to show. Followed by one sentence on how to conclude from the picture, how many of the hotspots are inactive. Or just telling how many of the 395 hotspots are inactive. (Or: "Here is an example of a hex that causes mis-targeting: x out of the 395 total hotspots are inactive.")

Or is it too late to change the HIP as voting has started - even regarding adding purely explanatory sentences?

@toy1111
Copy link

toy1111 commented Feb 18, 2022

The proposal text isn't describing how a hotspot will be determined "inactive". I think there is a current mechanism that removes the a hotspot after 30days from counting against Transmit Scale. I've seen my hot spot's Transmit scale fluctuate from .65 -> .55 -> .60 -> .51 but the inactive hotspots remain on the map. Changes to deal with this I think are going to be positive if not overdue. Though some details would be helpful regarding "inactive" (as other commenters have also noted).

My hotspot also doesn't beacon anything close to 3 per/day (3 weeks since change its been 1.5/day average). But it may me consider if does their "3 per/day" mean we should average 3 a day or just that at most you'll see 3 per day and doesn't mean that's what you would average?

Either way my interpretation is that both 54 and 55 should help make beaconing more fair and reduce the data load on the network.

@edakturk14
Copy link
Contributor

The HIP has been approved via heliumvote, with 99.34% voting For HIP 54.

On behalf of the DeWi, the HIP Editors, and the wider Helium community, I am marking this proposal as approved and recommending that the coredev team implement the necessary changes as soon as reasonably possible.

@vincenzospaghetti
Copy link
Contributor

This HIP has been deployed and is now closed!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants