category of odds and evens.sol is wrong!

[BuggerBag]

odds and evens.sol is not front running, front running is a problem that race condition has happened at the mempool. it category beyond to Unencrypted Private Data On-Chain

ref: https://swcregistry.io/docs/SWC-136#odd_evensol

[BuggerBag]

the attacker or Eve must wait until the first transaction is mined, after that Eve watches the internal transaction of oddevent contract and choose wise data for getting profit. front running means that the Eve transaction was mined before the party transaction. meaning of those is very important! please edit your repo, thank's in advance.

[jff]

Thanks, @BuggerBag

@pedrocrvz WDYT ?

[pedrocrvz]

I agree with the attack vector described by @BuggerBag, but even in that scenario, if the winning transaction goes through the mempool, Eve can be front ran. Like all unencrypted/private/secrets relying contracts, if not handled carefully (e.g: via commit/reveal schemes or access control), front running can also be possible on the winners transaction submission. Alice and Bob are playing the game, Alice plays first and submits her number. Bob plays seconds and submits a winning transaction - at this point anyone watching the mempool can front run Bob and win the game (this can easily be done by any generalised searcher/bot watching the mempool).

[BuggerBag]

Hi, thanks for your response, I think, if the first number was encrypted, the attacker can't decrypt it. if the number encrypts with CBC (cipher block chaining) then attacker can't decrypt it. so the front running is not meaningful. I have one question, if the front running was solved, does the attacker lose? (my answer: never, because the contract has a race condition problem) I think the root cause is unencrypted data. I think the functionality of Odds and Evens is not correct. if the functionality is correct, then the attack vector will be meaningful. few smart contracts at SWC have the wrong functionality, this one was such that. Big thanks to @jff and @pedrocrvz