[Cryptography] Code is Cruel -- The DAO

[Peter Todd]

On Sun, Jul 24, 2016 at 04:16:14PM -0400, ianG wrote:
> >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.

Double-entry bookkeeping was developed in a time when the available ways to do
arithmetic were both error prone and expensive; with computers arithmetic is
highly accurate, and more importantly, extremely cheap.

I don't see why you would have a double-entry backend in a computer system;
just re-do the calculations and see if you get the same result. After all,
that's how cryptocurrencies work: everyone who fully validates re-checks every
calculation, and scalability approaches focus on limiting the scope of who
needs to fully validate (e.g. Lightning's approach of caching transactions, so
most transactions are between a small number of parties, or my own client-side
validation approach of only calculating history relevant to you).

What's more important is having a 100% accurate recording of what the
transactions are supposed to be in the first place, but that's what consensus
algorithms do, whatever the exact approach is that you take.

Now that said, having your consensus mechanism commit to checkpoints of the
entire state is a nice thing and lets you quickly find consensus problems, like
the debits/credits mistakes described next. In Bitcoin Core, you can easily get
a hash of the entire state as of a particular block height, which is commonly
used to cross-check implementations:

    $ btc gettxoutsetinfo
    {
      "height": 422242,
      "bestblock": "00000000000000000384d6e2d2ca642382b75faf3d8777492048db449475572f",
      "transactions": 11856140,
      "txouts": 40523151,
      "bytes_serialized": 1439610493,
 >>>  "hash_serialized": "f4ec9bc2dac641311635250334e59814e28975aab2298888d065e77460681fd7",
      "total_amount": 15777873.60473552
    }

But at best that's double-entry accounting only in spirit.

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

Hmm? In Bitcoin not only are there no accounts, but at the protocol level
transactions are supposed to be atomic; exactly what order debits and credits -
transaction outputs being marked spent and created - happens is an
implementation detail. Getting anything wrong in your implementation other than
the correct atomic transactions is a disaster as you end up out of consensus
pretty quickly.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20160725/6393fd6a/attachment.sig>