This is a repost. Please refer to the original post’s comments before replying.
HIP: 58
title: Vouchallenger removals framework
authors: ludoviko.eth, herniadlf.eth
status: Phase-3
created: 2022-07-16
Simple Summary
This HIP proposes a framework to allow to make removal requests under any of the already existing reasons for removal, in cases where an account is evidently vouching maliciously.
Abstract
The proposal will allow vouchallengers to be removed if they meet the vouchallenger definition in the body of this HIP. Vouchallengers will be removed and cannot re-register after a period. This will be enforced by a modification of the PoH policy. It will not be retroactive but the historical actions will be considered if there is a new vouchallenge.
Motivation
Vouching a profile is an act of responsibly giving the recognition of a legitimate and valid submission to the registry. Since the launch of Proof of Humanity, vouchallenging as in “the act of using the vouch feature of registered humans to make another profile vulnerable to challenge” has become a serious issue. As of the day that this HIP is being written, 57 profiles have more challenged vouched profiles than valid vouches, resulting in 211 challenges and a damage to the registrants totalling around 25 ETH. and the number is growing. A series of governanceposts raising the issue and some solutions were proposed during this time. @donosonaumczuk has proposed a robust and good approach for L2 rollups and future upgrades to PoH’s smart contract, but in the meantime there are possible solutions that could make it harder (important! not impossible!) for malicious actors to continue this attack.
Specification
1. Add removal criteria
In the latest PoH policy version, there are some explicit criteria to ask for a profile removal. A new removal criteria that allows a vouchallenger to be removed can be added. We can instruct jurors that in the case of a removal of a vouchallenger, if the alleged vouchallenger challenges this removal, to rule against the vouchallenger (effectively removing them from the registry).
2. Add admission criteria
In order to avoid the vouchallenge to re-register after a removal, another modification to the document will allow the cases where the removal was due to a vouchallenge to be inadmissible for a period. The text in the primary document will read:
- The submitter must respect the vouchallenger inadmissibility period, as defined in the Vouchallenger section of this policy.
That base_period is 120 days (4 months). A vouchallenger that continues vouchallenging after a removal will be removed again folowing section 3 “Conditions to consider a vouchallenger as such”. The next inadmissible periods will be calculated as base_period*(times_removed). No matter the cause of the removal.
Parameters to consider:
base_period = 120 days
times_removed
3. Conditions to consider a vouchallenger as such
A vouchallenge is a vouch that results in a challenge. The vouchallenger is the profile that performs a vouchallenge, AND:
- A profile that exceeds or equals the
max_vouchallenge_ratio. The ratio is calculated asvouches_wtih_incorrect_submissions / total_vouches, AND - A profile that has vouched at least
initial_vouchallenge_thresholdthat ended in any type of challenge, OR - A profile that after being already removed for being a vouchallenger, that makes at least
repeated_vouchallenge_threshold=1, OR - A profile that was bribed to perform a single vouchallenge according to section 7.
Parameters to consider:
max_vouchallenge_ratio = 1/2
initial_vouchallenge_threshold = 2,
repeated_vouchallenge_threshold = 1
4. “Refuse to arbitrate” in challenges made from a re-entrant vouchallenger
If a vouchallenger is removed and then re-registered in Proof of Humanity, every new vouchallenge must be voted as “Refuse to Arbitrate”.
5. Retroactivity
This HIP is not retroactive to profiles that performed vouchallenges in the past that cross the initial_vouchallenge_threshold. However, if a previously active vouchallenger performs a new vouchallenge, and it is above the repeated_vouchallenge_threshold it will be considered a vouchallenger and will be removed.
6. Whitehat vouchallenge
In the case the deposit is returned to the challenged person from a vouchallenger that meets the criteria of section 3, that vouchallenge is not considered for the total count. The total deposit fund must be returned before the end of the evidence period of the removal request challenge.
7. Bribed vouchallenge
If there is proof (transaction records) that a vouchallenge is performed by a wallet/profile that received funds or tokens from another wallet/profile or a standalone wallet, the total amount of vouchallenges is added to both wallets.
Proof applies for wallets directly or indirectly connected to other wallets by funding/being funded in the last 6 months.
Case examples
- A recently registered profile that vouches its first profile that ends in challenge.
- Not a vouchallenger since the minimum of vouchallenges is 2
- A profile that has 24 vouchallenges but 340 total vouches
- The ratio 24/340 is 0.07, so not a vouchallenger
- A profile that has 2 vouchallenges and 4 total vouches
- The ratio = 1/2, so it is a vouchallenger
- A profile that was previously removed as a vouchallenger and after re-registering vouchallenges again
- The profile is a vouchallenger
- A person that attemps re registering the day after they get removed as a vouchallenger
- The profile is challengeable and whoever challenges it gets the vouchallenger deposit.
- A profile that has a ratio of 0.87 before the implementation of this hip, and then performs a challenge:
- Clause 5 applies, profile is a vouchallenger
- A profile that is being requested a removal, but returns the deposit to the address of the vouchallenged
- Not a vouchallenger, and the vouchallenged is not added to total vouchallenges.
- A profile that it is proven that he received funds from a wallet tied with transactions from a known or reported vouchallenger address (registered or not).
- A vouchallenger, no matter the ratio.
Rationale
- More robust solutions than this one will come in the future, but this solution tries to ammend the situation as of today, which has brought a large impact to the registration process.
- The parameters are very strict to stop the abuse of these days. Such parameters could be changed in future HIPs.
- The vouch process need to be enhanced and be taken seriously.
Implementation
Following what was specified in HIP-45, the pull-request (https://github.com/Proof-Of-Humanity/poh-docs/pull/4) was open for comments. That version was updated in https://github.com/Proof-Of-Humanity/poh-docs/pull/5 and this version will be merged if the phase-3 poll gets the result of “Accept changes”.
Once merged, it will be uploaded to ipfs with the .MD extension:
When this HIP is merged, the Markdown document that was specified above, will be provided as it is, without rendering, as a plain Markdown file, on the MetaEvidence.
We will obtain a new URL for the policy at ipfs. From now on, this url will be named “newPolicyIPFSURI”.
Once uploaded, the final “_registrationMetaEvidence” file will be also uploaded to IPFS, setting the fileURI to the “newPolicyIPFSURI”.
Actual registrationMetaEvidence
{
"category": "Curated List",
"title": "Proof of Humanity Registration Request",
"description": "A request to register the specified entry to a list of provable humans.",
"question": "Should the request to register be accepted?",
"fileURI": <newPolicyIPFSURI>,
"evidenceDisplayInterfaceURI": "/ipfs/QmSL8d82dMhcThwERWaF4LtmCa4hgV7TyPjAo4fKCzPVkv/index.html",
"rulingOptions": {
"type": "single-select",
"titles": [
"Yes",
"No"
],
"descriptions": [
"Accept the request to register the entry.",
"Deny the request."
]
}
}
We will obtain a new ipfs uri that we call “finalRegistrationMetaEvidenceURI”.
The final “_clearingMetaEvidence” file will be also uploaded to IPFS, setting the fileURI to the “newPolicyIPFSURL”.
{
"category": "Curated List",
"title": "Proof of Humanity Clearing Request",
"description": "A request to remove the specified entry from a list of provable humans.",
"question": "Should the request to remove be accepted?",
"fileURI": <newPolicyIPFSURI>,
"evidenceDisplayInterfaceURI": "/ipfs/QmSL8d82dMhcThwERWaF4LtmCa4hgV7TyPjAo4fKCzPVkv/index.html",
"rulingOptions": {
"type": "single-select",
"titles": [
"Yes",
"No"
],
"descriptions": [
"Accept the request to remove the entry.",
"Deny the request."
]
}
}
We will obtain a new ipfs uri that we call “finalClearingMetaEvidenceURI”.
Governor Transaction
We will create the transaction in the kleros governor to call the changeMetaEvidence method of ProofOfHumanity contract. The parameters will be the named finalRegistrationMetaEvidenceURI and finalClearingMetaEvidenceURI.
