[On Hold]HIP XX: Allow a waiting period after vouch and before pending
HIP: <Number to be assigned>
title: Allow a waiting period after vouch and before pending
author: @juanumusic @ludoviko
status: On Hold
created: 2021-11-02
This proposal has been put on hold until technical feasibility issues are solved.
Simple summary
The purpose of this HIP is to create a mechanism that gives the registering Human extra time between the moment they are fully funded and vouched and the moment they can Advance to Pending.
Abstract
This proposal will look to implement a change in the Proof of Humanity Smart Contract (PoHSC) that creates an extra status right after a user has been vouched and before moving to the PendingRegistration status. During this period, the Human is able to remove their submission.
Motivation
Occasionally a Human Profile submission does not follow the rules by a presumed-innocent mistake. Vouch-and-challenge attacks are those in which these Profiles are vouched by a person unknown to the target in coordination with a malicious challenger. This is done without the target’s consent and reduces the time the person has to notice its mistake or be warned by someone else.
These attacks are just an exploit of the role of the Voucher, a person that has an equal role as the Challenger has in helping to keep the Registry without duplicates and inappropriate submissions. It is also typically considered a position of trust to the person that is trying to be registered in Proof of Humanity. Although not frequent in terms of the amount of the total humans that get successfully challenged and the legitimate challenge to truly malicious submissions, the fact that an innocent person is being “gamed” by the system generates negative attitudes towards the project and the reputation and sustainability of it.
Another motivation to make this proposal advance is to make it less harsh and to look ways to be more people-friendly:
“This “you lose your deposit if you do it wrong” mechanism is harsh! Has there been any thought put into ways to be more friendly to people making mistakes?” V. Buterin(Source)
Resumen simple
El objetivo de este HIP es crear un mecanismo que proporcione a la persona que se inscribe un tiempo extra entre el momento en que está totalmente financiada y voucheada y el momento en que puede moverse a Advance to Pending.
Resumen
Esta propuesta buscará implementar un cambio en el Contrato Inteligente de Proof of Humanity (PoHSC) que cree un estado extra justo después de que un usuario haya sido voucheado y antes de pasar al estado de Pending Registration. Durante este periodo, el humano puede eliminar su perfil.
Motivación
En ocasiones, el envío de un perfil humano no sigue las reglas por un error presuntamente inocente. Los ataques “Vouch-and-challenge” son aquellos en los que estos Perfiles son avalados por una persona desconocida para el objetivo en coordinación con un retador malicioso. Esto se hace sin el consentimiento del objetivo y reduce el tiempo que la persona tiene para darse cuenta de su error o ser advertida por otra persona.
Estos ataques no son más que una explotación del papel del Voucher, una persona que tiene un papel igual al del Challenger en ayudar a mantener el Registro sin duplicados y envíos inapropiados. También se suele considerar una posición de confianza para la persona que intenta ser registrada en Proof of Humanity. Aunque no es frecuente en términos de la cantidad del total de humanos que son desafiados con éxito y el desafío legítimo a las presentaciones verdaderamente maliciosas, el hecho de que una persona inocente esté siendo “engañada” por el sistema genera actitudes negativas hacia el proyecto y la reputación y sostenibilidad del mismo.
Otra motivación para hacer avanzar esta propuesta es hacerla menos dura y buscar formas de que sea más amigable con la gente:
“¡Este mecanismo de “pierdes tu depósito si lo haces mal” es duro! ¿Se ha pensado en formas de ser más amigables con la gente que comete errores?” V. Buterin(Fuente)
I agree with the spirit of this HIP. Having more leeway for honest mistakes is certainly how we need to move forward!
For people submitting a profile, waiting a couple more days at this stage will not be a big deal, but it might be crucial if someone can reach out and help save their profile.
Lately we had a series of situations where the image of the profile did not load for some reason, and it would have prevented that.
If it turns out the change doesn’t have a lot of impact, then we can set the curation time back to 0. It’s also nice to be able to change this parameter if necessary.
It will be easy to measure the impact of submissions withdrawn during this period.
Also, the incentives for challengers remain intact.
This proposal done at a smart contract level, in addition of not being desirable (creates an additional delay in getting ones identity reducing the UX of the system) cannot be technically executed without a complete redeploy of POH. So unless it were to be updated to include a full v2 an migration path, it would be void.
Currently, it would mean people being delayed in getting UBI. It would also prevent POH usecases where getting registered fast is primordial (currently we’ve seen the Artistical Intelligence NFT drop where people would have been unable to register in time and stuff like the priority tickets for POH members that we had set up for the blockchain week would also be impacted as people cannot register in time).
From a UX perspective, it would also make people less engaged as it takes more time to register. It would also lower the registration rate as people would have to wait longer before being able to give vouches.
From a security engineering perspective, making the contract more complicated to prevent people from making mistakes would be a violation of the
Limit smart contracts to blocking malicious behavior and let clients prevent the stupid ones.
principle.
Here comes the solution where we no one would be penalized: Have different frontends.
Some people (on which I believe the supporters of this HIP belongs) would like an extremely heavy process to prevent people from making mistakes, even if it means reducing the UX & decreasing adoption speed. The reasoning being that people making mistakes and losing deposits is bad press.
Some other people (on which I belong) think that users should be able to be responsible for their security. Favor rapid adoption & protocol security even if this means that some people will lose a bit of money (or actually earn less, as people losing deposits get more in UBI than their lost deposits so they are still positive overall).
The solution for that is having multiple frontends:
One for users who are sure about themselves or for whom losing a deposit wouldn’t be dramatic and favor fast registration.
One “childproofed” where the user is given way more warnings, speed bumps (this proposal) and opportunities to correct errors.
This would also have added benefits:
Being more resilient (for both bugs and attacks on servers).
Being more legally resilient (the Kleros Cooperative currently running the frontend has received legal threats from people who had put videos of them naked asking us to temper with the frontend, fortunately we were able to talk them out of it showing them how to withdraw their submission and make a new video). There may also be new legal threats we haven’t anticipated yet and being one among a lot of fronts would make it more resilient to those.
Letting the market handle what is the best of those two opinion groups by letting users choose between different fronts.
As discussed yesterday with Federico Nanni, we already came to the conclusion that upgrading the contract is a harder way than we thought of.
Although this UIP will not pass phase 1 (because of the paragraph above), it would be interesting to hear from someone at Kleros (like @clesaege ) what is the technical way that Kleros has set up for upgrading the POH contract if it was needed, since it’s not an upgradeable proxy.
If you are referring to Proof Of Humanity, we advise you to either:
Reference the main contract and have a mechanism to switch to a new one.
Reference the proxy which will automatically be updated in case of new versions (like one allowing anonymous accounts). The proxy also acts as a pseudo-ERC20 returning a balance of 1 VOTE to people registered in the registry. This allows to use it for some voting systems using tokens such as Snapshot.
So devs using POH can either reference POH directly (in the case they want POH upgrades to be opt-in) or the proxy (which is controlled by the DAO and can be switched to aggregate data from multiple POH versions).
So to upgrade we need to:
Switch the proxy to also get data from a new contract.
Convince people who are referencing the main contract to also allow the new one.
This proposal has been put on hold until technical feasibility issues are solved.
