[Cryptography] Code is Cruel -- The DAO

[ianG]

On 23/06/2016 18:14 pm, Ray Dillinger wrote:
>
>
> On 06/21/2016 07:47 PM, Sidney Markowitz wrote:
>> A more detailed technical look at the exploit is here:
>>
>> http://hackingdistributed.com/2016/06/18/analysis-of-the-dao-exploit/
>
>> What that analysis ignores is that it was possible to have a function that
>> manipulates the balances which in the middle of that manipulation can call
>> another function that manipulates the balances. Isn't a fundamental
>> requirement of a system like this that it be possible to grab and release
>> locks on shared resources?
>
> Yes.  Among other things, locking is one of the points that Hal Abelson
> cited when he and Satoshi were deciding which opcodes should be allowed
> in the Bitcoin scripting language.  IIRC, Satoshi wanted to enable more
> programmability but Hal demonstrated some ways that recursion and/or
> looping operators could be used to attack the system - or enable legit-
> looking scripts that could be attacked later, as apparently happened
> with ETH.  In the end they wound up removing all the potentially
> backward-branching control structures.


In more accounting terms, the typical defence against this is to 
implement double entry bookkeeping, so that the value cannot be 
"created" out of thin air, it must come from somewhere, and be shown to 
have existed as a deliberate act.  Typically a system that profers an 
account style (as typical in Ethereum) should have a double entry 
backend behind the scenes.

In more CS terms, any form of transactional processing likely needs some 
form of locking, somewhere.

Another issue is an unwritten law of financial cryptography: you always 
debit the sender's account first, then credit the receiver's account. 
So if there is a division attack, you can destroy money not create it.

Finally, the dichotimy between code-is-cruel and consensus-is-community 
is now revealed.  The solution is to set the contract up front and to 
state what the conditions of a hard fork are as a dispute.


> IOW, every "later" instruction executed in a Bitcoin script is also a
> "subsequent" instruction in the serialization of that script; control
> can jump-over sections but can't jump backward to execute anything
> more than once, nor call anything that might be called from more than
> one place.  ETH didn't have the same structural constraints.


Interesting!  Yes, Ethereum deliberately goes against Hal & Satoshi's 
conservatism and calls for the full turing experience.

iang