Skip to content

Instantly share code, notes, and snippets.

@amirhaleem
Created September 27, 2021 19:29
  • Star 2 You must be signed in to star a gist
  • Fork 1 You must be signed in to fork a gist
Star You must be signed in to star a gist
Save amirhaleem/8349f248c0ce26ef78b708dae2e88e40 to your computer and use it in GitHub Desktop.

Validator Denylist

  • Author(s): ????
  • Start Date: 2021-09-27
  • State: Proposed
  • Original HIP PR: ????
  • Tracking Issue:

Summary and Motivation

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 the community-at-large have determined are "gaming" the PoC system and not providing coverage where they claim to be.

This proposal has two consensus mechanisms:

  1. how Hotspots are added or removed from the denylist
  2. whether validators choose to adopt the community blacklist

Semi-Detailed Implementation Plan

  • A public JSON or YAML file of denylisted Hotspot unique addresses will be included in the validator software

  • Community members will be able to submit pull requests against this file to add/remove addresses from the list with some explanation for the request

  • When PoC transactions are submitted to the consensus group, if a majority of consensus group members agree that a given Hotspot address is on the denylist, any witness receipts from that address will be marked as invalid with a reason of denylist

  • Only witness receipts are affected by the denylist. Hotspots on the denylist can still transmit and be witnessed by others, and be rewarded for that activity. This also allows Hotspots to justify being removed from the denylist in the future

  • Validators do not have to use the community denylist file, or any denylist at all. Only if a majority of consensus group members both have a denylist and have common Hotspots on the denylist would any action be taken. This puts consensus decision making in the hands of a) the entity that approves/denies pull requests to the community denylist, and b) validators who choose whether to adopt the denylist

Open Questions

  • Who decides which denylist PR's to accept or reject?

  • Should a majority of validators be required to denylist a witness receipt, or should it be unanimous?

  • Should Hotspots on the denylist still get transmission (aka. challengee) rewards?

Success Metrics

Success here means that a Hotspot address contained on a majority of validators' denylist have their PoC witness receipts rejected as invalid.

@anthonyra
Copy link

Some thoughts on maybe an on chain version, just brainstorming.. not sure which would be better

Make it transaction based, where it would require the same amount of HNT that's been earned in the last 7 days to submit. Upon investigation the hotspot witness rewards aren't rewarded. If the accused can prove they're legit. Then the rewards during the investigation can be released and the reporter gets their HNT back and the hotspot continues. If the accused can't prove that they're legit the reporter gets their HNT back and the HNT accrued during the investigation and the hotspot remains data-only while on that account.

@waveform06
Copy link

Expanding the last open question and assuming it gets Data and Challengee rewards and who knows about Challenger
If the denylist only prevents Witness Earnings...
Q1 Is it still an "interactive" hotspot for PoC HIP17 calcs?
Q2 If it is one of the possible 10 PoC Witnesses will it count for the Challengee earnings?
Q3 If it is one of10 PoC Witnesses will no 11 now get witness earnings?

@ke6jjj
Copy link

ke6jjj commented Sep 27, 2021

For easier operational deployment, I suggest that instead of YAML, each proposed list is distributed via DNS, like the Real-time Black Hole Lists that are used to control e-mail SPAM.

Under this system each validator would choose to "subscribe" to particular ban list, in which case they would simply program their validator to query a structured domain name, rooted at a DNS zone published by the list maintainer, to determine whether a given hotspot is or isn't a member of the list.

Records published this way can have automatic expiration times, allowing the list maintainer to tune their settings, and to help ensure that ongoing research is taken to remove hotspots from the list should they be found to come back into compliance. With the addition of DNSSEC, validators can be assured that these records really are published by the publisher and not spoofed by some other entity.

@Leon-THL
Copy link

Views and points for input and up for debate and consideration: In my personal capacity I would like to support this denylist.

  • When a hotspot has been added the owner should have a very specific route to query or give information to a specific forumn - almost like a report line / discord private channel. If for some reason my hotspot is listed I need an easy route to ask questions and state my case.
  • Consider a forumn where information can be privately submitted, almost like a reporting area that would be anonymous publicaly but still have a link back to a wallet / person to disuade it being used for the wrong reasons
  • Once a hotspot is listed it probably will have the effect that the owner opens up their system (if hidden in any way) so a diagnostic can be run from the Helium network. That diagnostic analysis should then be analysed and verified by those validators that voted for the ban and needs to be done quickly

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