Chasing the DAO Attacker’s Wake – A second exploit
1–10 of 180 posts
Re: Chasing the DAO Attacker’s Wake – A second exploit
#2So one contract can call a function in another contract, in the middle of their transaction:
if (_recipient.call.value(_amount)()) { // vulnerable
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 subject to exhaustive case analysis. Contract executions should have been atomic transactions - either everything commits, or everything gets rolled back. Stack overflow and running-out-of-gas terminations are inherently trouble.
Etherium needs to go back into the shop for a redesign. At least we found out early that this isn't going to work.
Re: Chasing the DAO Attacker’s Wake – A second exploit
#3So 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…
> At least we found out early that this isn't going to work.
$US150M later isn't early
Re: Chasing the DAO Attacker’s Wake – A second exploit
#4So 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…
> At least we found out early that this isn't going to work. $US150M later isn't early
Maybe that just means the $150M was early too
Re: Chasing the DAO Attacker’s Wake – A second exploit
#5So 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…
> At least we found out early that this isn't going to work. $US150M later isn't early
That's called a bug bounty.
Re: Chasing the DAO Attacker’s Wake – A second exploit
#6Re: Chasing the DAO Attacker’s Wake – A second exploit
#7I'd be interested in knowing how this has been dealt with (or not) before. Was the problem recognized when designing E?
Re: Chasing the DAO Attacker’s Wake – A second exploit
#8Earlier quoted context omitted.
> At least we found out early that this isn't going to work. $US150M later isn't early
That's called a bug bounty.
I came up with "self-distributing bug bounty piñata" in the last DAO-failure discussion https://news.ycombinator.com/item?id=11921677
Re: Chasing the DAO Attacker’s Wake – A second exploit
#9So 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 control or any of the normal forms of accountability - these things are designed out of the system deliberately - means that there's going to be a long, slow, expensive period of designing them back in.
Re: Chasing the DAO Attacker’s Wake – A second exploit
#10Earlier quoted context omitted.
That's called a bug bounty.
I came up with "self-distributing bug bounty piñata" in the last DAO-failure discussion https://news.ycombinator.com/item?id=11921677
Hehe, that's even better. But it is the essence of the matter. If you put $100M in a bucket you've just incentivized the worlds bad guys to audit your production in order to figure out how to open the bucket to get to the loot.
And this goes for all of commerce, which is an important realization: security is not an all-or-nothing proposition, it is an economic affair. Whatever you wish to secure, you can expect to expend a reasonably constant fraction of that on the act of securing it. So if you wish to secure $100M you will have to do a much better job than if you wish to secure $10M or $1M, just like you're going to spend more money on the lock for a $1k bike than a $25 junker.
When DOA ended up being over-subscribed they should have immediately yanked the emergency brake because whatever plans they had would end up being moot by virtue of storing more money in the bucket than they originally planned.
Their security measures would by definition not have been up to the task because they had planned to secure a much smaller amount. Either that or they were ridiculously over-confident.