I am trying to make sure I understand something correctly, so I will pose a problem with a solution.
Problem:
Let's say commit
has been called. After this, we call the reveal
. attacker listens to commit
transactions, and calls the commit
was a front-run by himself. Then, attacker listens to reveal
transactions. What attacker does now is as soon as he figures out there's a new reveal
transaction in the pool, he grabs the arguments(these are the arguments how the hash was derived from), hashes them and if it matches the one already stored on his own address when he called commit
, then attacker will also front-run the reveal
transaction.
Solution:
I think the only solution to the above problem is that we include msg.sender
while getting the commitment hash. This way, even if attacker listens to reveal
transactions, and front-runs it, it won't be enough, because msg.sender
of attacker will be different and it won't produce the same hash as commitment.
Question 1: What do you think ? Am I right about Solution above ?
Question 2: I've seen some implementations that msg.sender
is not included while deriving a commitment hash. This means that front-run still exists, which means attacker front-runs commit
, and then front-runs reveal
. If there're lots of transactions happening, sure, this front-run doesn't make any sense to the attacker, but I don't think commit-reveal
scheme solves front-run if we use it for quiz
smart contract where user submits the solution and gets the reward, because attacker can listen to commit
again and it's highly likely that whoever commits, is most likely the winner, so attacker will also wait for the reveal
from the same user who called commit
and front-runs again. What do you think about this ? For me, for quiz systems, commit/reveal
doesn't seem a good solution to solve front-running. Could you put some examples where it would really be useful ? NOTE: I know commit/reveal
is a good scheme, but I need examples where it solves the front-running problem and doesn't use msg.sender
in the hash too.