Hacker News Reader

Comment by baby | Hacker News Reader

That is a really really interesting post. I always figured that these were only exploitable from a miner's point of view, but no! Creating a contract that will access the same randomness and THEN query the targeted contract will work, since they both happen in the same block hence the randomness will be the same.

View on HN

Yeah, I used this trick to empty out a few tens of dollars worth of Ethereum from a few naively-coded roulette contracts that were sitting around with a little money left in them.

Say a contract exists in the blockchain that owns a little bit of ether and has code so that if you send it a certain amount of money, it does some magic to randomly determine whether to send you more money back. I found a few contracts like that. All I had to do was code a contract that would send money to the target contract, check its own balance (to see if it won some money from the target), and then abort the entire transaction if its own balance isn't greater than it started with. The code was really simple: https://gist.github.com/AgentME/d4cc6aa355900853b8ede3a84b10...

("Tens of dollars" was in present prices. I assume it was an even tinier amount of money when the creator or previous users put the money in. I think there's multiple interesting moral problems here: if you decide to ignore any "code is law" notions about Ethereum and call what I did as stealing, is the crime lessened by the fact that they thought it was worth even less when they put it into the contract? Also, who exactly did I steal from? The users who put the money into the contract believed they had gambled it away. Does it make a difference if they believed that money was going into an un-owned pot to be winnings for the next person? Do I count as a "winner", since I did claim it in a way it was coded to accept? ... Maybe a related problem: If someone doing some kind of art/performance statement purposefully hid money underground in a random place on public property unlocked, unmarked, and location unknown to themselves such that they thought no one else or even themselves could ever find it, and then I find it with x-ray goggles and take it, am I stealing?)

The questions of morality are largely orthogonal to questions whether surrounding institutions have strategies to address behavior considered 'problematic'.

In the overworld, we have institutions which continuously interpret, enforce, refine, and revise both the letter and the spirit of contracts and law.

Ethereum developers and VIPs have already shown that they'll use hard forks to steer the community towards their preferred direction, and individuals will have to decide which chain to pursue. Since your actions are small beans and unlikely to prompt the Ethereum decision makers to reverse these transactions, you and others can likely keep doing such things in the future, and those affected will have little choice but to accept it.

Ok, but their question was morality, not what will be enforced, so, I'm not sure why you are bringing up what will be enforced?

I think they are interestingly intertwined questions. If something happens that's egregiously morally out of bounds, then people will find or create ways to enforce against it. From the other angle, existing enforcement mechanisms will impose themselves as trying to define what moral is. In a way, besides the little selfish gains, I may be fatalistically trying to define "code is law" as moral because it is what I am presently capable of enforcing. Maybe I'm just talking myself in a circle; it's good fuel to ruminate on.

> If something happens that's egregiously morally out of bounds, then people will find or create ways to enforce against it.

I think you left out "and a lot of money is involved". Do you think there would have been an emergency hard fork if the DAO only had $100 in it? I sincerely doubt it.

> existing enforcement mechanisms will impose themselves as trying to define what moral is.

Morality and Law (code or not) are different things. You can't code morality - you can only encode the programmer's morality. (Which is not the same thing, because the programmer can change his/her mind.)

I guess it would be more responsible to report the bug to the contract author first. Perhaps they will let you take it as a reward, and you'll sleep better at night and won't have a moral dilemma ;-)

Seriously though, nice find. What would be a way to defend against this?

The main article mentions some defenses. Never immediately determine whether or not the user wins; the basic idea of a transaction that immediately within the block results in win or lose has to be thrown out the door. Instead, roulette-type contracts always must have the user pay in as one transaction, let the user at a later block check if they won, and then let the user withdraw any winnings in a separate transaction.

An easy and pretty good way to do this is to record the block number they make their deposit, and then have the question of whether they win or lose be calculated from the hash of the block some fixed N blocks after their deposit. There are certain attacks by miners that are possible to try to force a win, but the attacks require the miners to forfeit mining rewards for blocks they calculate where they lose, and unless N is small enough for an attacker to try to generate the whole chain of deposit-wait-then-withdraw blocks, or the entire network is working together, it's likely that a different miner will create a block first and interrupt any miner trying to bruteforce a winning block. So if the winnings are under the size of the block reward amount, there's basically zero danger, and the danger is tiny unless the winnings are ridiculous. ... I hadn't thought about how possible future proof-of-stake schemes affect this though. Those might be fatal to this strategy on second thought, since it might be easy for a staker to try out many block variations. I'm not too familiar with this detail of PoS schemes though.

Another common solution involves active oracles and commit-then-reveal schemes, but they generally require the oracle to be honest, or else the oracle could participate in the lottery and force its own win. There are common ways that oracles try to show their own good behavior, so people can notice if they cheat and stop depending on them. As long as it's more profitable for the oracle to continue operating than to cheat a roulette and then be shunned, things work out.

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!

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).

It seems like commit-reveal is really the only thing that makes sense.

Reply on news.ycombinator.com