Topic: Technical Analysis of DAO / ETH problem. Is Augur next.. ? (Read 530 times)

There were a number of minor issues although they were not so much security but things like an AT being able to be "stuck" or the like (there may still be some minor issues waiting to be found of course but we have found no major issue in around 2 years of live operations so I'd be very surprised if one will appear with the current implementation).

Agreed it needs more people trying to attack it (unfortunately we don't have much to spend on promotion) - an upcoming "challenge" to steal from the Crowdfund AT is going to be issued so hopefully we'll have some hackers try to steal (and hopefully they'll fail as there won't be any "hard forks" to change the outcome).

AT!.. the original..

I'm curious - have any such security issues / hacks been found in AT since you deployed it ?

Any ways in which you could use the code that you hadn't originally intended ? Even minor ones ?

( If I'm honest I feel that ETH has probably been put under more scrutiny.. because Burst and Quora are just not as large, not due to AT specifically. )

The approach taken by AT (the smart contract system used by Qora and Burst) does not suffer from such pitfalls as one contract cannot "call" another but instead can only send funds or a message in the same manner as any other "account" can.

This AT design approach was done on purpose after I had read Vitalik's paper (as I saw potential "red flags").

Fascinating article - although maybe a little 'Heavy on the Magic' for non-techies..

http://eprint.iacr.org/2016/633

Basically it runs a program that checks current Ethereum contracts and sees whether they are susceptible to various forms of attack - like the DAO was.

'..Among 19,366 existing Ethereum contracts, Oyente flags 8,519 of them as vulnerable.'

Just under half of them.

..

Hmm..

Definitely a step in the right direction.

Much can be learned from these first forays into the 'Smart Contract' world.

But the bottom line is - flick a coin to see if your ETH contract is 'safe'.

It's much harder to do than anyone thought..

It's not just 1 'Attacker'. There are many MANY people who could attempt any number of clever little tricks now.

Pandora's box has been opened. The secret's out. (Funnily enough - it always was, just that nobody noticed before..)

You're going to have to be VERY careful when writing ETH contracts (in it's current form).

Better than the entire DAO / ETH devs put together.. (impossible?)

Then there is a bigger issue at hand here. It's the attacker. He is still at large and after the hard fork he could make another attack when he sees the timing is right. He will also wait for a target good enough so that the impact of an attack will be newsworthy.

If what you say is really true, then the attacker has Ethereum under his thumb. Will Vitalik keep rolling back the transaction history?

Most with valuable technical insight have long left these wastes m8, these are the shilling grounds now.

But maybe someone can riddle me this: when investing, you try to be ahead of the crowd. You want to have insights before others have them to be ahead of the competition. From where then comes this idea that letting a majority of unknowns decide for you what to invest in is a sound plan?

If you are afraid for your augur REP value, you can sell them OTC 

This post is to discuss the technical reasons why the DAO attack was possible, and if that 'flaw' is 'systemic' in ETH. Let's not just slag each other off please..

I held ETH, no more I'm afraid (The FORK  ), and I hold some Augur REP (which you can't dump yet).

The issue that allowed the DAO 'attack' is VERY low level.

Basically, the way the ETH EVM functions, when you send ETH to an address it executes some code. The 'contract' for that address. The problem lies with the fact that THAT contract can call back to the original contract, recursively, and screw with the internal states.

You may think - OK, now you know this, just write the smart contract so that it doesn't matter. Hmm.. if only it were that easy.

The DAO/ETH devs tried to fix this issue in the DAO 1.1, after the flaw was found in DAO 1.0.  They couldn't fix it. The problem is so 'pernicious' that EVEN VITALK HIMSELF could not find a solution to it (I can assure you he was involved in trying to fix it). And whatever you may think of him, no-one knows more about ETH.

So then you think, OK - Hard fork that 'ability' away. No more problem. Hmmm.. if only it were that simple.

This is really very VERY low level in the ETH EVM. The whole point is that you can call functions in other contracts. You cannot simply remove this, without fundamentally changing everything..

This does not bode well.

How can Augur ensure that it is not riddled with similar issues - from a programmatic level ? ( It can't is the honest answer )

How could this be fixed - 'technically' ? (If Hard Forks are the order of the day - at least make them count, and fix this issue)

..

For instance - What if you said that you cannot call functions in other contracts ? And that the contracts running on ETH have to be completely self-contained ?

Would that fix it, and would ETH still work if you did do it ?

ps - we may be talking about ETH's successor here.. What to do differently for version 2.0 (from a technical point of view)..