This is a bug. The resolution registry maps from fill hash to filler. That implies that an attacker who presents a false claim with a random fill id will not be invalidated by the fill proof of the real filler. This attack only happens if the real filler hasn't withdrawn yet. But it is possible that this happens.
Decision
Instead of sending the fill hash we will send the request hash and fill id separately. This counts both for Non fill as well as fill proof.
Functions must be renamed accordingly in the resolution registry. In the Fill manager the fill hash can remain.
The fillers mapping changes to mapping request hash => filler, fill id.
For the invalid fill hashes the fill hash could remain as is. There is no need to separate the two in the mapping. But they must arrive separated upon invalidation in order to check against the fillers registry.
This is a bug. The resolution registry maps from fill hash to filler. That implies that an attacker who presents a false claim with a random fill id will not be invalidated by the fill proof of the real filler. This attack only happens if the real filler hasn't withdrawn yet. But it is possible that this happens.
Decision
Instead of sending the fill hash we will send the request hash and fill id separately. This counts both for Non fill as well as fill proof. Functions must be renamed accordingly in the resolution registry. In the Fill manager the fill hash can remain. The
fillers
mapping changes tomapping request hash => filler, fill id
. For the invalid fill hashes the fill hash could remain as is. There is no need to separate the two in the mapping. But they must arrive separated upon invalidation in order to check against the fillers registry.