[Cryptography] Code is Cruel -- The DAO

[Ray Dillinger]

On 07/24/2016 01:16 PM, ianG wrote:

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

Yah.  Bitcoin doesn't have accounts though, just transactions.
The basic entity that stores Bitcoin on the block chain is a
"txOut" -- literally, just one of the outputs of a previous
transaction.

What is actually stored on the block chain are transactions that
say something like, "this set of existing txOuts was used in a
transaction by one or more people who, between them, demonstrated
knowledge of the keys and/or scripts needed to spend all of them.
The transaction creates a set of new txOuts each of which will
probably be spent in some subsequent transaction sometime."

Transactions are "atomic" in the sense that they are either
recorded in a published block that is part of the current best
block chain, or they are not.  You can't do just part of a
transaction.  It is DONE (old TxOuts destroyed, new ones created)
in any version of the block chain that contains it.

Locking is something Bitcoin would have had to deal with if
there'd been any kind of accounts that could have coins deposited
into them or withdrawn from them more than once.  A txOut on the
other hand is non-divisible, and is created exactly once and spent
exactly once. The Bitcoin design didn't have to deal with locking
as such because it was built on "atomic" primitives.

Locking issues (and potential division attacks) arise when people
try to force complicated things that involve multiple sequential
transactions to happen.  The design of such interlocking sets and
sequences of transactions is fraught with all the usual troubles
of protocol design and can be got wrong even if the individual
steps are properly atomic.

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

Ethereum, unlike Bitcoin, provided persistent accounts with balances
that could change more than once.  So, yes, they needed locking.
Apparently a bunch of transactions were done with a script that
failed to execute the locking mechanism correctly.

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

By nature such a thing can't be automated.  There has to be community
support for the hard fork to happen. You can't do it yourself unless
you've built in a technical stop that would make you "trusted" in the
evil sense; someone whose failure, coercion, or bad faith can screw
everyone else over.

Contract or not, if people don't actually *do* the hard fork
when you call for it, you can't pick up your toys and go home
because they're not yours anymore. Not unless the user community
allows you to keep playing with them.  All the alternatives involve
drawn out proceedings in an old-fashioned analog courtroom, with
expensive lawyers and a judge and jury who're going to have to study
cryptocurrency ideas and protocols starting from scratch in order
to even understand what the contract they're being called on to
enforce is about.  The eventual result of such a proceeding is
something I'd prefer to neither rely on nor wait for nor pay for.

As John Boehner said, "without followers a leader is just a man
taking a walk."

				Bear

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20160727/8f7b85b1/attachment.sig>