[Phase 3] HIP 55: Explicit Sybil Resistance

HIP: 55
title: Explicit Sybil Resistance
author: @greenlucid
status: Phase 3
created: 2022-07-18
conflicts with: None
languages: EN

Simple Summary

Make the registration policy reject sybils explicitly.

Abstract

Make the Acceptance Criteria be explicit about puppeteers not being allowed. Allow challenging puppeteered submissions as Duplicate. A puppeteer is an actor that controls human accounts whose human does not represent themself.

Motivation

In its current state, the Policy states the registry is sybil resistant, which is a desirable trait. But the Acceptance Criteria was not explicit about this. This has resulted in some different strategies to creating sybils, like farming, or helping family members to get in while controlling their keys.

The point of this clause is to explicitly make the case in the rules, of something that was already implicit in the spirit of the registry.

Implementation

Merge this PR to the HIP-45 compliant repo. Changes are also stated here, for completion, but in the case of conflict, the implementation to follow is the one in the PR.

  1. Define puppeteer as

actor that has direct control over registered human accounts that don’t represent them.

and be explicit about 100% proof not needed.

  1. Add non-puppeteer as Acceptance Criteria.
  2. Add examples of puppeteers.
  3. Add puppeteering as a Duplicate worthy challenge.

Make it clear that the burden of proof is on the challenger.


Specifically, this is translated to the two following changes in the policy.

Add new not-puppeteer condition to Acceptance Criteria

  • The submitter is not a puppeteer, and will not become a sybil after successful registration. A puppeteer is defined as an actor that has direct control over registered human accounts that don’t represent them. Since this is very hard to prove, it is enough to invoke this criteria if it is extremely likely for the submitter to be a puppeteer. To invoke this reason, the burden of proof resides in the challenging side, in case a registration is disputed, or in the remover side, in case a profile is being removed. This side must provide an explanation for why, within reason, the submitter is a puppeteer. Given inconclusive evidence, jurors must rule in favor of including the submission.
  • For example, a human cannot be registered if the submitter is not the same person as them.
  • For example, a human cannot be registered if their submitter is a farmer, an actor that submits multiple humans.
  • For example, a human child cannot be registered if their parent (who technically is the submitter) is controlling their private key.

Modify Duplicate challenge condition to allow for targetting puppeteers

  • Duplicate: The submitter is already registered in the list, or the submitter is a puppeteer.
  • If the submitter is already registered, the challenger has to point to the identity already registered or to a duplicate submission. If someone tries to register multiple times simultaneously, all submissions are to be rejected.
  • If the submitter is a puppeteer, the challenging side has to prove within reason that the submitter is a puppeteer. The burden of proof resides on the challenging side, who must explain why, within a reasonable interpretation, the chances of the submitter being a puppeteer are extremely high. Dubious motives weigh in favor of including the profile.

Rationale

It’s not possible to prove that someone is a sybil at its core, since that would imply proving they are holding other accounts’ private keys or whatever equivalent. So, an explanation with reasonable, extremely-high likely arguments for someone being a sybil, should be enough. The most important characteristic of the registry is sybil resistance, not inclusion.

It would also be desirable to treat a sybil submission challenge as a Duplicate, because then, whoever vouched for them gets removed as well (who, is certainly malicious, unawarely or knowingly so).

Purposely, exceptions are not added. This is because, when there are exceptions in play, items that do not match the exception obtain extra legitimacy in favor of the challenger. The challenger is expected to provide the full, lengthy explanation of why the submitter is a puppeteer. The burden of evidence rests on them.

Some complaints were made on why a standard of evidence wasn’t disclosed in the proposal. This is because:

  • such a standard would be general to the policy, not this clause specifically. It is outside the reach of the proposal.
  • adding this standard can result in challenges that follow the standard to have overwhelming strength compared to the submitter. This is similar to how adding exceptions to give breathing room to submissions, makes the non-exceptions stronger challenge reasons in the eyes of the jurors.
  • the jurors already follow a standard of evidence. Jurors don’t accept baseless claims.

I think there are some things that are not clear in this proposal:

  1. How do we deal with current ‘good-faith’ sybils, i.e. people who have registered dependents (children or elderly)? Are they immediately up for a challenge or will they only be possible to challenge after renewal (the latter would be my suggestion)?
  2. I think it is better to put the sybil definition in the acceptance criteria in the proposal and let this be authoritative. Otherwise, it puts a barrier to figuring out what the content of the proposal is. The link can then simply be a suggested implementation.
  3. As a smaller point I find the phrase: “Given the subjectivity, jurors must weigh doubts and unclear points in favor of including the submission.” a little awkward. Suggest a change to “Given inconclusive evidence, jurors must rule in favor of including the submission.”

How do we deal with current ‘good-faith’ sybils

That’s an interesting point, I just remembered your point on not making this retroactive. So, there’s an issue at hand here. If we cannot remove known sybils that registered before X date, then we are effectively telling integrations to discard profiles submitted before the No Sybil Epoch. Which will make all profiles submitted before the epoch less trustworthy.
Plus, those known sybils would still get to vote in proposals. Getting UBI is fine, though.

So:

  • either you remove them. Sybils can withdraw the UBI they’ve been accruing. The human behind the submission can register properly from a new address.
  • either you let them in, but then there are ~16k humans that registered before the epoch, and projects cannot really use them for sybil resistance.

Please give your thoughts. I’m in favor of being retroactive but retroactivity is usually bad so we should discuss this.

sybil definition

What do you mean? The clauses no longer talk about sybils, but puppeteers (as per Alan suggestion)

phrase

Sure, will change.

I think it is best to apply this criterion only to new sign-ups and on renewal. A profile can be “tagged” as “Independant” or untagged. Until all profiles are renewed integrators can choose how to deal with untagged profiles. It gives me a bad feeling if we throw kids out when their parents didn’t actually break any rules. This will also create consistency with @herniadlf proposal to deal with explicitly dependent profiles. [Phase 1] HIP-XX - Explicit account management

My point was that the authoritative text should be present in the HIP itself - not through a link (it even takes a few clicks to get to the actual text). It was not a comment on the text itself.

After giving this deep thought, I will send it to Phase 3 as it is, retroactively. Otherwise, 16k profiles become lost in this untagged state. PoH itself is the registry that holds the tagged profiles.

It’s not a big issue for current, sybil profiles. Most of them don’t even have any evidence for being removed. Those who do, can re-register properly with a key really controlled by the human. They will be registering with a deposit which is way lower as well, so there’s no friction there.

the authoritative text should be present in the HIP itself

Ok, that’s fair, I’ll get it into the HIP text.

The link can then simply be a suggested implementation

Note that this is not possible, as per HIP-45, changes to the policy are all about PRs now.

But, I can add the authoritative text in the HIP text as well

This proposal is put to a vote.