On today's episode of Let's Talk Bitcoin, Adam gives a simplified explanation of TheDAO ether drain exploit, explores the idea that the attacker might not be doing anything wrong. TheDAO's Griff Green joins The Filter to discuss what's happened and what's next.

Content by Adam, The Filter Show and Griff Green.

Music by Jared Rubens and Editing by Adam B. Levine.

Transcript of Simplified Explanation:

So what happened at TheDAO, what was the mistake that turned an even bigger launch event than Ethereum's wildly successful crowdsale into a state of halt and catch fire - Without getting into the technical details, the problem seems to have been as simple as getting the order of actions wrong when supporters of TheDAO decide to go their separate ways. Like the mighty Amoeba, TheDAO is designed to let the organization split into smaller more specialized or at least divergent groups, basically at will. When allowing someone with DAO tokens to take their portion of the Ether owned by the DAO and create their own smaller version that they and potentially their supporters or friends can control as they wish, accepting the increased personal risk, greater control and lesser pool of assets that comes from breaking away from the main group.

The splitting process works in three sequential steps.

Step 1 - Verify that the user owns the tokens they wish to split

Step 2 - Transfer ether from theDAO to the new split equal to the amount of tokens the user is splitting

Step 3 - Burn the tokens the user is splitting

The process itself is sound, the order in which the actions are performed proved it's undoing. This is simplified but let's imagine I'm going to split 1 ETHEREUM away from the Dao. Step 1 - The system validates that I actually have enough tokens to convert. I do, so no problem there. Then Step 2, theDAO sends ether from the main pool to the group I control. At this moment, after step 2 has completed but before step 3 has completed, I start the split process over which takes me back to step 1. Since step 3 never happened, the tokens I redeemed were never burned which means that Step 1 finds that i do in fact own enough tokens to redeem 1 ETHEREUM, which takes us to step 2 where my reward is sent a second time. Before step 3 has burned my redeemed tokens, I start the process over and you can see the problem.

If the process involved burning the tokens first and then sent the split on proof of that burn, this attack would be impossible. This is not lazy or bad design, it's early design. Nobody knows what the right way to build smart contracts and while this weakness might have gone unexploited, Smart Contracts are the ultimate pinatas - The bigger the value locked up in one, the greater the incentive to bust it open to get at the good stuff inside.