Posting on behalf of Mateo Daza @mateodazab who is the main author of this proposal and, for some reason, has his account locked for posting or commenting. I participated in the draft and review process.
Simple Summary
This proposal calls for a change in the vouching mechanism, in such a way that the registry applicant can accept the vouch that they are receiving. This prevents vouch-and-challenge strikes.
Abstract
Incorrect submissions by human errors can be very usual, most of the time regarding the wallet address on display. There are good chances of noticing and fixing this error before getting a vouch and risking a very costly submission. Challengers have an assured win for the challenge in the cases where the error is explicit. There have been cases where strange people give a vouch and instantly challenge the profile to make profit. Allowing users to accept vouches would give an extra chance to notice errors and disable this sort of “attack”. Besides it would encourage the registrant to confirm having physically met the voucher.
Motivation
This proposal is a follow up from this snapshot with almost a hundred votes, which indicates that this is a very relevant topic and that it needs a swift solution.
Another dispute associated with this practice is Case 671.
Specification
Current flow allows any human to give vouches and automatically start the challenge stage for the registrant, this improvement should add an additional step for manual acceptance from the registrant. just like the “start accruing” action.
This would require a new version of POH taking considerable development time and disrupting the registry.
It would make the UI way worse for people involved and increase the gas cost of a registration.
Users already have the possibility to “fix” just after submitting (at a cost of gas). It would only happen in really rare cases that someone find his submission is wrong after someone they don’t know vouch and challenge them.
Even if it was the case, this would increase challenge rate leading to a need to increase the deposit everything else considered equal.
The snapshot poll was done without discussion therefore only the side “change the vouching mechanism” had the possibility to express themselves about it. Polls without discussion are not a democratic process.
In general trying to change a system because of one case isn’t a good idea. It could make one case nicer, but the 4000 other cases worse (that is exactly what this proposal would do, the lost time and gas would be order of magnitude higher than the benefit of someone being able to correct his mistake).
It doesn’t matter that we can’t solve it at the moment. Addressing the issue is important and looking for better options. I get that the gas costs are a problem but I’m sure there are alternatives to the flow.
My point is, let’s keep thinking about it and not shut it down just because it’s rare. Maybe the solution isn’t even this and more about Kleros decision making.
EDIT: The bigger this project gets there are more chances these edge cases occur, I can easily picture people “hunting” mistakes just to get a piece of the stake and not for curation as it’s actually profittable.
It’s perfectly fine. Someone made a submission which was incorrect and they lost their deposit. This is the expected behavior. You will be rewarded for it and incentivized to look at the registry to find potentially more incorrect submissions.
But here a challenger does the change-to-pending (thus enabling challenges). Doesn’t that deprive the applicant of a little more time in which they might have caught their own mistake first?
The fact that they have time to withdraw is a courtesy (also made to allow people not finding vouchers to withdraw), not a right. If they don’t notice it before someone else does, they have a very low chance of noticing further.
I agree with @clesaege’s points but I don’t think that simply saying “no” should be enough. This is a super helpful issue to think about how to improve governance. I have a few ideas, @clesaege, @ludovico and @mateodazab let me know your thoughts.
We need guidelines with the reasoning behind the current registration process and key points to be taken in consideration before proposing changes to it, so that everyone can participate in an informed way.
We could do a co-creation workshop where we have all perspectives represented and together we analyze the issue more in-depth to devise a solution (maybe we can have other changes in the ui that address the issue without involving more gas cost and significant development time).
There’s also an open question about how developers working on Proof of Humanity should prioritize their work. With everything we propose, we must always remember we are working under limited resources, and developer time needs to be used extremely wisely. If the community votes a change that will address a minor case, but would take developer time away from work that is crucial to the growth of Proof of Humanity, how should we proceed? We need to be able to consider things in context. I started working this week on a non-binding prioritization process to address this question… will post soon!