Return-path: Date: Tue, 7 Oct 1997 08:39:27 -0400 (EDT) To: e$@thumper.vmeng.com cc: enoch@zipcon.net, eternity@internexus.net, Lyle_Seaman@transarc.com, rah@shipwright.com, szabo@best.com Subject: Persistence of Data on the Information Silk Road From: Ted Anderson -----BEGIN PGP SIGNED MESSAGE----- Subject: Persistence of Data on the Information Silk Road This note builds on a model for the global market in public information I introduced in a message on 29Aug1997 titled: "The Information Silk Road"[1]. In that description I posited the existence of data merchants which trade in information. I listed several services data merchants could offer that their customers would be willing to pay for (the value they can add to free data): speed of access (caching), locality (replication), data location services, and anonymity. But I omitted an especially important service: persistence. Data merchants could store data for customers; essentially renting out disk space. Mike Duvos suggested on 29Aug1997 in "A Distributed Network Cache Service" an idea for using micropayments to pay servers to store data. There was a follow-up on 31Aug1997 called "Adding Memory to the Net" which amplified further on this motif. I've saved some of these messages (thanks to RAH's e$pam) in [2]. In one of the follow-ups "Just Another Cypherpunk" says: You could imagine the price going up over time as fewer people want to see it. At some point not enough people may want to pay as much money so it goes away. In this model the server operators would just be information speculators. These "information speculators" are just the data merchants I envision. I have two basic problems with Mike's idea. The first is the payment model, and I think I have a good solution for this. The second is that I don't seen any financial incentive for data merchants to maintain data that no one is requesting. This seems to me to throw a bit of a wrench into the whole eternity file service idea. I originally saw two basic approaches for a customer to pay a data merchant to hold his data. Either pay in advance; the customer must trust the merchant not to take the money and drop the data. Or pay to get the data back; the customer must trust the merchant to retain the data and the merchant must trust the customer to still be around when the storage period is over. Clearly there are also half-now-half-later variants. None of these seemed very sound. Taking a queue from Nick Szabo's Smart Contracts[3] and Robert Hettinga's Digital Bearer Bonds[4] it occurred to me to construct a sort of bond to attach value to the persistence of the data. To do this, deposit some money with an escrow agent in exchange for a digital instrument which encodes a hash value and a date. The instrument entitles the holder to present the data matching the hash value after the date and receive the money in exchange. The escrow agent has instructions for what to do when the data is returned; perhaps it keeps it for a short while pending pick-up or e-mails it to a specified address. Anyone wanting to preserve some data can create such a bond and sell it, with the data, to a data merchant at a discount from the face value. To first order, this discount represents the cost of storing the data until the bond matures. Normally the market value of the bond would increases as time passes until the date of maturity arrives when the bond, with the data, can be redeemed at face value. The data merchant can, of course, sell the data alone to customers requesting it. If he perceives a large resale market he may offer to buy the bond at a reduced discount, since retailing the data will defray some of his storage costs. The data merchange may also decide to resell the bond itself, using an e$-like protocol, to some other data merchant. If there are few requests for the data it may be more profitable to sell the bond to data archiving service that doesn't keep data on rotating media but instead keeps it on tertiary storage, sorted by maturity date, along with other bonds. These tertiary media represent future cash and can be reloaded after the collective maturity date and redeemed with the appropriate escrow agents. Presumably the cost of such off-line storage would be considerably lower than for online storage, so the discount to face value would be smaller and the selling data merchant could reap a small profit on the sale. This mechanism assures, with fair confidence, that data can be cast onto the network and be reliably recovered in the future. Of course, it doesn't guarantee that the data will not be lost or suppressed, merely establishes the cost of such an action. If I dearly desire that the data be retained I can create a bond with a large face value. Since the cost of storing the data is pretty much unaffected by the face value, the discount is similarly unaffected. The main difference is that the bond holder has more at risk if the data is lost in a disk crash or other calamity. However, nothing stops a censorious attacker from buying the bond and discarding it, except lack of funds. There is presumably some art in selecting the face value of a bond. Clearly the value needs to reflect the storage costs of the data, because, after discounting, the value still needs to be positive. Further, if discounted the value is too small the data merchant has little incentive, at least at first, to avoid losing or even discarding the data. For example, if the cost to store a megabyte of data for a year is $1, then a $1.10 bond would sell initially for a dime. This may or may not be enough to convince the data merchant to hold on to it for a year. Though, after 11 months, it would be worth about $1.01 ($1*11/12 + $0.10). Perhaps a $2 face value would make more sense, the initial and final values would differ by no more than a factor of two. On the other hand, a $20 face value would sell initially for about $19, but the value to data merchants is large and approximately constant for the life of the bond. The limit on face value is that the premium the data merchant has to pay for insurance against disk crashes is proportional to the face value. Data assurance costs will represent an additional discount from the bond's face value, but after all improving the safety of the data is why the large face value was selected in the first place. If the original owner of the data has lots of money to spend it may make more sense to mint additional bonds (probably with different escrow agents) with smaller face values and sell them to different data merchants. There is still no guarantee that the data will be preserved, but at least the cost to suppress the data is quantifiable. [1] http://www.transarc.com/~ota/Information-Silk-Road.html [2] http://www.transarc.com/~ota/DistributedNetworkCacheService.txt [3] http://www.firstmonday.dk/issues/issue2_9/szabo/index.html (I haven't yet read this reference, but I've read earlier material on the same subject). [4] http://www.shipwright.com. I know Bob has a rant on this in there somewhere. Or try http://www.tiac.net/users/rah/dbb.html. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBNDoskwGojC9e/wyBAQHsewP/WBMR5rIgS4rECbagvXrdDW+xi/qKyu66 37NFjzIHvqsjCKEHMSwtvpk49nPuc/XiCCy7SzpeJok7ANEXJd8shQ1rXrcLbP6Y D5X6TA3t3dzna/FXvhNmPqBn9caosjPbnBOg0XsbeRP4k9lu38AZO2eoKKkVOpD7 7I7WyDIuZhY= =P2eE -----END PGP SIGNATURE-----