No Subject

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. These ideas implicitly rely on
several types of cryptography-- public key, secure hash, symmetric ciphers
and blind signatures. To explain these technologies here would
substantially obscure the presentation for those who know of such things
and help very little for those who don't.

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 holding the data for a few days and
computing its secure hash. The bank knows the data only by its secure hash.

Selling Hat Checks: The bank will sell a hat check to anyone who will pay a
negotiated price. The hat check specifies the secure hash of the data, the
penalty to be paid upon failure to produce the data, and the cost of
redeeming the data. The hat check is signed blindly by the bank and is a
bearer instrument. Any holder of a hat check can present the check along
with 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 hat check. A
particular hat check is canceled whenever the bank pays the penalty like a
spent Chaum DigiCash note. The bank can sell multiple hat checks for the
same data. Different hat 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 hat check: A holder of a hat check may sell it back to the bank at
a negotiated price thus releasing the bank from the threat 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
hat checks for the data.

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

Risks

Dividing trust may be done by agreeing on a notary. Upon redemption, for
instance, a trusted notary might examine the hat check, accept the payment
specified therein from the client, pass over the data on its way from the
bank to the client while computing the secure hash, and if the secure hash
matches that in the hat check, deliver the payment to the bank. 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 hat
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 can engage in knowing who has what data. Given a hash they can
tell you what banks have the data. This would presumably require a new
protocol with the bank. This might be the ultimate URL or URI server.

Inflation can damage incentives. Hat 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 $100,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 hat 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 hat checks. It can make money by
supplying copies of the data in return for a fee plus secure hash. Indeed
new hat checks may be sold after the last had expired. Data banks thus have
an incentive to disseminate their list of holdings in the form of hashes,
as input to bounty hunters.

Design Considerations

It may seem strange that the data bank does is willing to sell data to who
ever will pay. I suggest that because it is so 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.

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 on demand. It must keep
canceled hat checks lest it become liable to extra penalties. The bank need
not keep records of hat 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.

> Date: Sat, 28 Jan 1995 15:49:13 -0800
> From: norm@netcom.com (Norman Hardy)
>   [...]
> Selling Hat Checks: The bank will sell a hat check to anyone who will pay a
> negotiated price. The hat check specifies the secure hash of the data, the
> penalty to be paid upon failure to produce the data, and the cost of
> redeeming the data. The hat check is signed blindly by the bank and is a
                                              ^^^^^^^
> bearer instrument. Any holder of a hat check can present the check along
> with the redemption fee and demand the data. 

  Why in the world would the bank want to sign blindly?  The bank
would be undertaking an obligation of an unknown nature.  Would you
sign a blank check?  A blank contract?  I wouldn't.

  Unless the comunication mechanism ensures anonymity, the bank can
know who deposited what, and who 'withdrew' what.

j'

From: norm@netcom.com (Norman Hardy)

   The hat check specifies the secure hash of the data, the
   penalty to be paid upon failure to produce the data, and the cost of
   redeeming the data. 

This sentence contains the single best idea in the whole proposal,
which is to specify liquidated damages in the retrieval note.  (Most
of you will be saying, What?)

One of the largest costs of any conflict resolution is deciding, once
the existence of damage has been agreed upon, exactly what the scope
and worth of that damage was.  "Liquidated damages" are a term of art
referring to a pre-agreed upon worth of the damage in question.  One
most often sees them in construction contracts, where the contractor
will agree to pay a fixed amount per day for each day late.  Rather
than bickering over how much a delay is worth, the two parties agree
in advance to value each day of delay at a given amount.  This kind of
agreement is cheaper _for both parties_ than going to court.

In the data bank case, the liquidated damages are the amount to be
paid upon failure to produce data.  In this case, there's no need even
to call it a penalty.  The data bank agrees to produce either data or
a fixed amount of money.  They get to choose, and it will almost
always be cheaper to remit data rather than money.

   The hat check is signed blindly by the bank and is a
   bearer instrument. 

There's no need to have it signed blind.  A blind signature is useful
when two parties have some persistent relationship with the
intermediary; when they don't have identity, there's no need for
blinding.  Take, for example, a money bank.  Two account holders who
wish to transact also wish to keep that transaction secret; in order
to do so, they use a blind-signed note, which prevents the linkage
from being determined by the bank.  The reason that the blind
signature is necessary is that the two parties have accounts with the
bank, that is, they are known to it in advance.  These two wish not to
create more information at the bank, that is, more information than is
already known.

On the other hand, this model of a data bank does not have account
holders.  The relationship between this data bank and its customers is
embodied in the retrieval notes ("hat checks").  Furthermore, if two
parties wish to move data through the data bank, the storage and the
retrieval transactions can be trivially linked because they are about
the _same_ piece of data.  The hash of the stored data is the same as
the hash of the retrieved data.  Because data is not fungible -- one
block of data is not like another -- the parties who use this data
bank as a intermediary of transmission must remain anonymous to the
data bank if they are to remain unlinked.

A blind signature will not alleviate the need to remain anonymous to
this data bank.  Suppose (somehow) the data bank was able to sign
blind the right sort of retrieval note.  So fine, the retrieval note
doesn't reveal the linkage directly.  But the retrieval note must
contain the hash of the data being retrieved.  The hash can't change;
it's the access key.  So the unchanging part of the note is what gives
the link away.  We therefore conclude that there's no need for a blind
signature here at all.

   Cancel a hat check: A holder of a hat check may sell it back to the bank at
   a negotiated price thus releasing the bank from the threat of paying a
   penalty in the future.

This cancellation can't be done well.  Remember that the parties are
remaining anonymous to the data bank.  In order to release the data
bank of an obligation, some party would have to make some signed
statement releasing the data bank from the obligation.  But making a
signature reveals identity, perforce.

Furthermore the retrieval note is a bearer instrument, but it's a
_digital_ bearer instrument, which means you can't simply give the
note back to the data bank.  There's no piece of paper to return.
Once the note is out there, it's out there forever.  There can be lots
and lots of bearers.  Which one of them gets to release the data bank
of its obligation?

   The hat check may specify expiration dates, cancellation terms etc. 

The retrieval note very well should specify an expiration date, since
otherwise the data bank has specified an obligation in perpetuity.  A
perpetual obligation is much less stable than a fixed-time one.  The
value to the data bank of disappearance grows larger as the cost of
storing the data increases.  No new external revenue is coming in (by
definition -- otherwise you've got a renewable agreement, which is
different) and all you've got is costs.  So there becomes little
reason not to simply abscond with the assets and deny any outstanding
obligations.

A customer, therefore, would be wise not to deal with a data bank
which signed perpetual obligations.  If a customer wants indefinitely
long storage, the best way to do this is with a set of interlocking
obligations with mutually ignorant parties.

   The bank is explicitly permitted to disseminate the data and may
   well do so to lay-off risks. In this sense a data bank is like in
   insurance company that spreads and shares risks. A hat check may be
   viewed as a life insurance policy for the data.

This is exactly why liquidated damages are such a good idea.  By
making explicit the cost of data loss, a data bank can much more
accurately calculate it's risks and costs.  Indeed, the ability to lay
off risk of loss is what can create a stable economy of data storage.

There are lots of extraneous elements in the proposal that I've not
addressed.  I wish to highlight what is valuable and not to dwell on
what is not.

Eric