- Author(s): ????
- Start Date: 2021-09-27
- State: Proposed
- Original HIP PR: ????
- Tracking Issue:
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:
- how Hotspots are added or removed from the denylist
- whether validators choose to adopt the community blacklist
-
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
-
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 here means that a Hotspot address contained on a majority of validators' denylist have their PoC witness receipts rejected as invalid.
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.