Tesla Coils & Corpses, 2014-08-22 — cryptocurrency 2.0 storage, Ethereum

[Zooko Wilcox-OHearn]

.. -*- coding: utf-8-with-signature-unix; fill-column: 73; -*-
.. -*- indent-tabs-mode: nil -*-

LAFS Tesla Coils & Corpses, 2014-08-22
======================================

in attendance: Zooko (scribe), Andrew, Daira, Nathan

Zooko has been noticing all these distributed-storage projects coming
out of the cryptocurrency world: Permacoin
(<https://www.cs.umd.edu/~elaine/docs/permacoin.pdf>), StorJ
(<http://storj.io/>), MaidSafe (<http://maidsafe.net/>), a recent blog
post from Vitalik Buterin
(<https://blog.ethereum.org/2014/08/16/secret-sharing-erasure-coding-guide-aspiring-dropbox-decentralizer/>),
and IPFS/FileCoin (<http://filecoin.io/>). Zooko is saddened that none
of these projects are building on Tahoe-LAFS, nor even studying
Tahoe-LAFS and learning from its successes and its mistakes.

Andrew says they all have broken incentives, will eventually get
exploited, but none of them come with a good model or formalism with
which to succinctly show that it is broken.

Zooko suggests "Mechanism Design" as that formalism
(https://en.wikipedia.org/wiki/Mechanism_design ).

Then we switched gears:

Andrew showed us an Ethereum script which sets a mutable variable to a
value then does some stuff, and surprisingly that variable has the
wrong value after. If you try to fix this by adding locking, then the
locking may prevent an otherwise useful and desirable use case.
<https://gist.github.com/amiller/cdc42df919a9b1dcf7df#file-concurrency_example-py>

Zooko pointed out that this is the same pattern of examples shown by
Mark S. Miller in his PhD dissertation
(<http://www.erights.org/talks/thesis/index.html>), which is there
called "Plan Interference".

Andrew proposes an Ethereum message-queue dispatcher (implementing an
eventual-send).

Nathan: There's a proposal for an Ethereum thing called "alarm". That
could be used for the eventual-send message.

Daira: Where's the best documentation for the Ethereum language?
Andrew: the yellow paper.

Daira finds these systems difficult to think about because they are
*almost* capabilities-as-data systems except that the mailbox
addresses are not secret.

Andrew wonders if you could layer capabilities on top by having a
little table of which contract is allowed to send messages to which
contract.

Zooko says that would be a C-list, implementing a capabilities-as-access system.

So Andrew went and implemented one right at that moment:
<https://gist.github.com/amiller/dab7b9d2aece26f5bf20>

Zooko noticed that it had a flaw — it allowed Alice to give a
Bob-reference to Carol even if Alice didn't have a reference to Carol.

Caps-as-access can implement the *-property, and confinement in
general, Caps-as-data can't.

Daira says "I think I've been convinced that it is possible to
implement an obj-caps system in Ethereum."

Andrew wants to be able to connect two objects within the ocap graph
even if neither created the other, and there is no path through the
ocap graph that connects them. Why? Because Andrew might already own
some Ether, and there could be an Capthereum-based club, like a
lottery, and Andrew might want to play their lottery.

We proposed a hybrid in which some sorts of things in Ethereum-world [
* ], which have private keys, can register themselves with the
Introducer in order to linked in to the ocap graph, but other sorts of
things, that created by contracts, through the cap-manager, can't do
that and so they can be confined.

[* Zooko doesn't understand Ethereum well enough to understand what
sorts of things Andrew and Nathan were talking about.]


-- 
Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.