I am trying to make sure I understand something correctly, so I will pose a problem with a solution.
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
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.