HIP 94: Response Time Windows for Witness Rewarding

[hiptron]

HIP 94: Response Time Windows for Witness Rewarding

• Author(s): @disk91, @jmarcelino
• Start Date: 2023-07-20
• Category: Economic, Technical
• Original HIP PR: #749
• Tracking issue: #764
• Voting Requirements: veIOT Holders

Summary

Currently the Proof-of-Coverage Oracles reward the 14 first hotspots (defined in default_max_witnesses_per_poc ) reporting a witness. This rewards the fastest hotspots, incentivizing fiber backhauls and specific hardware models that happen to be able to produce fast signatures. The result is that the same hotspots are selected, making others unviable even if they provide unique and useful coverage for the network. In other words, it punishes hotspots for falling short of millisecond optimizations when the LoRaWAN protocol functions to the order of seconds - see also. A hotspot’s utility in providing LoRaWAN coverage is based on measuring “good enough” response times, not absolute fastest as absolute speeds provides no marginal utility, the Uplink does not have a particular time-window, the downlink time windows is up to 2 seconds, and the Join process up to 6 seconds.

Since HIP-83, changing the way hotspot are selected, we see an acceleration of hotspots not participating to PoC anymore conducting to network size reduction.

This HIP proposes to evolve the hotspot selection by adding a response time window to eliminate only slow hotspots that fail to meet LoRaWAN-grade timing constraints and push helium hotspots to improve their reponse time, over time, reasonably.

Rendered View

https://github.com/helium/HIP/blob/main/0094-response-time-windows-for-witness-rewarding.md

[BFGNeil]

assuming hip83 is the only reason rewarded hotspots are reducing faster is not correct. the halving also plays a role.

drawing the authors eyes to the big drop in earnings, no reason for a reduction in rewarded hotspots right?

We've also seen with optimisations that earnings have improved, and much needed changes to data transfer to move to a session key base system which are all positive outcomes of Hip83. here I see very little benefit whilst also giving packet stuffers more chance at being rewarded.

Which one are we also voting on, the one listed or the alternative? how does someone vote for the alternative listed? better to focus it on one of the two.

[disk91]

assuming hip83 is the only reason rewarded hotspots are reducing faster is not correct. the halving also plays a role.

drawing the authors eyes to the big drop in earnings, no reason for a reduction in rewarded hotspots right?

We've also seen with optimisations that earnings have improved, and much needed changes to data transfer to move to a session key base system which are all positive outcomes of Hip83. here I see very little benefit whilst also giving packet stuffers more chance at being rewarded.

Which one are we also voting on, the one listed or the alternative? how does someone vote for the alternative listed? better to focus it on one of the two.

Nice to see you back on helium community Neil ;) @BFGNeil you don't need to defend HIP-83, this HIP is not against HIP-83, like any HIP it's a proposal to make what exists working better to develop the network. So it's better to propose solution to ameliorate this proposal.

The HIP dos not assume HIP-83 is the only reason of hotspot fleet decrease, it shows that there is an acceleration starting after HIP-83 and does not includes data after halving. Even if the HIP83 is not causing any decrease, all the data clearly show that it did not slow done the decrease. Halving played a role also and the combination of the two is having a big impact on the network. None of the metric shared in the HIP includes halving period to not mix the impacts in the analysis.

One of the purpose of HIP-83 you told me (and has also been repeated in discord today) was "to reduce number of hotspots in dense area" - even if this is not written in the HIP - if you maintain this objective, to be honest I don't see how this can be achieved without reducing the number of hotspots. So it important to take a position, do you want HIP-83 to reduce the number of hotspot and in this case the figure shows in this HIP make it a success, or you want HIP-83 to help maintaining a strong & large network and in this case it seems to be a failure.

The graph with the number of rewarded hotspot within a day does not show the disconnected devices, this metric is important and it is linked in the HIP but it does not prove that we are in a good situation, it just show a continuous decrease.

I prefer also to look at hotspot disconnection (the one you never see again) to understand when things impacts and what is the real situation, the reward distribution is hiding a big part of the problem in particular all the hotspot that don"t get rewards because the coverage around have been removed.

Session key is a good thing, HIP83 helped to accelerated the discovery of it for sure, this will not be impacted by this HIP proposal. Basically with the session key deployment, all the purpose of the HIP-83 is becoming not applicable as the response time for witnessing will become totally uncorrelated with the data response time. (Session key optimization does not impact the current witness performance. It only impacts data transfer)

As a consequence, session key improvement conducts to the need for this HIP. We need to consider through the witness time the ability for a hotspot to transfer the data in a correct timing in regard of the LoRaWan network timing constraints, in regard of the different parameter of variability we can have between hotspots. ECC calculation is one of these variation impacting the PoC process but not impacting the data transfer anymore.

[disk91]

Feedback from the community to add in the HIP (as a reminder)

• the time windows extension for low density area is fixed at 14 hotspots in the 1st proposal and 5 in the second (coherence)

[disk91]

Feedback from the community to add in the HIP (as a reminder)

• The witness from the beaconner itself must be ignored as it can be a way of gaming the timing windows

[mawdegroot]

Feedback from the community to add in the HIP (as a reminder)

• The witness from the beaconner itself must be ignored as it can be a way of gaming the timing windows

What does this mean? A Hotspot can't witness itself.

[waveform06]

What does this mean? A Hotspot can't witness itself.

Well they do, but its ignored for rewards, so I guess that this is for clarity of how many are counted in the timing windows.

[disk91]

Feedback from the community to add in the HIP (as a reminder)

• option to scenario with an incentive for some of the fastest hotspot

[disk91]

What does this mean? A Hotspot can't witness itself.

Well they do, but its ignored for rewards, so I guess that this is for clarity of how many are counted in the timing windows.

exactly

[disk91]

Feedback from the community to add in the HIP (as a reminder)

• Freedom Fi ECC is 400ms

[disk91]

Feedback from the community to add in the HIP (as a reminder)

• Get and add detail on the exact HPR data integration windows

Personal point of view, that may be a really good reason to not give reward to slow hotspot that could impact the uplink data quality & communication costs

[madninja]

Feedback from the community to add in the HIP (as a reminder)

• Freedom Fi ECC is 400ms

upside of the hip83 exercise is that we did end up finding that the standard OEM driver was very slow and some optimizations are available to get it within the same ballpark as the ecc signing speed.

[HeliosHyperion1111]

assuming hip83 is the only reason rewarded hotspots are reducing faster is not correct. the halving also plays a role.

drawing the authors eyes to the big drop in earnings, no reason for a reduction in rewarded hotspots right?

We've also seen with optimisations that earnings have improved, and much needed changes to data transfer to move to a session key base system which are all positive outcomes of Hip83. here I see very little benefit whilst also giving packet stuffers more chance at being rewarded.

Which one are we also voting on, the one listed or the alternative? how does someone vote for the alternative listed? better to focus it on one of the two.

oh there you are, you installed a trojan horse into Helium network with your scammy Hip 83, and you did so just before the halving, but hey you made sure to mask it so to blame ''halving'' is what reduced earnings, yeah second time you aren't fooling anyone here buddy, we see exacly what your HIP 83 has done, -35k hotspots as i have projected when i said if this scammy hip 83 passes, this will be the result, and all we got is few lazy hotspots with no unique coverage earning everything. GET the f out of here. didn't you leave cuz someone turned you down? get the F out of here.

[disk91]

Feedback from the community to add in the HIP (as a reminder)

• Freedom Fi ECC is 400ms

upside of the hip83 exercise is that we did end up finding that the standard OEM driver was very slow and some optimizations are available to get it within the same ballpark as the ecc signing speed.

do we have some measurement update we could add in the HIP for the different brands ? and a refresh of the reward distribution per brand ? It would be great to use the last / updated data in the HIP

[waveform06]

HIP 94 will be closed in 2 weeks unless the HIP is updated without multiple options and includes the supporting data.

[Vagabond]

Personally I'm in agreement that we should not penalize hardware that is slightly slower so much, as long as it leaves plenty of time for the lorawan timing requirements.

I think the only comment I might make is to make it a weighted selection from the qualifying witnesses. We should strive for the fastest response times both from a QoS perspective but also from a anti-gaming perspective.

[abhay]

Any thoughts on adding weighting @disk91 ?

[BFGNeil]

example 3 needs updating:

Example 3 25 witnesses received:

10 within MAX_WITNESS_WAIT_WINDOWS_MS 200ms 8 within EXTENDED_WITNESS_WAIT_WINDOWS_MS 200-500ms 7 outside EXTENDED_WITNESS_WAIT_WINDOWS_MS 500ms The first 10 are marked as SELECTED, the next 8 are marked as VALID, the 7 others are marked as INVALID.

Oracle will reward all the SELECTED, then will randomly choose 6 (14-8) of the 8 witnesses marked as VALID and reward them. Assuming default_max_witnesses_per_poc is 14

should be 4 more chosen from valid for a max of 14, 10 were in the max wait.

[stmax82]

I am opposed to implementing a weighted selection process that favors the quickest response times. HIP 83 aimed to decrease the concentration of hotspots in dense areas. I believe that all participants providing coverage within a specific time window (like 200 ms), should be rewarded equally, regardless of their equipment (hotspot, internet,...).

I run a hotspot located 10 km away from the next one. I guess that's a low-density area where you want more hotspots? Yet this is the consistent feedback my hotspot receives:

Valid, Not Selected, Arrival Rank: 56 of 73, Late: 84 ms (Fastest hotspot: -10 ms)

I earn 0 for witnessing.

The issue is that my hotspot can only connect with other hotspots in a city (dense area) about 20 km away.

Using a weighted selection that rewards those with quicker response times will only perpetuate the advantage for hotspots in such dense areas, since there'll always be many that respond faster than mine (while providing no useful coverage). Consequently, my hotspot, which provides important coverage in a low-density area, will continue to go unrewarded, like it did since HIP 83.