-
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 40: Validator Denylist #285
Comments
*Below are talking points I've summarized from Discord discussion... This may only serve as context for discussion at the next Dewi call or further commenters* Intention of HIP
Points seemed to be addressed by current version of HIP
Future Plans
Considerations & Implications
|
Personal Comments/Suggestions:
|
It's been suggested we run a temperature check vote on this to see how the community feels about it conceptually, even if no real code has been written and there's still details to be fleshed out |
Sure, happy to do so, we were told to wait for 31 updates to maybe tie it in with the updates, but I can submit the newer more pinned down version for a vote? would just need a day or so for edits. |
isn't there a gps function in the hardware that can be automatically used to validate the location? That would slow some of the spoofers down wouldn't it? |
no, current hotspots do not contain a GPS in them |
To add historical context to this, some of the first did, but were unused, due to the spoofing. The GPS being insecure is more or less at the heart of the spoofing issue, so oddly enough this point sort of strikes at the very core of PoC. |
Independent on the Mechanism to find and add an HS to a potential deny list, could it be an intermediate step (list) where suspected gaming HS is added to a pendingEvaluationList and the tokens earned goes into an escrow account? Owners of the hotspot have to fulfill certain requirements to prove that its not gaming or set it up so it's not gaming. During this time the hotspot change of ownership would be locked. If the owner proofs not gaming or rectifying the issue, the escrow token will flow back to owner. A new T&C should also be approved by all Helium Wallet user that need to be ack to be able to open the app where users ack no gaming intent and the consequences it they do. |
where is this deny list? how does one suggest candidates? |
This may be a dumb question, but would it be possible to triangulate a hotspot's position based on its interaction with other hotspots? One of the applications for this network is low-power geolocation tracking, replacing GPS. |
Not a dumb question at all. Helium HAS to come up with ways to eliminate, or at least mitigate the obvious 'Gamers' but when the 'Gamers' are as brazen and obvious as the current ones here, it makes a mockery of the whole system. All new systems and ideas get gamed at some stage and eventually evolve with improvements or they die on the vine... let's hope for the former not the latter here. |
This proposal doesn't strike me as particularly practical nor effective. The current denylist sample seems to be empty (at least it was when I tried it just now), although we know there's tons of spoofing. Two other concerns with this: (1) assuming the 14x threshold works, spoofers will find ways to stay just below it. This could be done through slight changes to the spoofed locations, artificial interference / blockage within self-witnessing clusters, automatic scheduled offline time for spoofed hotspots. If the threshold then comes down in response, the next concern hits: (2) great setups get punished in favor of the big mass of really bad ones out there. Instead of incentivizing the types if setups that provide lots of coverage and have the potential to pick up lots of traffic, Helium seems to increasingly hobble itself by introducing changes that primarily benefit the thousands of low-earning, excessively redundant hotspots in large cities, which have no benefit whatsoever to the network. This does not promote effective and smart network growth. It promotes the completely uneven and piled-up coverage we're seeing today. It seems to me, actual data traffic is the way to verify hotspot locations. Say an electric scooter rolls through a city street. All Hotspots that can hear it are obviously in the area. Those that don't, are not. With enough traffic, this should create quite a deep and detailed image of the network. But it won't work with small amounts of traffic (like, the next couple of years) out in remote areas. |
Update going live soon removing the floor. watch this space. |
Well said indeed! |
This was not my idea but I really like it. It was posted on Reddit with many upvotes. "The best way to solve the unsolvable problem of spoofing is to incentivize people to find them in the form of bounties. There are already people who spend hours mapping the network and finding these hackers - imagine if the blockchain rewarded them for doing it. The people should be called Auditors. They need to be a class on the blockchain and should be staked just like validators to create a halo of trust. These auditors could be randomly selected to a suspected hotspot to audit - if they're not transmitting at that location then their wallets should be emptied and transferred to the auditor." Although I would personally rather see the the bounty come from the blockchain as I don't think emptying the wallets would be feasible. |
Interesting idea. But: it opens the door to all kinds of vigilante behavior. How far will people go in order to gain access to a location to audit? What if the spoofed cluster is on a big piece of private property? Also: those auditors would obviously have to have "territories"; doesn't make sense to send one from L.A. to Shanghai. So what's keeping a spoofer from becoming an auditor himself on his home turf as an "insurance policy"? Further: solid criteria would be needed to confirm the HS really isn't there. Sometimes, they're down for days. That doesn't make them illegal. I think we really need to keep real-life people out if this and keep it technical. If someone gets hurt on one of those "missions", it's a liability and PR nightmare waiting to happen. |
One additional comment on all this: I really think the solution needs to focus on what makes a spoofer a spoofer and how to identify it at the root. This proposal is trying to achieve this through the proxy of performance / rewards. This cannot work. As I mentioned before, it will eventually hurt good and legit setups, which Helium needs more of, not less. And the spoofers will just find a way to stay under the rewards radar and let the good guys take the heat. Look at it: lots of the dubious clusters we see in places like China really don't have above-average returns. But they don't care. It's free money for zero effort. |
It's not focused on rewards any more. The major problem with defining gaming is that if you say "this method and these results are how we define gaming", gaming will change. We've moved it away from a reward based focus, and have been working with DEWI to define how a committee does research on gaming (ideals like ML, Data analysis and even boots on the ground). A new PR has been submitted, and a temperature vote will be run shortly to gauge the communities feelings around this hip to get it moving. |
I frequently see posts on the Reddit with links to and discussion around gaming and spoofing situations, HIP/0040-validator-denylist.md Line 49 in 29b78e5
edit: also crossposted here: https://www.reddit.com/r/HeliumNetwork/comments/rkvkmf/hip_40_validator_denylist_for_reddit/ edit 2: I just learned of https://www.suspots.com/ |
You have my support however it is done. With china banning crypto mining, why does helium even support that country? I know it's the people's network but shouldn't we follow the gov laws? The same way why helium has to abide by local laws on transmitter output levels. |
Maybe make it less interesting for gamers, to limit the max amount of 7D Avg beacons til 250. The gamers lives on 7D Avg beacons of 1250 and higher. And a 2nd rule can be - if relayed, than becomes inactive. |
You raise an interesting point. |
I think 250 is way too low. I have a perfectly legit setup with 470 7d avg beacons |
Maybe 500-600 is better, but It's more to start discussing and thinking. Because at the end, gamers are stealing till the money bucket is empty. |
Yep 250 too low I have a legit setup with 400+ beacons and 100+ witnesses. |
My best setup is getting over 800 beacons. It has been both relayed and not. I don't believe relayed status has made much, if any difference. Happy to jump on a call to discuss more. |
Fairly new to all this and apologies if already covered, but won't Relayed/Gaming hotspots generally all be in the same building, therefore the likely reason they are Relayed is because they are sharing the same public IP and can only Port Forward to a single IP address? - couldn't the Public IP be used to spot potential gamers, so maintain a list of IP addresses in use and only a single miner can use each address? |
Why cant there be a certain list of "Clues" and if there are enough clues, that would trigger something to check that a hotspot is spoofed or not? If x number of clues are triggered out of x total possible clues, it will trigger a audit. So therefor, if I don't like my neighbor in my hex, me alone complaining wont trigger anything. But once I check off the boxes that say, "Mapper could not see this hotspot", "Hotspots would only witness other hotspots in this same wallet, but no other hotspots around" "All hotspots in this wallet are spread in perfect hexes" or something similar, then it could trigger the audit. While this wont stop all of them, its a start and would probably stop 50% of them. Part of the appeal process would be the owner submitting pictures of those hotspots located in different locations possibly. |
These are implemented as 'behaviors' on https://www.suspots.com/, FYI. |
Community observations corroborate this, relayed status is not a harsh malus on earnings. @davetapley excellent resource. "Who watches the Watchmen" aka. who will do the auditing? In order to stay true to the idea of decentralized economies, some of the HNT inflation would need to be directed to those auditors who would be humans meaning we would introduce an additional level of complexity into this already complex mess. As a token engineer I am all for doing so - but doing it right. The need to curtail spoofing of all kinds is more pressing than perfectly informed design decisions. Ergo a two-pronged approach makes sense: collect data and based on that data implement first order measures to curtail the problem, then integrate node auditing into the protocol which necesarily includes human intervention and cost. |
Is someone from the technical staff interested in talking to me please? I found my whole wallet on that list without having a clue what might have triggered that. I am willing to share the details of my setups and locations to any extend to deliver proof of legit installs. I am searching contact for nearly 3 weeks now without luck. |
yes pls help
On Monday, January 17, 2022, 12:58:02 AM GMT+1, FuraoEvil ***@***.***> wrote:
Is someone from the technical staff interested in talking to me please? I found my whole wallet on that list without having a clue what might have triggered that. I am willing to share the details of my setups and locations to any extend to deliver proof of legit installs. I am searching contact for nearly 3 weeks now without luck.
No one seems to be interested in my technical details that could avoid false positives and therefor a lot of frustration in the future. I am an system engineer for 20+ years and have in depth knowledge of networking, RF and Linux systems and some basic scripting and coding skills. I think my input could be valuable to this HIP
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
I find stuff like this super troublesome. What precents these from becoming personal vendetta lists for people who don't like others in their hexes? It's like public shaming based on anecdotal observations. Who validates if they're true? Having looked at a few examples, they don't look spoofed and they don't have outrageous earnings. This whole denylist thing really needs to be thought through. |
Would be interested in hearing whether there is a place for something like secure mapper audits or this: dewi-alliance/grants#12 |
我的两台设备更改了位置没有更换钱包,目前因为换位置进入了黑名单。请给与解决,钱包地址143xoZQn6j46RHPKKNirisBrn6kRxdsJazPetjgZ7c9aMhqmDqS |
@sxtysgj you can apply for removal here https://github.com/helium/denylist/issues/new/choose |
This mechanism is very opaque. Although it is reviewed by community members, how many community members are there? They can completely ban any machine using their personal emotions. They also won't admit their mistakes, I only have one machine, this machine is added to denylist, how can I cheat on one machine. ridiculous. |
Is this the so-called people's network and decentralized project? This is completely anthropogenic and helium is a disgrace to blockchain! |
Helium is not supposed to be entirely decentralized. I mean the core devs have full control over the chain variables. What are you suggesting? |
The hot spots on the reject list should not stay in it forever. This will cause many friends who buy second-hand hot spots to be cheated. I think it should be deleted regularly to let the cheater get some punishment. Or is the discovery of cheating hot spot, pull into the rejection list, so that the hot spot to pay a certain penalty from the refusal list deleted. |
Hi @BFGNeil - is this still active? How do you feel about this? Do you want to change any language for validators --> oracles or can we close this HIP? |
we can close it, I believe someone will want to copy this over to oracles further down the line. |
Sounds great. Will remember this as we see oracles play a bigger role. Thanks to everyone for their contributions! |
Info
Rendered view
https://github.com/helium/HIP/blob/master/0040-validator-denylist.md
Summary
While the situation with regards to Proof-of-Coverage gaming has improved and additional enhancements are intended, we need a backstop prevention mechanism that allows us to quickly allow the network to grow and deal with obvious gaming and spoofing situations as they materialize.
This plan proposes that validators would maintain a denylist file of Hotspot addresses which are selected from a basic floor function, selecting the hotspots where earnings are abnormal, and then this is likey followed up with more metrics (see unresolved questions)
This proposal has two consensus mechanisms:
The text was updated successfully, but these errors were encountered: