Trading

In the Free Haven design, servers periodically trade shares with each other. There are a number of reasons why servers trade:

Cover for Publishing:

If trades are common, then there is no reason to assume that somebody offering a trade is the publisher of a share.

Servers Join and Leave:

Trading allows servers to gracefully exit the servnet by giving away all their shares. This support for a dynamic network is crucial, since many of the participants in Free Haven will be well-behaved but transient relative to the duration of the longer-lived shares.

Longer expiration dates:

Long-lasting shares would be rare if trading them involved finding a server that promised to be up and available for the next several years.

Accomodates ethical concerns of server operators:

Frequent trading makes it easy and unsuspicious for server operators to trade away a particular piece of data with which they do not wish to be associated. Server operators can use the public key in each share to check to what document a share belongs, then trade away the share without compromising their reputation as a servnet node or the availability of the document.

Provides a moving target:

Encouraging shares to move from node to node through the servnet means that there is never any specific, static target to attack.

When a server A wants to make a trade (frequency of trade should be a parameter set by the server operator), it chooses another server Bfrom its list of known servers (based on trust and history), and offers a share $\Phi_i$ and a request for size or duration of a return share. If B is interested, it responds with a share $\lambda_k$ of its own. (The notation X_y indicates share y of document X.)

Trades are considered ``fair'' based on the two-dimensional currency of $size \times duration$, plus a function of the preferences of the servers involved in the trade.

The negotiation is finalized by each server sending an acknowledgement of the trade (including receipt, as described in section 4.8) to the other. In addition, each server sends a receipt to both the buddy of the share it is sending and the buddy of the share it is receiving; buddies and the accountability they provide are described in section 4.9. Thus, the entire trading handshake takes four rounds: the first two to exchange the shares themselves, and the next two to exchange receipts and at the same time send receipts to the buddies.

By providing the receipt on the third round of the trading handshake, A makes a commitment to store the share $\lambda_k$. Similarly, the receipt that B generates on the fourth round represents a commitment to store the share $\Phi_i$. B could attack A by failing to continue the protocol after the third line: in this case, A has committed to keeping the share from B, but B has not committed to anything. At this point, A's only recourse is to broadcast a complaint against Band hope that the Trust system causes others to recognize that B has misbehaved.

We suggest that when a server A trades a share to a server B, server A should keep a copy of the share around for a while, just in case Bproves untrustworthy. This will increase the amount of overhead in the system by a factor of two or so (depending on duration), but provide greatly increased robustness. In this case, when a query is done for a share, the system responding should include a flag for whether it believes itself to be the ``primary provider'' of the data, or just happens to have a copy still lying around. The amount of time is a parameter which requires further study.