Skip to content

Instantly share code, notes, and snippets.

@amirhaleem
Created September 27, 2021 19:29
Show Gist options
  • Save amirhaleem/8349f248c0ce26ef78b708dae2e88e40 to your computer and use it in GitHub Desktop.
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.

@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