[freehaven-dev] sketching accountability requirements/solutions in FH

[Roger Dingledine <arma@mit.edu>]

Our job is two-fold: we want to keep people from overfilling the
bandwidth available from and between servers; and we want to keep people
from overfilling the system with data.

A) Bandwidth: we can require timewasting micropayments for having a
server respond to a query. But there are really two issues here. From
the big picture, we're talking about the Free Haven protocol -- each
request is effectively a chain of length two (one to get to the server,
one (broadcast) hop to get to every other server). From the little picture,
we're using a separate mixnet to do each hop. If this mixnet gets hammered,
then it doesn't matter that we're using micropayments at the Free Haven
level. So first of all we need to sketch a solution for using
micropayments to protect mixnets. This is a tough problem, but hey, it's
one we've been planning to look into for a while. Perhaps we could take a
lesson from ZKS in this. Mike, can you address this? We don't need to go
into every detail of solving it; just a paragraph or two sketching solutions
that don't suck and that pertain to real-life right-now systems. The issue
I see is that we need to decide to pay just the head of the mix chain,
or pay each of them, or something.

But even if we solve that, we have the same problem at the higher level:
the requestor doing the FH document query needs to pay not only to get
his request to the first server, but he also has to pay that server to
contact all the other servers. Is there a way to tunnel payment like
that? (Or rather, what's the best way.) (Note that the requestor doesn't
know how many servers are currently participating; this might make it
very tricky. The parallel to this is that if we pay every node of the
mixnet, how does the sender know how many hops there are?)  I'm pretty
sure that we can assume that servers will behave nicely most of the time
(as opposed to eating the whole payment themselves), especially if they're
non-fungible payments. "Servers that drop queries will stop getting used
after a while."

B) Data. This is broken down into two issues also: first of all we
need to notice servers that drop data, and second we need to develop a
process for 'punishing' these servers. The process of noticing is very
difficult, and we still haven't solved it for real. The 'buddy system'
is our current approach, and it may well be good enough. As for punishing
misbehaving servers, that's where our reputation scheme comes in. I
can take a while to address the various questions and topics raised in
reputations.txt specifically in the context of Free Haven. This would
be a valuable addition to the chapter; I'll try to post more musings on
that later tonight or tomorrow.

Comments? Am I being blind?
--Roger