4 ms·

Thanks for the explanation. Good point about staking, assuming if the validator is chosen before, then they are certain to get the chance to order the transacti

Thanks for the explanation. Good point about staking, assuming if the validator is chosen before, then they are certain to get the chance to order the transactions in their favour. The article, as I understood, the caller predicts the outcome of the 'random' function first, and then calls if the result is favourable. It seems like yours is more efficient, as it relies on using revert() to undo all state changes, if the outcome was unfavourable, so no need to predict anything!

AgentME 9y ago
I originally considered making my contract predict the outcome of the 'random' function first, but I got lazy when I realized I could just check whether I won and revert the transaction afterward for the specific contracts I wanted to attack. It also meant that my win-forcer contract was more generic and could work against more naive roulette contracts. However, my strategy would not work against naive roulette contracts that immediately on deposit calculate whether you won, but don't tell you or let you get the money until later. (I didn't encounter any like that, but it's a possible flawed way someone might attempt to make their contract defend against attacks.) To attack those, you would need to do the article's strategy of predicting the 'random' outcome first before making the deposit (or have your win-forcer contract automatically check the random outcome for you, and only make the deposit if it knows you'll win).