Live data from Hacker News

Chasing the DAO Attacker’s Wake – A second exploit

pdaian.com

91–100 of 180 posts

Re: Chasing the DAO Attacker’s Wake – A second exploit

#91
post #69

"This impacts all contracts on Ethereum, not just the DAO. This is an issue with Ethereum’s JavaScript-like programming language (Solidity)." No it doesn't, no it's not. It affects contracts that use this functionality with arbitrary untrusted contracts (which is a bad idea), and most contracts just don't use this functionality at all.

Yeah, all this shadenfreude from people who (wrongly) predicted ethereum would never work, and who want to feel vindicated, is predictable but frustrating.

Not at all.

When I discovered ethereum a couple of years ago I thought it was a good idea. Partly because I was turning similar ideas in my head at the time.

But what I read now sounds like amateurs designed & implemented it. Sorry.

Re: Chasing the DAO Attacker’s Wake – A second exploit

#92
post #70

Earlier quoted context omitted.

It's a code mistake by who did the DAO code. (DAO != Ethereum) It's more the equivalent of using eval in your nodejs code to evaluate some parameter received from a user. It's a stupid code mistake, but you wouldn't say the internet is a bad idea because some website got hacked.

I know that DAO != Ethereum. Letting programs call arbitrary function on each other is a fundamental design-flaw in every concurrent system.

I dont think I would consider Ethereum a "concurrent system" in the same sense.

This functionality is there because it allows contracts to interact with each other. This allows a million different type of applications, e.g you could create a crowdfund using a gold token hold by a multisgn.

The contracts are usually trusted and their addresses set from beginning, so this is never an issue (unlike what the article implies). The DAO however allowed an arbitrary address to be used as the contract to talk to. This is flexible because it allows contracts to be update themselves, or update who they talk to, but if the contract is malicious and there is a reentrancy, then that's the issue, but again, it's the contracts fault, not the whole platform.

Re: Chasing the DAO Attacker’s Wake – A second exploit

#93

Earlier quoted context omitted.

The Ethereum Foundation had nothing to do with the creation of the DAO.

That's like saying The Pirate Bay has nothing to do with piracy.

It's like saying the WEB and HTTP protocol have nothing do with a SQL injection on some website.

Re: Chasing the DAO Attacker’s Wake – A second exploit

#94
post #67
post #44

Earlier quoted context omitted.

It is absolutely fair to banish a company for security credentials if it's dangling $150 million out in the open air.

> What are you talking about? Please don't be uncivil. It's damaging to collegial conversation, and it's against the rules ( https://news.ycombinator.com/newsguidelines.html ). Please edit such stuff out of your comments here.

edited.

Re: Chasing the DAO Attacker’s Wake – A second exploit

#95
post #76
post #58

Earlier quoted context omitted.

The problem pointed out in this article isn't that it is impossible to write correct contracts. The problem is that it means that it is superhumanly difficult to write correct contracts, using the current feature set and infrastructure. This is especially true in what is theoretically an actively hostile environment, which the DAO hack proves is also actually an actively hostile environment. It is theoretically possi…

I'm not sure that it is super humanly difficult. It seems likely that programming patterns, such as not using I trusted external sends at all, will emerge that any contract will need to abide by to be trusted. If what you say is true then Ethereum is DOA, which seems unlikely to me. (I don't own any ETH.) I totally agree that it would be great to have more language based security and I've started dabbling with some s…

And there are still people running around who think that writing code based on threads and semaphores isn't superhumanly difficult and people just need to Try Harder (TM).

At least when they're wrong, they usually don't lose millions of dollars. (But only... usually.)

I think some people are mentally modeling Ethereum as a sort of hobby thing in their head when they say things like that. I mean, who cares if my hobby static-rendering blog platform has a few bugs in it, right? But Ethereum aspires to be the foundation of an economy. Real foundations of economies have billions of dollars worth of effort poured into them. While a small set of particularly brilliant people may produce something that can run in this environment, Ethereum isn't what it would look like if they did.

I also think that people don't realize that the usual fate of a cryptocurrency is to die. Bitcoin isn't the first cryptocurrency by a long shot. Cryptocurrencies in general are not strong, robust things. I think something like Ethereum is quite likely, but there's no particular reason to believe we aren't three or four more major fully independent stabs at the problem away from a stable solution. Ethereum makes Bitcoin look like a homework problem in comparison; it would almost be beyond belief that we'd get it right the first time.

Re: Chasing the DAO Attacker’s Wake – A second exploit

#96

With all this fuss over ethereum security flaws, can someone explain to me the practical use case for these smart contracts? I just don't understand where the benefit comes in. It seems like any type of contract that would be useful requires a human to qualify the meaning of the terms since these contracts cannot autonomously measure the state of the world. Even something as trivial as betting on sports requires defe…

I think the basic idea is that with Bitcoin, you sort of have to hack at it to achieve any unintended functionality. These things can and do exist in the Bitcoin world, but when you get down to it, Bitcoin is meant to be a currency; anything built on top of that is just a hack that happens to work. Ethereum and its smart contracts, on the other hand, are structured to handle these sorts of extensions by design. There's nothing that Ethereum can do that Bitcoin absolutely can't be used for in some hacky way AFAIK, but it's generally much easier to do complex things with Ethereum that aren't strictly transactions of currency.

Re: Chasing the DAO Attacker’s Wake – A second exploit

#97
post #69

Earlier quoted context omitted.

Yeah, all this shadenfreude from people who (wrongly) predicted ethereum would never work, and who want to feel vindicated, is predictable but frustrating.

Honestly, I was in awe by r/bitcoin's reaction to this whole DAO debacle. I thought that the whole Mt Gox "incident" has taught them some empathy to people losing money but I was very wrong.

Empathy? Bitcoiners? A large chunk of them are anarcho-capitalists who measure a person's right to survive by how much money they can make, and most of the rest are in it to make themselves rich. There's a fair few who are mostly in it just because it's cool tech, but they avoid Bitcoin forums now due to the former two groups.

Note that this covers most other cryptocurrencies as well.

Re: Chasing the DAO Attacker’s Wake – A second exploit

#98
post #70

Earlier quoted context omitted.

I know that DAO != Ethereum. Letting programs call arbitrary function on each other is a fundamental design-flaw in every concurrent system.

I dont think I would consider Ethereum a "concurrent system" in the same sense. This functionality is there because it allows contracts to interact with each other. This allows a million different type of applications, e.g you could create a crowdfund using a gold token hold by a multisgn. The contracts are usually trusted and their addresses set from beginning, so this is never an issue (unlike what the article impl…

> This is flexible because it allows contracts to be update themselves, or update who they talk to, but if the contract is malicious and there is a reentrancy, then that's the issue, but again, it's the contracts fault, not the whole platform.

The platform is being shown to be superhumanly difficult to write secure contracts for. That's a platform issue.

Re: Chasing the DAO Attacker’s Wake – A second exploit

#99

With all this fuss over ethereum security flaws, can someone explain to me the practical use case for these smart contracts? I just don't understand where the benefit comes in. It seems like any type of contract that would be useful requires a human to qualify the meaning of the terms since these contracts cannot autonomously measure the state of the world. Even something as trivial as betting on sports requires defe…

Contracts I'm working on include variants of anti-theft vaulting, blind auctions, crowdfunding, person-to-person gambling, currencies, exchanges, and a simple implementation of Bitcoin's Lightning. None of them require external data.

For those contracts that do, at least you're reducing the third-party trust to "provide accurate data" instead of "hold my funds without stealing them." To reduce trust in a single entity you can use various schemes that allow multiple independent parties to provide the data.

Re: Chasing the DAO Attacker’s Wake – A second exploit

#100
post #90

With all this fuss over ethereum security flaws, can someone explain to me the practical use case for these smart contracts? I just don't understand where the benefit comes in. It seems like any type of contract that would be useful requires a human to qualify the meaning of the terms since these contracts cannot autonomously measure the state of the world. Even something as trivial as betting on sports requires defe…

Some simple use cases: - a multisignature wallet, that requires more than one person to sign off on a transaction before it can happen. - payment schedules or any kind of transaction that does not function exactly like a one time, full size payment (payments, debt, etc). - more ambitious ideas, like the Slock.it ones, involve smart locks that hold funds while granting use to a resource, and only return them after acc…

> a multisignature wallet, that requires more than one person to sign off on a transaction before it can happen.

This is possible with bitcoin isn't it? What does the added complexity of ethereum bring to the table?

> payment schedules or any kind of transaction that does not function exactly like a one time, full size payment

This also seems possible with bitcoin, but it's also a problem that has already been solved better by the traditional payment system (e.g. netflix debits my credit card every month, why would I use a cryptocurrency solution instead?)

> more ambitious ideas, like the Slock.it ones, involve smart locks that hold funds while granting use to a resource, and only return them after access has been revoked

Can you go into specifics here? I'm not really understanding. It sounds like you're describing a kind of autonomous collateral system, but I can't really think of any practical examples where this would be useful (without bringing human judgement into the mix).

Post reply on HN