[tahoe-dev] Tahoe-LAFS Weekly Conference report, 2012-09-25

Zooko Wilcox-O'Hearn zooko at zooko.com
Thu Sep 27 15:27:22 UTC 2012


caveat lector

2012-09-25 -- "The Science Fair episode"

in attendance: Zooko (scribe), CodesInChaos, amiller, David-Sarah, elb


Topic: proof-of-storage/proof-of-retrievability

CiC suggested a pass-through "Chess Grandmaster" style attack of
storage server which doesn't hold the data but queries other servers
to answer challenges.

amiller suggested that perhaps not knowing the verify cap would
prevent a storage server from doing that.

CiC pointed out that if you are a malicious storage server who wants
to defect, you won't do that when there are K other, non-malicious,
storage servers online. You might as well wait until there are not
enough non-malicious storage servers left, so that your defection can
accomplish some real harm.

CiC mentioned his standard merkle tree design, but didn't get much
opportunity to say much about it.

There was extensive discussion about the very notion of
Proof-of-Storage and Proof-of-Retrievability, and how they could be
applied to LAFS. I (Zooko) intend to write notes to tahoe-dev about it
soon. David-Sarah had simulation results about the idea of
Proof-of-Storage by adding erasure-coding redundancy to each share
stored on an individual server.

After CiC disconnected, amiller and davidsarah proposed standardizing
a hash-dag instead of a hash-tree, with the tree being a special case
of the dag. There was a bit about having a tweak to make hash
collision attacks harder.

Andrew Miller talked about the Bitcoin blockchain and a git repository
are similar data structures.

Zooko told Andrew Miller that digital signatures built out of secure
hash functions normally use hash trees, but that one design, due to
Bleichenbacher and Maurer, uses hash-dags instead.

The full sub-graph of a LAFS filesystem which is  reachable starting
from an immutable dir constitutes a hash dag. Not so for mutable dirs.



More information about the tahoe-dev mailing list