[Phase 1] HIP-55: Explicit Sybil Resistance

HIP: 55
title: Explicit Sybil Resistance
author: @greenlucid
status: Phase 1
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 sybils not being allowed. Allow challenging sybil submissions as Duplicate. A sybil 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.

Implementation

Merge this PR to the HIP-45 compliant repo. Changes are also stated here, for completion: (but, the authoritative wording is in the PR)

  1. Define sybil 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-sybil as Acceptance Criteria.
  2. Add examples of sybils.
  3. Add sybil as Duplicate worthy challenge.

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 that indicates high changes of 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).

4 Likes

Hi Verde. How would you deal with cases where someone is Challenged, does not hear about it and is deleted because of reasonable doubt?

They should have been aware then. That’s an UX issue, not contract or policy related. The solution is to build a comprehensive notification system

1 Like

Agree. Then we should build it before passing to a next step.

1 Like

There are notifications built already. This is easy to do.
Also, being aware of this is already a requirement. You can remove a profile that is deceased, and the burden of proving you’re not deceased is in the human account. So there is no need to delay this.

1 Like

Hey @green , I think that this is necessary but from my point of view is better to close a definition in here first Acceptable management of family member’s PoH account . Your proposal is very restrictive for family members.

The most important characteristic of the registry is sybil resistance, not inclusion.

I think that it’s a very importante characteristic, yes. But It also crashes with UBI social use case, one of the largest now, am I right? So it’s not easy to ignore it.

1 Like

Although the HIP is deffinitelly interesting to apply, It requires a lot of discussiong and formalization of other topics.

  • Notifications are implemented using EPNS, but that still has a UX barrier, so even with the solution implemented, there still needs some work around it
  • As @herniadlf said, we need to debate the Acceptable management of famili members. This doesnt mean allowing sybils, but discussing a framework thaty allows people to help family members limited to the use of POH, but also avoiding sybil attacks. We owe ourselves that discussions first, to see if its even possible.

After all those toipics are clear, I believe we could move foprward with this HIP considering the result of those previous discussions

1 Like

I disagree with the proposal as is. However, with building spirit, I’ll make some suggestions, consequence of some thoughts already posted in here.

(1)
I would prefer to define the sybil in terms of his malicious intent or his personal gains. In that case, change this:

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

For this:

actor in search of personal gain by controlling registered human accounts that do not represent them

(2)
I would explicitly add somewhere that “It is not allowed to control the keys of any other human. Any suspicion of it is cause for challenge/removal, for which you must present irrefutable evidence that it is an exceptional situation.”

(3)
I would remove the human child example:

For example, a human child cannot be registered if their parent (who, technically is the submitter) is controlling their private key.


In any case, as you mentioned, it is very difficult to prove this situation. I don’t think we’ll be more sybil resistance just with policy changes. But it’s good to start with clearer statements and some warnings, which the judges should then evaluate in each case.

1 Like

This looks like a good step. Again, we are dealing a removal that needs some sort of proof in order to be considered a Sybil as such. A failure to do so would lead to a state of hyper-litigiousness.

So we can give a little help to jurors by saying what is the standard of proof in such cases.

I would love to move forward with this HIP, maybe start a draft for Phase 2. I agree it’s a great step towards making the registry more explicitly sybil-proof, which is the main objective of the registry.

Regarding notifications, I agree it’s something that already IS a problem.

I would love to test out the current mechanisms before phase 3 to confirm they work. I’ve also set up myself a notification on https://tenderly.co/ to alert removals, and I’m sure it can be used to automatize or alert people at scale. BUT I don’t think that should be in the scope of this HIP actually.

Also note that the cost of resubmitting if you miss a notification will be greatly reduced on Gnosis chain with POHv2, where it will also be easier (cheaper) to crowdfund profiles, AND reduce sybil footsteps and so on. So we will have a different environment really soon.


As you’ve said after this, it’s effectively almost impossible to provide irrefutable evidence. Unless the person records a video saying that, I believe this would make this HIP not to accomplish its goals.


I believe we should consider a couple of signals jurors should take into their consideration, give a couple of examples, the draft mentions that. We can’t be too strict with our definitions either, because then attackers will keep coming up with new ways of carefully dodging the strict rules.

Remember “The Law is Fractal”, and we shouldn’t attempt to anticipate everything, we should aim to build the rails that guide the jurors to take the decisions we desire.

2 Likes

I don’t understand why my suggestions would be different from the original proposal in order to acomplish the goals. Both needs some suspicion first and none can be 100% proven. Can You explain to me?

hyper-litigiousness

A way to do this is, make sybil resistance explicit first. Then, if abuse patterns are detected, then rapidly make an HIP and patch them out as legally allowed exceptions. We can’t tell what those exceptions should be without field knowledge.

Rationale: it’s impossible to predict everything, but we can go in the proper direction and then incrementally get closer.

The criteria has vagueness to it but it has a defined scope:

if it is very likely for the submitter to be a sybil

Maybe changing very to extremely makes the scope clearer. This criteria will never reach 100% certainty.
Another reason the criteria had vagueness to it is to prevent adversaries to find edge cases or technicalities on a precise definition, and then inject a lot of sybils. That way, the law can be explored from a starting point that is very safe, and move towards removing abusive patterns, instead of moving from a specific, unsafe point that gets riddled with exceptions.

1 Like

But It also crashes with UBI social use case, one of the largest now, am I right? So it’s not easy to ignore it.

If there was a clash between UBI use case and sybil resistance, and resistance to get away from priority inclusion, then the way forward is to simply fork the project so that there can be a safe registry and an inclusive registry. These philosophies are contradictory.

Inclusion first is good for UBI.
Sybil resistance is good for voting, identity and airdrops.

3 Likes

After all those toipics are clear, I believe we could move foprward with this HIP ( Acceptable management of family member’s PoH account )

We can discuss both things simultaneously, no problem. I’m totally against sybil resistance, even in the context of family, it’s not a negotiable trait for me. But parties that are interested should investigate and develop a decision.

1 Like

(1)

Some philosophical schools identify action with desire (like praxeology), in which case, every action you take does, by definition, imply personal gain. I find limiting the challenges to sybils for personal gain to be limiting. Then, “altruistic sybils” (whatever that means) are supposed to be allowed? Or “accidental sybils”?

(2)

I think this point can be derived without an explicit mention, but if you want to add it yourself, you can make a PR to my PR, or tell me exactly where would you place it.

(3)

I think that example is fine, since it’s a sybil. The child is not really in control of the account, the parent is taking the UBI and the voting power for themselves. (And also, I just don’t tolerate sybils). I think it’s a good example to make explicit to avoid emotional arguments around disputes.

1 Like

Some philosophical schools identify action with desire (like praxeology), in which case, every action you take does, by definition, imply personal gain. I find limiting the challenges to sybils for personal gain to be limiting. Then, “altruistic sybils” (whatever that means) are supposed to be allowed? Or “accidental sybils”?

Makes sense, personal gain is not the best definition then. But I keep thinking that the “kind of sybils” that we don’t want are those which implies some malicious intent. For example, I don’t see a problem for a human who helps his grandfather with web3 onboarding, creates a poh registry and then help him to connect to lenster or such. I know and respect your position about sybil resistance, but thats my point of view.

About (2), I’ll try to do it soon.

About (3), I disagree but it’s okay. Anyway, a suggestion is to make a proper definition of the “submitter” before any example. You’re saying that “anyone controlling the private keys == submitter” in this example alone. But then, in the “List of current required/optional elements and submission rules”, we talk about “submitter name”, “submitter photo”, etc. So, who is the submitter then? The one that clicks the ui buttons? Anyone who manage the keys of the human in the video? What I’m trying to point here is that if we want to be explicit with sybil resistance in order to have arguments that helps to curate the registry, we need to be more specific. If you’re interested in what I’m saying, I can help drafting some definitions here.

If anything, any modification to the acceptance criteria must have:

  • A clear definition
  • What constitutes good evidence and what does not.

This does not harm the scope of any subsequent modification to the acceptance criteria, but it strengthens the legislative corpus towards clearer merit-worthiness and transparent procedures, something that latest removals lacked at its best.

If accusers and jurors do not have concrete procedures to assess merit and evidence, then it comes to the challenger to make the most spurious interpretations of what an “actor that has direct control over registered human accounts that don’t represent them” means in practical ways.

In summary, let’s make it

  1. Easier for jurors to decide
  2. Safer for registered humans to fall in false positives
  3. Clearer for challengers that are legitimately curating the list
2 Likes

I believe we need to resurface this HIP, since HIP-63 might be moot without it.

2 Likes