From: norm@netcom.com (Norman Hardy)
Date: Sun, 29 Jan 95 09:15:38 PST
To: cypherpunks@toad.com
Subject: Re: Protocols for a Data Bank
Message-ID: <ab517999010210042be5@DialupEudora>
MIME-Version: 1.0
Content-Type: text/plain


This is a corrected version. I was wrong to suggest that the protocol was
similar to blinded signatures.


Protocols for a Data Bank

The purpose of a data bank is to store large bodies of information for long
periods of time. I suggest here some protocols and contracts for a data
bank and its customers. We then discuss risks, incentives and
stratification of the data storage industry.

Here are several transactions that a data bank engages in.

Acquire data: A client anonymously sends a collection of data along with
funds sufficient to warrant the bank's computing its secure hash and
holding the data for a few days. The bank knows the data only by its secure
hash.

Selling (Hat) Checks: The bank will sell a check to anyone who will pay a
negotiated price. The check specifies the secure hash of the data, the cost
of redeeming the data, and the penalty to be paid by the bank upon failure
to produce the data. A client proposes the details of a check as
follows: Send (SH(acquisition), redemption price, penalty, SH(Secret)) to
the bank along with a proposed price. 'Secret' is a secret random number
chosen by the client for this negotiation. If the bank agrees it signs and
trades the signed message for the proposed price, or it may propose another
price. The signed message is the check and is a bearer instrument.

Redeem data: Any holder of a check can present the check along with the
secret, the redemption fee and demand the data. The data bank must then
either produce the data or pay the penalty to the holder of the check. A
particular check is canceled whenever the bank pays the penalty like a
spent Chaum DigiCash note. The bank can sell multiple checks for the same
data. Different checks for the same data may specify different penalties.

Sell a copy of an acquisition: Any one can request a piece of data
identified only by its secure hash. The bank is free to sell a copy of the
data to anyone with the secure hash. The bank sets the price.

Publish index: The bank can publish its list of hashes. (This makes data
hunters possible.)

Cancel a check: A holder of a check may sell it back to the bank at a
negotiated price thus releasing the bank from the risk of paying a penalty
in the future. This also allows the bank to retrieve the physical storage
where the data is stored if it is sure that it has not sold other checks
for the data.

Checks may specify expiration dates, cancellation terms etc. The bank is
explicitly permitted to disseminate the data and may well do so to lay-off
and reduce risks. In this sense a data bank is like an insurance company
that spreads and shares risks. A check may be viewed as a life insurance
policy for the data.

Risks

Trust may be divided by agreeing on a notary. Upon redemption the bank
examines the check to see if it has been canceled. If it knows the Secret
which produced the SH(Secret) of the check, the check is canceled.
Otherwise a mutually trusted notary takes the check, accepts the redemption
payment specified therein from the client, passes over the data on its way
from the bank to the client while computing the secure hash. If the secure
hash matches that in the check the notary delivers the payment to the bank.
If the hash fails to match, the transaction is aborted and a penalty
transaction begins. The bank delivers the penalty to the notary and the
client delivers the secret to the notary. If the hash of the secret matches
that in the check then the notary delivers the secret to the bank
(canceling the check) and the penalty amount to the client. The notary need
not have long term financial stability as must the bank.

Brokers may have an interface similar to a bank. They return baskets of
checks. This reduces the risk to the client that one of the data banks will
fail financially and be unable to pay the penalty. The broker need not be
financially stable.

Data Hunters engage in knowing who has what data. Given a hash they can
tell you what banks have the data. This might be the ultimate URL or URI
server.

Inflation can damage incentives. Checks might be denominated in gold or
currency baskets or what ever.

RSA modulus size is critical for long term contacts. 2K bits of modulus or
more may be warranted.

Example

I can imagine the Getty Museum digitizing its Rembrandts and storing the
results in a data bank. The data might be insured for $10,000,000. The bank
would disseminate the data to increase security and lower its risk. The
museum would probably encrypt the data and share the key and hash ala
Shamir for safe keeping. The museum would not share the check because it
wants to be the one paid upon default.

Incentives

A data bank, or any other player, may find that keeping data profitable
beyond the point of any outstanding checks. It can make money by selling
copies of the data. Data banks thus have an incentive to disseminate their
list of holdings in the form of hashes, to support data hunters.

Design Considerations

It may seem strange that the data bank does is willing to sell data to who
ever will pay. I suggest this because it is easy to encipher the data and
not have to trust the bank. You can distribute the key thru what ever
channels you transmit the secure hash of the data.

Note that bank clients are always anonymous. Data is never held for some
known person. Data may be held solely for speculation. The purpose of the
penalty is to motivate the bank to keep data for which there is no reason
to forecast sales revenue. Unlike Chaum bank notes, the issuance of a hat
check may be  associated with the redemption. The depositing of data and
hat check issuance, however, may be anonymous. Data redemption may be
anonymous but collecting a substantial penalty may be difficult to arrange
anonymously. Managing anonymous transactions is a difficult but orthogonal
issue.

The Bank's State

Logically the bank can perform all of these transactions by merely keeping
the unordered set of acquisitions. It is practically necessary to index
these by their secure hash but this can be rebuilt from the acquisitions
themselves. When it looses data it must keep canceled checks to avoid extra
penalties. The bank need not keep records of checks that it has sold unless
it wants to know when it can delete acquisitions. It may want to keep
marketing information to know when acquisitions are worth keeping merely to
sell copies of. The bank will need to keep records of the checks that it
issues for financial auditors (to satisfy owners of the bank.)