Possible Front-end solution to vouch and challenge attacks

Proof of Humanity
1

Possible Front-end solution to vouch and challenge attacks

I’ve been thinking about how to solve the vouch and challenge problem that is still happening within Proof of Humanity.
Keeping in mind that changing the smart contract is not within the possibilities, I came up with a pretty straightforward solution.
Within the UI, it is possible to know if the vouchees (users vouched by someone) have been challenged and removed because of that. What I believe would help is introducing a minimal vouching coherence (I suggest 80%). This is good because the process for fair and square vouchers would be left unmodified without putting that much pressure on them. This feature would help the community because if someone intends to vouch maliciously, they would first need to correctly vouch for at least four other submissions. This only would reduce the actual vouch + challenges to 20%.
Another feature that I’d like to propose is a temporary vouching lock in the case that a profile’s vouch results in a challenge. I believe it is in the project’s best interest to lock vouches for 45 days since the challenge began.
This solution could be bypassed if a person interacted directly with the contract using the regular (gas consuming) vouch. Given the gas values of the Ethereum Network, the profit to be obtained by challenging a registration is around 0.04ETH. Vouching on-chain would lower that number to around 0.025, thus decreasing the incentive behind this mechanic significantly.
This is what a user would see if they wanted to vouch and shouldn’t be able to:

473×838 68.2 KB

Also, vouched profiles would now appear green if they are either on “Pending Registration” or “Registered” statuses and red if they are “Removed” due to a challenge.
I already coded the features described on the following repo (https://github.com/bilinkis/POH-vouch-timeout).
I’d like to know what others feel about this features and appreciate all the feedback you’d like to share.

4 Likes
2

I believe it could be a good patch for the UI. There is no way that a person mistakenly vouches so many people and end in challenge, so it would not increase friction in any sort of way. Even if people did mistakenly vouch people, we would be protecting them from even themselves and others.

3 Likes
3

Hi @0x17a91203a9e9c3519c2f76210497ef7f4be2352f_Ethereum ,

I am not a specialist, but in reading them, your proposals seem to be coherent and bring significant improvements to the vouching system.

Moreover, the fact that they are fairly simple to implement suggests that, if a large number of problematic situations were to arise as a result of their implementation, it would also be simple to modify or remove them.

1 Like
4

Well the vouch is locked during the challenge so that’s already happening to some extant (but not 45 days).

Changing the UI wouldn’t stop people as they can interact with the contract directly.

But the idea of preventing users to vouch for some time if they have vouched incorrectly is interesting.
Currently it’s binary:
Either the reason is considered related to a mistake and the voucher is not removed. Or the voucher is removed from the registry. Having a time out in vouching would allow to have an intermediate kind of disincentive.

2 Likes
5

So what is the plan? Can we put a bounty?

6

Yes. But by doing this relatively simple change in the UI you add friction to the malicious vouching process. This would stop attackers who do not have the skill to write directly to the contract. It would not stop everyone but at least it will stop some (maybe even a majority).

1 Like