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 40: Validator Denylist #285

Closed
jamiew opened this issue Sep 29, 2021 · 43 comments
Closed

HIP 40: Validator Denylist #285

jamiew opened this issue Sep 29, 2021 · 43 comments

Comments

@jamiew
Copy link
Contributor

jamiew commented Sep 29, 2021

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:

  1. how Hotspots are added or removed from the denylist
  2. whether validators choose to adopt the community denylist
@EdBallou
Copy link
Contributor

EdBallou commented Sep 29, 2021

*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

  • Preferring to only target blatant gaming over forging a path for long-term research into improving/strengthening PoC reward algorithm

Points seemed to be addressed by current version of HIP

  • validators unanimous or majority? It has to be unanimous, per evan -

"recall that our consensus mechanism hides txns from other consensus members so if we want to do denylist filtering, everyone has to agree"

  • Define process for getting on the list and off the list
  • Examples? Either current or historical
    • Could there be a list of miners to start review from always (eg. X% above the average miner earnings automates a review)? Or other criteria?
  • Who does the review? (Dewi, "elected" community members, Helium, reps from everyone?, rotating committee?, manufacturers)
    • Governance? Should it be on chain? "A voting system can be abused, however, a committee system can be overwhelmed."
    • How do you reduce the noise of excess of submissions to subvert the denylist process?

Future Plans

  • What, if any methods could be used for verification? Mapping? Disco mode? Pings/Tracerts? Could there be a standard script/report for initial inquiry/investigation on a hotspot to add to the denylist?
  • Do we establish a Dewi grant to have a bounty to reward for reported exploits? Or offer a buyback program where the offending hotspot owner can pay back in exchange for information on the exploit to get the miner restored?

Considerations & Implications

  • What if a particular miner was being targeted or was compromised?
  • What if the miner was used by a fleet?
  • How can you respect the anonymity of reporters/"exploiters"/governing body to decrease likelihood of retribution?
  • setting an automatic threshold for gaming identification sets a boundary where gamers/exploiters could fly under the radar...and at scale
  • if rewards are held for any reason, or reappropriated, where do they go to? Burned? Validators/staking rewards? PoC rewards?

@EdBallou
Copy link
Contributor

EdBallou commented Sep 29, 2021

Personal Comments/Suggestions:

  1. Coverage should be defined as RF coverage (uplink and downlink required per Lora)
  2. Define the notice period and how the notice will propagate
  3. Offer option (perhaps in 51% to 66.6% range) where validators can choose to fund denied hotspots via their consensus earnings (or just allow validators to not use the deny list and people continue to stake with them or move elsewhere) - can't be done per how consensus works. See evan's quoted comment in my post above.

@jamiew
Copy link
Contributor Author

jamiew commented Oct 25, 2021

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

@BFGNeil
Copy link
Contributor

BFGNeil commented Oct 25, 2021

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.

@OzJockey
Copy link

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?

@BFGNeil
Copy link
Contributor

BFGNeil commented Nov 11, 2021

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

@cvolkernick
Copy link
Contributor

cvolkernick commented Nov 11, 2021

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.

@anders462
Copy link

anders462 commented Nov 12, 2021

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.

@OzJockey
Copy link

where is this deny list? how does one suggest candidates?

@ZeeCpt
Copy link

ZeeCpt commented Nov 14, 2021

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.

@OzJockey
Copy link

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.

@TXR72
Copy link

TXR72 commented Dec 14, 2021

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.

@BFGNeil
Copy link
Contributor

BFGNeil commented Dec 14, 2021

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.

@OzJockey
Copy link

Well said indeed!

@flyoffacliff
Copy link

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.

@TXR72
Copy link

TXR72 commented Dec 15, 2021

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.

@TXR72
Copy link

TXR72 commented Dec 15, 2021

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.

@BFGNeil
Copy link
Contributor

BFGNeil commented Dec 15, 2021

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.

jamiew pushed a commit that referenced this issue Dec 17, 2021
@davetapley
Copy link

davetapley commented Dec 20, 2021

I frequently see posts on the Reddit with links to and discussion around gaming and spoofing situations,
and you don't have to squint too hard to realize this is:

- Additional lists can be created by the community and validators can choose to opt-in to additional lists.

Reddit is obviously a terrible place to keep track of this, so I'd like to propose setting up somewhere else, and I wonder if GitHub issues (or 'discussions') would be a good place?

I could create a repo for this myself (in 'the community' spirit),
but would an admin of the Helium GitHub org be open to creating a repo for this purpose?


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/

@Ravenitt
Copy link

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.

@JForce01
Copy link

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.

@GP-Colorado
Copy link

You raise an interesting point.
I wonder though whether, if earning of cryptocurrency rewards is disallowed for hotspot within jurisdictions where it is unlawful to mine, we'll simply see a major migration to the Sahara Desert or Antarctica.

@flyoffacliff
Copy link

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.

I think 250 is way too low. I have a perfectly legit setup with 470 7d avg beacons

@JForce01
Copy link

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.

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.

@Ravenitt
Copy link

Yep 250 too low I have a legit setup with 400+ beacons and 100+ witnesses.
Let's do something about people who are relayed as this is a big part of spoofing. And will force people who are too lazy to sort it out.

@EdBallou
Copy link
Contributor

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.

@GreggersUK
Copy link

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?

@KG5FQT
Copy link

KG5FQT commented Jan 12, 2022

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.

@davetapley
Copy link

@KG5FQT

Why cant there be a certain list of "Clues"

These are implemented as 'behaviors' on https://www.suspots.com/, FYI.

@le-dawg
Copy link

le-dawg commented Jan 14, 2022

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.

Community observations corroborate this, relayed status is not a harsh malus on earnings.

@davetapley excellent resource.

@KG5FQT

"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.

@FuraoEvil
Copy link

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

@deemibelgium
Copy link

deemibelgium commented Jan 17, 2022 via email

@TXR72
Copy link

TXR72 commented Jan 17, 2022

edit 2: I just learned of https://www.suspots.com/

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.

@cvolkernick
Copy link
Contributor

cvolkernick commented Jan 17, 2022

edit 2: I just learned of https://www.suspots.com/

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

@sxtysgj
Copy link

sxtysgj commented Feb 6, 2022

我的两台设备更改了位置没有更换钱包,目前因为换位置进入了黑名单。请给与解决,钱包地址143xoZQn6j46RHPKKNirisBrn6kRxdsJazPetjgZ7c9aMhqmDqS

@benengele
Copy link

@sxtysgj you can apply for removal here https://github.com/helium/denylist/issues/new/choose

@AnnKingdd
Copy link

AnnKingdd commented Feb 16, 2022

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.

@Jackson5675
Copy link

Is this the so-called people's network and decentralized project? This is completely anthropogenic and helium is a disgrace to blockchain!

@BenJewell
Copy link

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?

@Davis712
Copy link

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.

@vincenzospaghetti
Copy link
Contributor

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?

@BFGNeil
Copy link
Contributor

BFGNeil commented Oct 6, 2022

we can close it, I believe someone will want to copy this over to oracles further down the line.

@vincenzospaghetti
Copy link
Contributor

Sounds great. Will remember this as we see oracles play a bigger role. Thanks to everyone for their contributions!

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

No branches or pull requests