-
Notifications
You must be signed in to change notification settings - Fork 408
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
Comments
Don't really see the relation with the expected behavior:
|
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. |
Do you have any evidence to support this?
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. 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. |
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. |
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. |
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. |
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. |
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.... |
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 |
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 |
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 |
If HIP 83 would negatively affect your earnings if implemented, that means the beacons you witness necessarily have to have more than 14 witnesses. |
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. |
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. |
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. |
people are complaining about the effects while the status of this HIP is approved and not deployed. |
It's live, been live for a few days now, it went live the day after the hip vote ended. |
@HeliosHyperion1111 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. |
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. |
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. |
A fix has been found!~ |
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. |
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. |
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 |
Where is the fix? |
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. |
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. |
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. |
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. |
@waveform06 What’s completed? All my FF gateways have a constant 7x reduce since this dumb hip was released. There is nothing changed. |
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? |
@Delitants Its completed in the sense that the HIP process is complete. |
I’m seeing a 200% increase today, looks like it’s getting back to normal. Thanks!On Oct 24, 2023, at 2:16 AM, Adrian ***@***.***> wrote:
@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
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>
|
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:
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
The text was updated successfully, but these errors were encountered: