Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ethereum is Doomed

nakamotoinstitute.org

Post reply on HN
Print view View original

21–30 of 217 posts

Re: Ethereum is Doomed

#21

Post by cheez »

pmorici wrote: post #6
cheez wrote: post #3

> They created a situation in which bugs would be expected to arise in an environment in which bugs are legally exploitable. That is hacker heaven. Every single system has this problem. You think banks aren't hacked?

What _legally_ exploitable bank bugs have you heard of? Keyword there being legally.

It's effectively legal because a lot of financial fraud is not pursued.

For example, people from different countries scamming old people out of $1000 for Prince Abu to free his millions.

That being said, I can understand why you think something being legally exploitable is something new. Just like a loophole in a contract is a loophole in a contract.

In the case of smart contracts, there is no recourse unless built in to the contract. This is by design.

All that's going to happen is people will start writing smaller, more testable, less damaging contracts. This regime is different from legal contracts because many lawyers specifically write contracts to create problems later. In this new world, good contract writers will be gods.

So if you're a good software engineer, there is potentially a huge market about to open up for you.

Re: Ethereum is Doomed

#22

Post by DennisP »

I have actually tested this attack technique (using my own contracts on a local test chain), and I've been in discussions with some Solidity developers and the guy who first published the attack. The situation is not as bad as this article claims.

For starters, you can use address.send(x) instead of address.call.value(x)(). All computations on Ethereum have to be funded with "gas" (transaction fees), and send() only forwards a small amount of gas. The recipient can write to the log but that's about it. TheDAO used .value() which forwards all the available gas.

If you do use .value(), then you can do it safely by doing it only once per method, as the very last step, and only using it in top-level methods. Then any sort of reentrant callback will find any required state changes already done. E.g. subtract from the user's balance, send the funds, and if the send fails then throw. The recipient can call back but the balance is already decremented. Using a mutex is another option. I've tested all this and it works.

There are a lot of reasons Ethereum is designed this way. The most common reason for a contract to run code when receiving funds is to prevent users from accidentally losing their money. E.g. in any contract that holds ether and maintains a ledger with balances for multiple users, if anyone sends ether to the contract address, they'll lose it, unless the contract either throws an exception or automatically adds to the user's balance on its ledger.

User addresses and contract addresses are interchangeable, because it lets you do things like use a multisig timelocked vault to receive funds and anything can send to it just as if it were a regular user account.

All that said, the devs are working on improvements too.

Re: Ethereum is Doomed

#24

Post by JorgeGT »

IanCal wrote: post #11
mmanfrin wrote: post #7

Earlier quoted context omitted.

Banks aren't legally exploitable .

Was the hack legal? A system letting you in if you poke it just right doesn't mean you are legally allowed in. I fail to see how a bug in banking software would be any different to the bug in the DAO.

From The DAO Terms:

The terms of The DAO Creation are set forth in the smart contract code existing on the Ethereum blockchain at 0xbb9bc244d798123fde783fcc1c72d3bb8c189413. Nothing in this explanation of terms or in any other document or communication may modify or add any additional obligations or guarantees beyond those set forth in The DAO’s code. Any and all explanatory terms or descriptions are merely offered for educational purposes and do not supercede or modify the express terms of The DAO’s code set forth on the blockchain; to the extent you believe there to be any conflict or discrepancy between the descriptions offered here and the functionality of The DAO’s code at 0xbb9bc244d798123fde783fcc1c72d3bb8c189413, The DAO’s code controls and sets forth all terms of The DAO Creation.

Basically, the code is the only authentic version of the contract. The attacker entered this contract and used its functionality as was programmed in the blockchain, he didn't modify a bit of the code. So it seems pretty legal.

Re: Ethereum is Doomed

#25

Post by DennisP »

darawk wrote: post #10
mmanfrin wrote: post #8

Having a little bit of trouble parsing how the attack worked -- so when a transfer happens, the destination account gets to run a command; they then ran a command that called the source's send-ether command, which ran because it was still in 'we owe destination account money' mode because the full initial contract had not concluded? Then at some point it terminates itself before emptying the source account (and there…

My understanding is that it looks essentially like this: send(theEther, childDao) deduct(theEther, tokenHolder) But that you can get it to overflow the stack in between the two so that the send completes but the deduction no longer happens.

If you overflow the stack it throws and rolls back (which is another attack in certain circumstances). What killed TheDAO is basically that childDao called back the sender method, which sends again without having deducted yet.

Do the deduct before the send, and the whole problem goes away.

Re: Ethereum is Doomed

#26

Post by aakilfernandes »

dkarapetyan wrote: post #19

I didn't know the language was turing complete. Isn't this computing 101? If you want a secure thing then you must be able to reason about it statically. Making things turing complete means any non-trivial property of program correctness can not have a generic solution and so you've just opened yourself up to a world of hurt.

The whole point of Ethereum is turing completeness. Ethereum without Turing completeness already exists and its called Bitcoin.

While this implementation of The Dao has failed, Ethereum is the only blockchain where implementing The Dao is possible.

Re: Ethereum is Doomed

#27

Post by whiddershins »

altoz wrote: post #12
3pt14159 wrote: post #9

Ethereum isn't doomed. I don't think it will ever have as much backing as Bitcoin because of institutional buy-in; but the world needs programmable smart contracts. Some rich soon-to-be-dead billionaire tech nerds want to be able to do something every year without worrying about a judge taking that away from them. Individual will is what cryptocurrencies are about. Bitcoin in terms of international payments and store…

RTFA. The idea of smart contracts isn't dead, but Ethereum looks like a terrible platform for it, given that it's very hard to audit the smart contracts on it.

I agree with your sentiment but downvoting because the guidelines specifically ask that you not say things that imply a commenter hasn't read the article.

Re: Ethereum is Doomed

#28

Post by amaks »

DennisP wrote: post #22

I have actually tested this attack technique (using my own contracts on a local test chain), and I've been in discussions with some Solidity developers and the guy who first published the attack. The situation is not as bad as this article claims. For starters, you can use address.send(x) instead of address.call.value(x)(). All computations on Ethereum have to be funded with "gas" (transaction fees), and send() only…

> All computations on Ethereum have to be funded with "gas" (transaction fees)

But that's what was wrong with the exploited DAO code - it didn't use gas. The point of the article is that it's very hard or impossible to verify the correctness of the smart contracts.

Re: Ethereum is Doomed

#30

Post by aakilfernandes »

amaks wrote: post #28
DennisP wrote: post #22

I have actually tested this attack technique (using my own contracts on a local test chain), and I've been in discussions with some Solidity developers and the guy who first published the attack. The situation is not as bad as this article claims. For starters, you can use address.send(x) instead of address.call.value(x)(). All computations on Ethereum have to be funded with "gas" (transaction fees), and send() only…

> All computations on Ethereum have to be funded with "gas" (transaction fees) But that's what was wrong with the exploited DAO code - it didn't use gas. The point of the article is that it's very hard or impossible to verify the correctness of the smart contracts.

> it didn't use gas

this is incorrect

Post reply on HN