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

121–130 of 180 posts

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

#121

Post by homogeneous »

chriswarbo wrote: post #118
homogeneous wrote: post #100

Earlier quoted context omitted.

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

> netflix debits my credit card every month, why would I use a cryptocurrency solution instead? Presumably you trust Netflix enough to give them your credit card details, and you trust your credit card company enough to pay them when they present you with a list of transactions they claim you made. That's fine for such big, entrenched players; presumably you wouldn't put as much trust in some unknown, anonymous onlin…

I suppose it depends on the product, the merchant, and the cost of the subscription. Certainly, it'd be foolish to give out a credit card to a merchant I do not entirely trust, however, it seems more risky to move cryptocurrency into a contract with a merchant I do not entirely trust (and a contract I probably don't fully understand, even if I take the time to read the code) since a credit card can protect me from fraudulent and erroneous charges that are forfeited if I opt for cryptocurrency.

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

#122

Post by homogeneous »

jsprogrammer wrote: post #119
homogeneous wrote: post #100

Earlier quoted context omitted.

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

>Can you go into specifics here? I'm not really understanding. It sounds like a security deposit, of a type. For example, I had to leave one of my shoes at the front counter of a store that hosted a small gaming LAN in the back.

If that's the case then I'm confused as to where the cryptocurrency comes in. A security deposit works just as well with fiat cash as it does with cryptocurrency and in your example there is no money exchanged at all.

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

#123

Post by jcoffland »

bradenb wrote: post #101
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...

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.

That's what the test net is for.

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

#124

Post by vectorpush »

CephalopodMD wrote: post #113
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!

Okay, so let me preface this with a warning. This will be an imprecise analogy! This is just meant to be an aid to understanding. Obviously, there are nuances of the DAO that don't fit perfectly into this model. Imagine a publicly owned company. It has a CEO, COO, CFO, board, and shareholders. Most decisions are made by the chief officers of the company, and these officers are kept in check by the board of directors.…

Let's say the members of the DAO voted to make an investment. How does the subject of the investment receive the funds and what mechanism ensures that the DAO actually receives any returns to which it may be entitled to based on the terms of the investment?

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

#125

Post by leesalminen »

pjc50 wrote: post #9
Animats wrote: post #2

So one contract can call a function in another contract, in the middle of their transaction: if (_recipient.call.value(_amount)()) { // vulnerable That's inherently a scary feature, and it was exploited. Etherium's "Solidity" suffers from the desire to have it be a general-purpose computer. It should have been if-then rules, or a logic tree, or a decision logic table - a finite representation of business logic subjec…

The problem with a redesign is that the only way you're going to get a reliable design involves a lot of formal verification, which is a rare skill and time-consuming to perform. Whereas the cryptocurrency space is a startup environment: there's huge pressure to launch first so that you can get the money that people are begging to throw into untested speculative finance systems. And the refusal to countenance human c…

> there's huge pressure to launch first so that you can get the money that people are begging to throw into untested speculative finance systems.

I got a good chuckle out of that one.

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

#126

Post by Dzugaru »

jerf wrote: post #58
mbrock wrote: post #12

I don't understand "you can't assume anything about the state of the contract." Surely the contract's state is only modified by the contract's own code, which means you can assume that the state is not altered arbitrarily but only according to the rules set up by the contract. Yes, you need to be careful about external calls that make altering calls to you.

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 an expert in programming languages design and I've read about Etherium just a couple of days ago. But when I saw that "Solidity is like JavaScript and Python" - I was like "What? I'd pick some functional programming language for that!".

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

#127

Post by gomox »

homogeneous wrote: post #100
gomox wrote: post #90

Earlier quoted context omitted.

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…

For example, a smart contract might withhold $100 from an account, and grant whoever owns the private key to that account access to open a lock. When the user is done using the resource (say, a shared car or apartment or locker), he can request his money back (minus a fee for using the resource) which would render him unable to use the resource anymore (i.e. open the lock).

Basically the equivalent of a credit card collateral on a rental, minus the credit card company.

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

#128

Post by gomox »

homogeneous wrote: post #121
chriswarbo wrote: post #118

Earlier quoted context omitted.

> netflix debits my credit card every month, why would I use a cryptocurrency solution instead? Presumably you trust Netflix enough to give them your credit card details, and you trust your credit card company enough to pay them when they present you with a list of transactions they claim you made. That's fine for such big, entrenched players; presumably you wouldn't put as much trust in some unknown, anonymous onlin…

I suppose it depends on the product, the merchant, and the cost of the subscription. Certainly, it'd be foolish to give out a credit card to a merchant I do not entirely trust, however, it seems more risky to move cryptocurrency into a contract with a merchant I do not entirely trust (and a contract I probably don't fully understand, even if I take the time to read the code) since a credit card can protect me from fr…

This might sound funny in light of recent events, but the idea is that a smart contract requires no trust in a 3rd party as the rules are specified within the contract and the Ethereum platform guarantees proper execution of the contract.

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

#129

Post by jsprogrammer »

homogeneous wrote: post #122
jsprogrammer wrote: post #119

Earlier quoted context omitted.

>Can you go into specifics here? I'm not really understanding. It sounds like a security deposit, of a type. For example, I had to leave one of my shoes at the front counter of a store that hosted a small gaming LAN in the back.

If that's the case then I'm confused as to where the cryptocurrency comes in. A security deposit works just as well with fiat cash as it does with cryptocurrency and in your example there is no money exchanged at all.

Money is only a token of value.

What if you were unable to accept cash (for example, you are on vacation)?

Wouldn't it be useful to make a deposit on a car, right before you use it?

What hasn't been explained here, are what guarantees the depositor receives.

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

#130

Post by sandworm101 »

DennisP wrote: post #106
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...

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

Five pages? I thought these things were meant to be shorter than plain-English contracts. I draft and review contracts daily and five pages is long for basic things (employment, NDAs, IP transfer etc).
Post reply on HN