Claiming on behalf of others

fredo commented 1 year ago

Currently an address only can claim for itself. This leads to a single point of failure risk. We can open up this requirement to allow any address claim for another address. This would solve the fact that one address can actually be the filler, but another address can claim on behalf of the filler.

The interesting part is how the claim stake is handled and where it is coming from. As a first step, I would suggest to keep this question completely out of the protocol and let the involved parties decide this on their own.

So what does it mean?

Anyone who is initiating the claim is responsible for paying the claim stake. This is necessary so that we protect the protocol from spams, or dragging any address into false claims. The "claimer" in the claim struct remains to be the address which is submitted as a parameter to the claim function. The actual message sender is NOT the claimer but the (claim) initiator. However, the initiator must provide the initial claim stake. This means, it is the initiator who puts in stake and risks to lose it if it is a false claim.

Claim stake distribution

The easiest way would be, that the final claim stake distribution goes 100% back to the claimer. This means that the amount "claim stake" staked by the initiator is sent to the claimer. The claimer and the initiator have to have their own way to deal with this fact and this would be out of scope from a protocol point of view. From my side this should be fine as a first implementation to this feature. The reason is that 1) it touches the protocol only slightly at first, 2) The parties could deal outside of this either in a trusted manner or in a form of a contract who deals with this exact relationship, 3) it opens up the possibility that the actual agent can run multiple processes to claim on behalf of the whitelisted address (initiator and claimer are different addresses but the same entity).

If at one point there is a need for this feature to become a generalized service by a third party, we could reevaluate if further contract changes are needed.

Claimer whitelist

In the latest contracts claimers are also whitelisted. This is because we wanted to reduce the pressure on the protocol due to false claims. I see three options how we can handle this. 1) Agents who want to use this feature will have to ask us to whitelist additional addresses on the claiming side 2) we need to give up the whitelist and allow anybody to claim, opening up again the risk of system overload due to many claims 3) We check the claimer (not the initiator) to be a whitelisted address. In this case, a system overload can still occur but the only ones who can exploit funds are agents which we do have some sort of relationship to for now (also due to the whitelisting process)

Background: Why do we have a whitelist on the claiming side?

The reason for this was the fact, that our agents currently run with limited capacity in terms of funds. Additionally, the network of "watchers" is rather small in the bootstrapping phase (agents, voluntary watchers). In this phase it is easier for an attacker to lock up all eth, which are provided for challenges, in running challenges. Once this happens, an attacker has 24h to claim a request and if nobody tops up the funds nobody will challenge it, and the attacker will be able to exploit the protocol. The more ETH the agents will provide the less likely this is to happen. But with the current status of the network and with limited monitoring system in place, the decision was made to strengthen the security by introducing a more controlled structure.

Acceptance criteria

[ ] @andfletcher checks with legal if we can do option 1
[ ] We create a claim on behalf of others' whitelist
[ ] Addresses on this list can claim on behave of others as long as they are on the whitelist
[x] We can add and remove addresses from the whitelist

Additional information

This only focuses on the contract changes that would allow a claim on behalf of someone. The software that will allow doing this is a separate issue that needs to be created @andfletcher

istankovic commented 1 year ago

Very nicely written. :+1: As for the "Claimer whitelist", I'd go with option 3 for now. Once we get rid of the whitelist entirely, it too will go.

The drawback to this is that we postpone the "system overload" testing to a later time, when there's greater damage to be done due to higher volume etc.

fredo commented 1 year ago

I thought a little bit more about the discussion of the option and I'd like to correct myself. Like @istankovic I'm also leaning towards option 3. The reason herefore is that we allow an unlimited claiming but with the restriction that only whitelisted agents can become the claimer and ultimately receive the funds.

This is actually a quite convinient way of opening up the system in "some sense", but have the beneficiaries at hand so we can figure out with them if something goes wrong. I wouldn't want to let this opportunity pass. @andfletcher please rethink and ask legal department if everything is alright. Any questions don't hesitate to ask.

andfletcher commented 1 year ago

@fredo @istankovic if both of you think option 3 is the best way forward then let us go for it.

beamer-bridge / beamer