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 83: Restore First to Respond Witness Rewarding #632

Closed
vincenzospaghetti opened this issue May 5, 2023 · 67 comments
Closed

HIP 83: Restore First to Respond Witness Rewarding #632

vincenzospaghetti opened this issue May 5, 2023 · 67 comments
Labels

Comments

@vincenzospaghetti
Copy link
Contributor

vincenzospaghetti commented May 5, 2023

HIP 83: Restore First to Respond Witness Rewarding

Summary

Currently, the Proof-of-Coverage Oracles collect all the witnesses for a beacon and randomly reward a selection of 14 witnesses. This HIP proposes to revert to rewarding the first 14 Hotspots responding to a beacon, incentivizing the most useful Hotspots to sensor traffic by prioritizing the low latency connections that sensors need for uplinks, downlinks, and join requests to work correctly.

Motivation

Rewarding witnesses that are the first to respond will incentivize Hotspots to provide the low-latency connection that the sensors desperately need.

Sensors use uplinks to transfer their data over the Helium network. For a sensor to join the Helium network, it must perform a handshake that requires both an uplink and a downlink. As a power-saving measure, a sensor often has a limited time window to listen for the downlink.

Because the sensor only listens for the downlink for a limited time, the Helium LNS and the Hotspots must minimize latency to ensure the Hotspot can deliver downlinks to sensors within the narrow sensor listening window.

The Helium network originally rewarded the fastest witnesses and moved to a random selection for several technical reasons that no longer apply to the Oracle-based POC architecture introduced as part of HIP 70.

Technical limitations included, but are not limited to:

  • Regular retransmissions on the libp2p network left Hotspot unable to deliver witness reports.
  • Hotspots struggled to sync the Helium blockchain before Validators and needed more time to determine which challenger to deliver a witness to.

Rendered View

https://github.com/helium/HIP/blob/main/0083-restore-first-to-witness.md

Supporting Code

helium/oracles@main...mawdegroot:oracles:mg/first-to-respond-witnessing

@vincenzospaghetti vincenzospaghetti added discussion technical Technical HIPs economic Economic HIP labels May 5, 2023
@disk91
Copy link
Contributor

disk91 commented May 8, 2023

Don't really see the relation with the expected behavior:

  • hotspot connectivity is a consequence, not really a choice
  • hotspot response time to witness is more related to the distance to Oracle than the connectivity type.
  • witness response time is not involved in packet selection
  • router should get best packet, not first packet, router is time constrained on reception, whatever is the hotspot response time
  • Join Accept windows is 5s .... so this Hip about ms is non sense for this.
  • Downlink windows is 2s, tens of Ms don't change anything, wait windows is about 500ms
  • This will make some hotspot not earning due to good but not fast enough connectivity and will conduct these hotspot owner to disconnect miner. The second hand market is already flooded so the only consequence of this will be a reduction of the coverage.
  • High latency HS are usually 4G, most of 4G are well placed hotspot (otherwise you have wifi, Eth...) so this will basically impact some of the best Hotspot in term of coverage

@JoToSystems
Copy link

JoToSystems commented May 20, 2023

Reward Systems in general are implemented to drive the behaviour/expansion of a system in the direction which is in the best interests of that system.
Therefore I would suggest the Reward System in this HIP should be structured to match the best outcome for the Helium network and that would be to maximise the coverage area. To to do this would be to maximise the number of Hotspots and to reduce the overlap (one way to think of this would be to reduce the number of Hotspots per Hex).
With the creation of HIP84, this HIP(83) is now redundant and the Rewards System should be proposed in HIP84 to match the outcomes which are determined in that HIP.

@jsloane
Copy link

jsloane commented May 21, 2023

the low-latency connection that the sensors desperately need.

Do you have any evidence to support this?

Because the sensor only listens for the downlink for a limited time, the Helium LNS and the Hotspots must minimize latency to ensure the Hotspot can deliver downlinks to sensors within the narrow sensor listening window.

Do you have any evidence to show that this is a problem on a wider scale? If high latency hotspots are dropping sensor packets, wouldn't it be better to reduce the PoC window to match the network timeout? That way these hotspots will not be rewarded, according to the network timeout configuration.
Most developed countries have low latency fibre to the premises available in population dense areas, so is this really a problem?

I think this is a bad change that will result in rewards being centralised to those that can configure low latency networks, hardware overclocking, etc. Some manufacturers who cheap out on low spec hardware may lose rewards, when these units are still fit for purpose. The casual users who don't know anything about this will eventually turn their perfectly fine hotspots off, resulting in poorer coverage and a poorer network.

@TXR72
Copy link

TXR72 commented May 22, 2023

This HIP would be a massive step backwards in coverage. It skews rewards towards hotspots with the highest internet speed / lowest latency available - typically urban areas, which are already oversaturated and should experience a disincentive rather than additional incentives.

Conversely, the hotspots doing the most for extending coverage - those further away from urban centres, hex "pioneers", etc. - usually have less fancy internet connections, e.g. 4G. They also typically invested a lot more in their setups. We need those hotspots in particular in order to grow the network in the right places, yet, their rewards would massively suffer.

This is counterproductive and feels like an attempt to concentrate rewards towards a few, super-connected hotspots, with little regard for what that means for the network.

@Blue-S0ul
Copy link

I have this miner in London, UK. The miners is with a 8 DBI antenna. I use this HeliumGeek app which shows what my miner is doing. I think and believe that I am not being treated very well because of this useless random selection. My miner is there and antenna is there. It is there to be used and to provide service which it is doing. My internet is 1GB download and 150 Mb upload. Miner is connected to the modem via cable. When I test the speed, it's 50 upload and 40 download. Latency is 30 and this can change every time I test. I have this app called Helium Geek. It has 3 important icons. Beaconed, Witnessed and Unselected. The Beacon I sent is always being picked up by 14 other hotspots. The Witnessed icon is what is annoying me because here I see it go up to 150 minutes without rewards. The unselected icon, which is in grey is never above 10-15 minutes. This means my hotspot is seeing many many other hotspots but I don't get selected to be rewarded. This is what you guys need to address. People with good hotspots should get good rewards. My antenna is up on 30 m high. It is seeing up to 700 other hotspots but does not get rewarded.

So HIP 83 can and should be good.

@disk91
Copy link
Contributor

disk91 commented Jul 2, 2023

So … basically there is 700 hotspots around you and you would like to be selected more often than the other one … because you are really important and the other are useless if i understand well.
i don’t understand your arguments ? You have a standard setup, a standard ISP connection but you think it is better than the 700 other hotspot around ..
My two cents, with a such density of hostpot, if HIP83 where applied, you will never see a witness anymore …

@Blue-S0ul
Copy link

So … basically there is 700 hotspots around you and you would like to be selected more often than the other one … because you are really important and the other are useless if i understand well. i don’t understand your arguments ? You have a standard setup, a standard ISP connection but you think it is better than the 700 other hotspot around .. My two cents, with a such density of hostpot, if HIP83 where applied, you will never see a witness anymore …

What I am trying to say is that does it mean anything to me to have my antenna there which is spotting so many and is not getting a thing out of it? I also wonder what is going on with all the miners that seem to be red but are around me.

@anyn99
Copy link

anyn99 commented Jul 8, 2023

Basically ALL LoraWAN Applications do not care about latency!

There is a reason for that, it is meant to be low power, not low latency....
Have the authors any idea of LoRa in general? Then they should be aware of the fact that latency is not a problem.

@BFGNeil
Copy link
Contributor

BFGNeil commented Jul 9, 2023

Basically ALL LoraWAN Applications do not care about latency!

There is a reason for that, it is meant to be low power, not low latency.... Have the authors any idea of LoRa in general? Then they should be aware of the fact that latency is not a problem.

Hi, thats not true, remember Join Confirmations, Downlinks and ACK's are an important part. These need to be fast to work.

We also have Class C support now with chirp stack, bidirectional is an important part

@Crash0v3r1de
Copy link

Crash0v3r1de commented Jul 9, 2023

This HIP would be a massive step backwards in coverage. It skews rewards towards hotspots with the highest internet speed / lowest latency available - typically urban areas, which are already oversaturated and should experience a disincentive rather than additional incentives.

Conversely, the hotspots doing the most for extending coverage - those further away from urban centres, hex "pioneers", etc. - usually have less fancy internet connections, e.g. 4G. They also typically invested a lot more in their setups. We need those hotspots in particular in order to grow the network in the right places, yet, their rewards would massively suffer.

This is counterproductive and feels like an attempt to concentrate rewards towards a few, super-connected hotspots, with little regard for what that means for the network.

This is actually a really good point. I'm still getting shafted by not having many hotspots around me purely because I'm in a mountain valley. Now I'll get shafted for not many neighboring hotspots AND slow latency to the collectors.

Glad I diverted my spending money away from this even more after reading this HIP.

@Ryan-Goldstein
Copy link
Contributor

This is actually a really good point. I'm still getting shafted by not having many hotspots around me purely because I'm in a mountain valley. Now I'll get shafted for not many neighboring hotspots AND slow latency to the collectors.

Glad I diverted my spending money away from this even more after reading this HIP.

If the beacons you witness have 14 or fewer witnesses (common in unsaturated, rural areas), then HIP 83 will not affect you at all. If the beacons you witness have more than 14 witnesses, then that's not as unsaturated an area as you may think.

@Crash0v3r1de
Copy link

This is actually a really good point. I'm still getting shafted by not having many hotspots around me purely because I'm in a mountain valley. Now I'll get shafted for not many neighboring hotspots AND slow latency to the collectors.
Glad I diverted my spending money away from this even more after reading this HIP.

If the beacons you witness have 14 or fewer witnesses (common in unsaturated, rural areas), then HIP 83 will not affect you at all. If the beacons you witness have more than 14 witnesses, then that's not as unsaturated an area as you may think.

o cool, I'm still rewarded less regardless

@Ryan-Goldstein
Copy link
Contributor

Ryan-Goldstein commented Jul 9, 2023

o cool, I'm still rewarded less regardless

Ok, so you're in an oversaturated area with more than 14 hotspots providing coverage for a single sensor in that area. It'd benefit the network for some of those hotspots to be redeployed to less saturated areas anyway, to expand total network coverage.

@Crash0v3r1de
Copy link

o cool, I'm still rewarded less regardless

Ok, so you're in an oversaturated area with more than 14 hotspots providing coverage for a single sensor in that area. It'd benefit the network for some of those hotspots to be redeployed to less saturated areas anyway, to expand total network coverage.

I didn't know less than 8 meant more than 14 - thanks for the quick maths

@Ryan-Goldstein
Copy link
Contributor

I didn't know less than 8 meant more than 14 - thanks for the quick maths

If HIP 83 would negatively affect your earnings if implemented, that means the beacons you witness necessarily have to have more than 14 witnesses.

@lthiery
Copy link
Contributor

lthiery commented Jul 12, 2023

I'm a little late to the game here, but was it ever considered starting a cut-off 1 (or 2) seconds after the first receipt?

I think this would mirror the LoRaWAN spec better as the first RX window is 1 second for roundtrip. So anyone that shows up a full second later would be "useless" from a coverage perspective due to latencies.

Currently, this cutoff feels too arbitrary.

@disk91
Copy link
Contributor

disk91 commented Jul 13, 2023

Join request are 5s - 6s windows so basically you currently wait more than a single second for this type of packets ( around 2s) and uplink with no ack (most common type of packets) does not have time constraints. Also 2s wait is a standard windows for reception of a larger amount of packets.

@VeryOuch
Copy link

Seeing this modification in action, it is apparent that good placements are not rewarded any more. In other words, in my area: mediocre placements with low-latency internet are up 2x (taking almost any beacon they can "hear") and near-excellent placements with medium-latency internet are 2x down ("hearing" much more beacons but being selected for almost none, due to the latency). I have very high and rare placements (e.g. 100m and 60m) that used to perform outstandingly but I cannot change the connection latency.

@FieserKiller
Copy link

people are complaining about the effects while the status of this HIP is approved and not deployed.
So is it deployed by now and status tracking is out of date or is it still in the pipeline and when will it arrive?

@BFGNeil
Copy link
Contributor

BFGNeil commented Jul 18, 2023

people are complaining about the effects while the status of this HIP is approved and not deployed.
So is it deployed by now and status tracking is out of date or is it still in the pipeline and when will it arrive?

It's live, been live for a few days now, it went live the day after the hip vote ended.

@waveform06
Copy link
Collaborator

@HeliosHyperion1111
Police don't decide what is to be voted on, I don't decide what will or wont.
I am doing some governance admin though.
We do straw polls of people and we take advice of experts, as I said there is no point sending thru a HIP to vote that the community thinks will fail to pass or is impossible/illegal to implement. If the HIP author cannot persuade a few community members how can they persuade a majority?

HIP 83 moved what people like Sorin (https://www.youtube.com/watch?v=BRO7ziKL7-U) called "Proof of Luck" back to a form of "Proof of Coverage", Disk91's proposal looks to modify that to a mix of both scenarios.

@HeliosHyperion1111
Copy link

yes Sorin did say its proof of luck, but the way the network was back then, had 25 witnesses not 14 and surely didn't implement so strict latency selection of the witnesses like HIP 83 does.
in fact back then it was much more balanced/fair because the witnessing was more focused to the RF signal itself rather the latency.
and we didn't have oracles to tell us who is fast and who is not.

@BFGNeil
Copy link
Contributor

BFGNeil commented Aug 4, 2023

yes Sorin did say its proof of luck, but the way the network was back then, had 25 witnesses not 14 and surely didn't implement so strict latency selection of the witnesses like HIP 83 does.
in fact back then it was much more balanced/fair because the witnessing was more focused to the RF signal itself rather the latency.
and we didn't have oracles to tell us who is fast and who is not.

Sure, when we wrote this hip we knew if we had said return to 25 it would automatically win. we wanted it to go through on merit alone. if 25 is needed, write an amendment now we have clear data.

@RuDee-BG
Copy link

RuDee-BG commented Aug 4, 2023

Coincidence or pure luck...just not fair. My hotspot is the unlucky one, the other one i can see from my balcony ...
Yeah, just bad luck.
IMG_20230804_121415

@mrfizzy99
Copy link
Contributor

A fix has been found!~
All will be right again soon!~
All thanks to @mawdegroot @nosmaster89

@Delitants
Copy link

A fix has been found!~ All will be right again soon!~ All thanks to @mawdegroot @nosmaster89

What's found? Where is it?

@Delitants
Copy link

???

@HeliosHyperion1111
Copy link

A fix has been found!~ All will be right again soon!~ All thanks to @mawdegroot @nosmaster89

What's found? Where is it?

i guess nothing has been found, looks like this guy is biased towards groot who is so against these fair changes.

@mawdegroot
Copy link
Contributor

Several changes to the code have significantly improved the signing speed for the majority of makers. In preliminary testing the majority of makers now show a very similar signing performance. These changes will be included in the new gateway-rs v1.1.0 release which has been released to makers for testing. The new gateway-rs release will also include session keys which will significantly increase data transfer throughput and should free up time on the ECC chip for further improvements in high traffic areas.

@HeliosHyperion1111
Copy link

Several changes to the code have significantly improved the signing speed for the majority of makers. In preliminary testing the majority of makers now show a very similar signing performance. These changes will be included in the new gateway-rs v1.1.0 release which has been released to makers for testing. The new gateway-rs release will also include session keys which will significantly increase data transfer throughput and should free up time on the ECC chip for further improvements in high traffic areas.

great news, so how about we also open up the 14 only selected witnesses to 25? original choices need original choices not half original half w/e we want.

@RuDee-BG
Copy link

From past night something have been changed, my witnesses increased and the nearby miners with 3000-4000 iot per day has been decreased from its original state before hip83.

Something is cooking

@Delitants
Copy link

From past night something have been changed, my witnesses increased and the nearby miners with 3000-4000 iot per day has been decreased from its original state before hip83.

Something is cooking

Nothing has increased at all

@Delitants
Copy link

Where is the fix?

@Firaso123
Copy link

So far no improvement at all at least for the three miners I own.

@HeliosHyperion1111
Copy link

So far no improvement at all at least for the three miners I own.

same, feels like i have to wait for fiber infrastructure for my area to buy one program, all thanks to the number 1 culprit who pushed the hip 83 that was not needed. did more damage to the network than good, usage is dogsht. i look everyday the usage and its nowhere near what those pump n dump flactuations happened before the halving, seems like it was all just cuz of price volatility nothing else.

@Delitants
Copy link

Delitants commented Sep 14, 2023 via email

@HeliosHyperion1111
Copy link

I have fiber and I tell you what, it makes ZERO improvement on this HIP. So forget waiting for it.

do u have the fiber cable connected straight into the hotspot? have you tried that? cuz i think that will fix majority of the latency.
also to add, switch DNS. 1.1.1.1 is by far the lowest latency that gives me.

@Delitants
Copy link

I have fiber and I tell you what, it makes ZERO improvement on this HIP. So forget waiting for it.

do u have the fiber cable connected straight into the hotspot? have you tried that? cuz i think that will fix majority of the latency. also to add, switch DNS. 1.1.1.1 is by far the lowest latency that gives me.

Fiber is connected to my router. You can't stick a fiber in the hotspot directly. Whatever they done here in this HIP is suppresses certain brands of the hotspots, especially those which have 5G function like FreedomFI. This shit must be downvoted or fixed. So far nothing changed

@HeliosHyperion1111
Copy link

I have fiber and I tell you what, it makes ZERO improvement on this HIP. So forget waiting for it.

do u have the fiber cable connected straight into the hotspot? have you tried that? cuz i think that will fix majority of the latency. also to add, switch DNS. 1.1.1.1 is by far the lowest latency that gives me.

Fiber is connected to my router. You can't stick a fiber in the hotspot directly. Whatever they done here in this HIP is suppresses certain brands of the hotspots, especially those which have 5G function like FreedomFI. This shit must be downvoted or fixed. So far nothing changed

there is a way, if you do POE you can basicaly use 2 fiber cables, 1 for electricity and 1 for internet, converted into a POE with a male into female (ethernet) adaptor or w/e its called u know what i mean

@Delitants
Copy link

I have fiber and I tell you what, it makes ZERO improvement on this HIP. So forget waiting for it.

do u have the fiber cable connected straight into the hotspot? have you tried that? cuz i think that will fix majority of the latency. also to add, switch DNS. 1.1.1.1 is by far the lowest latency that gives me.

Fiber is connected to my router. You can't stick a fiber in the hotspot directly. Whatever they done here in this HIP is suppresses certain brands of the hotspots, especially those which have 5G function like FreedomFI. This shit must be downvoted or fixed. So far nothing changed

there is a way, if you do POE you can basicaly use 2 fiber cables, 1 for electricity and 1 for internet, converted into a POE with a male into female (ethernet) adaptor or w/e its called u know what i mean

You don't make any sense. PoE has nothing to do with fiber. And fiber at home is usually PON, which is locked to provider's ONT. You can't just plug it in wherever you want.

@HeliosHyperion1111
Copy link

@HeliosHyperion1111 @RuDee-BG @Delitants Have you taken a look at https://github.com/helium/HIP/blob/main/0094-response-time-windows-for-witness-rewarding.md https://discord.com/channels/404106811252408320/1144746781071130795

yeah i wait for this HIP to be released, but for the time being we all try to find a way to reduce our latency, most people don't find any other way other than upgrading to fiber network with fiber lines connected straight to our hotspots, most think you need the antenna as high as possible, well mine is at the highest point in the outskirts of the capital( omni directional ) in case some think that i have a directional ''stealing'' all the rewards. this HIP 83 has impacted my hotspot significantly cuz i provide very good coverage, i connect the capital city, with islands on the south + 1 small port city behind me and 1 small sub urban town on the north, and guess what? i got punished for it! haha thanks to HIP 83.

@Delitants
Copy link

@waveform06 What’s completed? All my FF gateways have a constant 7x reduce since this dumb hip was released. There is nothing changed.

@madninja
Copy link
Member

madninja commented Oct 23, 2023

@waveform06 What’s completed? All my FF gateways have a constant 7x reduce since this dumb hip was released. There is nothing changed.

  1. poc ingest streams will go live shortly which will help with security chip performance across all hotspots, including the FF hotspots because of the use of session keys
  2. a FF update will include this gateway-rs upgrade as well as a faster security chip (TPM) interface

And finally, this HIP was accepted and implemented in the reward system. The fact that one or more makers did not upgrade quickly is not a problem for the HIP, it's a problem with the maker.

If you still generally don't like the the concept of first to witness, propose a new alternate approach in a HIP or back one of the existing ones?

@waveform06
Copy link
Collaborator

@Delitants Its completed in the sense that the HIP process is complete.
Its now down to the hotspot vendors to improve their products response times and the core-devs to make any improvements to the system to provide an even playing field where possible for all vendors.
#764 is an alternative that is being evaluated

@Delitants
Copy link

Delitants commented Oct 28, 2023 via email

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

No branches or pull requests