how does commit/reveal solve front-running?

Question

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.

Answer 1

Some remarks:

• Usually commit and reveal phases are separated such that no commit message are allowed after certain point. That way if someone send a reveal message an attacker no longer can send a commit with the answer.

• The committed message must include something extra that an attacker cannot alter like msg.sender or something he cannot guess like a random nonce.

Commit+reveal is a technique that helps prevent some cases of front-running but it is not an efficient situation requiring two transactions and several blocks in between those transactions.

Answer 2

Question 1: What do you think ? Am I right about Solution above ?

Agree. To prevent front-running, use a factor like msg.sender in the hash function so the front-runner can know the secret and still be unable to use that knowledge.

For example, consider a piggy bank with a secret word that releases the money. If the withdraw function uses (pseudo) hash(secret) then the front-runner can learn the secret word and try to claim the money first. If the function uses hash(msg.sender, secret), then front-running is prevented - the secret has to be sent from a certain address - two factors instead of one.

You should also consider how the contract executes the awarding of the prize. Consider msg.sender.transfer() versus rightPerson.transfer(). You want to be sure that the effect is that only the correct account ever actually wins.

For certain apps, you might want to make it possible for anyone to pay gas to push funds to the right person. Suppose there is no reason for Alice to want to leave her funds in place and Bob wants to be a hero and pay her gas. That can work as long as the contract is certain about where the money should go.

mapping(bytes32 => unit) public pendingPayments;

function beAHero(address receiver, bytes32 secret) public {
  bytes32 key = keccak256(abi.encodePacked(receiver, secret));
  uint amount = pendingPayments[key];
  if(amount > 0) {
    pendingPayments[key] = 0;
    receiver.transfer(amount);
    // emit ...
  }
}

Alice could give Bob her secret and all Bob would be able to do is pay for gas, if he wants to. Alice gets the money in any case. If receiver.transfer() is instead msg.sender.transfer() then anyone who knows the secret can take Alice's money, including front-runners who listen to the pending transactions.

(just a scribble, so please forgive my typos).

Hope it helps.

Answer 3

If the malicious owner sees the hash you submitted and submits the same hash, your solution breaks down.

Commit-reveal can be used only if it is hidden when committing and open when revealing. When committing, there are so many people who have committed it, so it should be difficult to know who's right.

A suitable example of commit-reveal is to answer a quiz or bid.