HIP 83: Restore First to Respond Witness Rewarding

[vincenzospaghetti]

HIP 83: Restore First to Respond Witness Rewarding

• Author(s): @BFGNeil, @mawdegroot
• Start Date: 2023-05-05
• Category: Economic, Technical
• Original HIP PR: Restore First to Witness HIP #605
• Tracking Issue: HIP 83: Restore First to Respond Witness Rewarding #632
• Voting Requirements: veIOT Holders

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

[disk91]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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