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

Chasing the DAO Attacker’s Wake – A second exploit

pdaian.com

Post reply on HN
Print view View original

101–110 of 180 posts

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

#101

Post by bradenb »

cheeze wrote: post #80
DennisP wrote: post #30

As the article briefly suggests, this problem can be completely avoided if every method has no more than one external call and always puts it last. I'm messing around with contracts to do about a dozen different things, and it turns out to be easy to meet this restriction, as long as I'm willing to design the UI accordingly. (E.g. don't send money to lots of users in one step, just update their balances and make them…

It seems like there are quite a few pitfalls to avoid just in writing these contracts, and they aren't obvious things in many cases. This seems incredibly dangerous , given what is at stake when a bug is included in a contract. Is there any form of auditing that contracts can go through to not have these pitfalls? I wonder how many of them are still undiscovered...

It would be nice if you could dry-run each execution of the contract and verify it passes a series of tests. It seems to me that regardless of how these contracts are written, you should be able to verify the behavior.

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

#102

Post by jarsin »

cheeze wrote: post #80
DennisP wrote: post #30

As the article briefly suggests, this problem can be completely avoided if every method has no more than one external call and always puts it last. I'm messing around with contracts to do about a dozen different things, and it turns out to be easy to meet this restriction, as long as I'm willing to design the UI accordingly. (E.g. don't send money to lots of users in one step, just update their balances and make them…

It seems like there are quite a few pitfalls to avoid just in writing these contracts, and they aren't obvious things in many cases. This seems incredibly dangerous , given what is at stake when a bug is included in a contract. Is there any form of auditing that contracts can go through to not have these pitfalls? I wonder how many of them are still undiscovered...

> I wonder how many of them are still undiscovered...

Yup. I find it interesting how everyone only thinks it's these couple of issues. I wouldn't do anything beyond experiments with it at this point.

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

#103

Post by jsprogrammer »

cheeze wrote: post #80
DennisP wrote: post #30

As the article briefly suggests, this problem can be completely avoided if every method has no more than one external call and always puts it last. I'm messing around with contracts to do about a dozen different things, and it turns out to be easy to meet this restriction, as long as I'm willing to design the UI accordingly. (E.g. don't send money to lots of users in one step, just update their balances and make them…

It seems like there are quite a few pitfalls to avoid just in writing these contracts, and they aren't obvious things in many cases. This seems incredibly dangerous , given what is at stake when a bug is included in a contract. Is there any form of auditing that contracts can go through to not have these pitfalls? I wonder how many of them are still undiscovered...

I have asked if there is a contract simulator and I got no response.

Even though the coding experience seems pretty poor, it doesn't appear to be particularly dangerous as bad contracts can just be rolled back.

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

#105

Post by bradscarleton »

jsprogrammer wrote: post #103
cheeze wrote: post #80

Earlier quoted context omitted.

It seems like there are quite a few pitfalls to avoid just in writing these contracts, and they aren't obvious things in many cases. This seems incredibly dangerous , given what is at stake when a bug is included in a contract. Is there any form of auditing that contracts can go through to not have these pitfalls? I wonder how many of them are still undiscovered...

I have asked if there is a contract simulator and I got no response. Even though the coding experience seems pretty poor, it doesn't appear to be particularly dangerous as bad contracts can just be rolled back.

There is no contract simulator AFAIK, but you can deploy contracts to a test network or your own private test network. The benefit there being it's cheaper from a Gas perspective, and you don't pollute the main network.

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

#106

Post by DennisP »

cheeze wrote: post #80
DennisP wrote: post #30

As the article briefly suggests, this problem can be completely avoided if every method has no more than one external call and always puts it last. I'm messing around with contracts to do about a dozen different things, and it turns out to be easy to meet this restriction, as long as I'm willing to design the UI accordingly. (E.g. don't send money to lots of users in one step, just update their balances and make them…

It seems like there are quite a few pitfalls to avoid just in writing these contracts, and they aren't obvious things in many cases. This seems incredibly dangerous , given what is at stake when a bug is included in a contract. Is there any form of auditing that contracts can go through to not have these pitfalls? I wonder how many of them are still undiscovered...

There's both an active developer community willing to help for free, and professional auditors you can pay. There are also people talking about a NASA-style bugs/best practices database at some central location.

People are realizing that this needs to be developed like safety-critical software, not like fast-moving startup websites. But I would say it's not as scary as, say, developing software for aerospace or medical applications.

And what really helps is that you can do a lot with very little code. I think all of my contracts are under five pages. I don't think we're ready for big complicated contracts, but there's a lot we can do with simple little contracts.

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

#107

Post by homogeneous »

DennisP wrote: post #99
homogeneous wrote: post #79

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 entit…

> anti-theft vaulting

Can you go into more details about this?

> blind auctions

Or this? How does the contract ensure that the winner of the auction receives what they have purchased?

> crowdfunding

In what respects beyond simply collecting funds? How does the contract judge that the terms of the funding are adhered to or ensure that the crowdfunders receive whatever it is they are entitled to as funders?

> person-to-person gambling

Any examples? In my post I gave the example of betting on a sports game but this requires a trusted 3rd party to officiate the outcome of the game.

> currencies, exchanges

These are vague descriptions and these things have already been done by bitcoin.

I'm not trying to nitpick, but I'm looking for specific practical examples that demonstrates the potential utility of ethereum.

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

#108

Post by qbrass »

afrenchcoder wrote: post #54
homakov wrote: post #41

Earlier quoted context omitted.

This is unfair to banish a company for not having enough "security experience". It could happen to anyone (i mean making such a design mistake), plus they afaik had some external audits. "Aha, no security background!" is wrong.

How is it unfair ? We're speaking about crypto-currency here. "crypto" is so damn hard than even experts make mistakes indesign or implementation, and very often in both. And when they don't, it still doesn't mean it's secure... And now it's ok to have no expert and to use the result to manage _currency_ ?!? It might sound weird, but yeah, I'd like to have knowledgeable people to deal with my money

People complained about the same criticism of MtGox back in the day.

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

#109

Post by DennisP »

jsprogrammer wrote: post #103
cheeze wrote: post #80

Earlier quoted context omitted.

It seems like there are quite a few pitfalls to avoid just in writing these contracts, and they aren't obvious things in many cases. This seems incredibly dangerous , given what is at stake when a bug is included in a contract. Is there any form of auditing that contracts can go through to not have these pitfalls? I wonder how many of them are still undiscovered...

I have asked if there is a contract simulator and I got no response. Even though the coding experience seems pretty poor, it doesn't appear to be particularly dangerous as bad contracts can just be rolled back.

Aside from running on a test chain there's the Mix IDE, which basically does have a simulator, and an actual debugger. So far it's kinda unstable and tends to crash, but I like it a lot anyway.

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

#110

Post by crispyambulance »

mtgx wrote: post #32
HoopleHead wrote: post #27

Every article I see on etherium mentions the DAO. Not one of them explains what it means. Gotta love unexplained acronyms!

It means "Decentralized Autonomous Organization". It's usually used as a common term ("I'm creating a DAO"), but these guys called theirs "The DAO". This attacker exploited "The DAO".

Ok, but you realize that merely listing the words in the acronym does nothing to explain what it actually is. The whole ethereum "ecosystem" is a radical and new construct that very few people are familiar with.

Given that, I would even say that the name "Decentralized Autonomous Organization" is a deliberate, almost satirical, obfuscation.

Post reply on HN