Warehouse Receipts

Just some notes for myself...

The current system is account-based, meaning that the instruments always refer to assets that are in some account.

So if I have a cheque for 10 clams, it's drawn against a clam account, and if the clams aren't there, the cheque will bounce.

Similarly, the cash is also drawn against an account. When you withdraw cash, the server takes it from your clam account, and adds it to the server's clam account for backing cash, and then issues you the appropriate amount of cash. Later on, when someone deposits the cash note, assuming it's a valid note, the server then pulls 10 clams back out of its server backing account, and puts them into the depositor's account. (This is similar to how it works when you exchange in/out of a basket currency.)

Having the server "double" the cash in a backing account is a way of protecting in case of security breach in the token code. After all, even if you have a bad token that slips through, the server still can't give you any more clams than are stored in the clam account. The server can never have more notes out than it has backing assets to cover them. The account would just go empty, which, if the note was still good, would reveal that the token system had been compromised.

As we can see, cheques and cash are very similar, in that they are both merely a mechanism; an instrument to be redeemed that is actually sitting in an account somewhere. Both cheques and cash have ACCOUNT BACKING. The only difference is, the cheques are traceable and they use transaction numbers for invalidating instruments, whereas the cash is untraceable, and it uses a spent token database along with expiring mint series for invalidating instruments.

NOW WE TURN OUR ATTENTION TO WAREHOUSE RECEIPTS...

What if the backing for the [cheques/cash] was not account based, but rather, was warehouse based?

What if the OT server actually stored a warehouse of notes, each with a serial number and each signed by its issuer (a separate entity.)

Let's further assume that those notes are all identical, or that they are all in identical groups (1 clam denomination, 5 clam denomination, 10 clams, 20 clams, 50 clams, etc.) This means, again, that each individual group contains notes that are all identical.

Now, cannot the existing cash token mechanism be used for trading these individual receipts, untraceably? If I want to withdraw 10 serial-numbered bars of gold, but into untraceable cash form, how would OT handle this?

Maybe like this: Each OTWarehouse object has a dividing line, between the serial numbers that are out in circulation, and those that are still back in the warehouse. For example, let's say that ALL the serial numbers are still in the warehouse, and then I show up to do the FIRST WITHDRAWAL. I ask for 10 clams (and let's say the serial-numbered notes are all 1-clam notes.)

The OTWarehouse object simply selects 10 of the serial numbers from the "available" list (not too hard since they are ALL currently available.) Let's say those are serial numbers 30,31,32,33,34,35,36,37,38, and 39. Those are marked as "CIRCULATING" (unavailable for the next withdrawal.)

THEN THE SERVER ISSUES ME 10 CLAMS WORTH OF UNTRACEABLE BEARER NOTES. Notice that the serial numbers are reserved in the warehouse, but there is no way to match them to the notes that were issued to me!!! Of course, there is also no NEED to match them. Let's say later on, after hundreds of people have done similar withdrawals, some guy goes in to redeem his cash, and he redeems 10 clams, so they give him the next 10 clams that are available in the warehouse, and they turn out to be the ones that I originally withdrew (30-39.)

Have I been robbed? Of course not. When I redeem my own cash, there still be SOME notes set aside, equivalent even, they just won't have the exact same serial numbers as the ones that were set aside when I first did the withdrawal. It's not necessary for those numbers to match up (in fact that would ruin the untraceability.) As long as the notes in circulation are equivalent in amount to the ones in the warehouse, the system works perfectly.

In fact, it forces one to ask: Why not use the existing account-based system, since it's functionally identical? Because perhaps there are cases where the existence of explicit signed notes from the issuer (versus an account balance) provides additional proof that they have actually issued notes which have then passed beyond their control. (Notice the Federal Reserve is never held responsible for fraudulent transactions using their money, though E-Gold is... Why? This is the exact distinction.)

I CAN ALSO THINK of cases where EACH serial number is actually a contract ID instead of a serial number. (Each serial numbered item in that instance of the warehouse actually refers to a DIFFERENT CONTRACT ID EACH TIME!) Of course, you cannot have a normal withdrawal from such a warehouse. But you CAN use it for registering, and transferring, clear title of property!

Imagine if I have a car, and I want to put it in the "warehouse". I draw up a contract describing the car, containing its VIN number, and various other identifying characteristics. Now (as the car's owner) I upload the contract to the server to "register" the existence of this new property. My public key is in the original contract, and I have also signed it.

The server doesn't have to issue a new currency based on that contract (like it normally would...) Instead, perhaps the server just stores the contract on a registry (that's why I uploaded it...) It hashes the contract (producing the ID for the car) and lists that contract as one of my "assets" (since I am the one who uploaded it.)

The contract has an ID. (No, you cannot use that ID to open an asset account, since it's not a currency contract, but a property contract. But you CAN store it on the server as your asset, and transfer it to someone else, or sell it, or put it into escrow, ETC!)

For example, when I first upload the car's contract, a transaction number is issued and a coupon is given to me, referencing the car's contract ID as well as the transaction number. (Let's say, transaction number 5.)

Next I sell the car to my friend. He puts 1000 clams into an escrow instrument, where I also put the car. Once BOTH of us sign off on the transaction, the clams are given to me and the car is given to him. The server is able to verify both instruments, so both parties know that both instruments are valid.

As you can see, escrow MUST be built into the server for people to even be able to safely negotiate the two instruments at all! Unlike account-based forms of property, which have access to markets, there is no way to safely guarantee that you'll get the money in exchange for your car... unless you have escrow! That is what makes it possible for people to verify that both instruments are valid, and to verify that the exchange will be two ways.

When the car is given to my friend, the server burns my old coupon, which was transaction #5, and generates for him a NEW coupon, say with transaction number 9. This coupon references the same contract ID for the car that my original coupon referenced. Now my friend has the only valid coupon, which is also provably the most recent one for that piece of property.

NOW: if I try to redeem the old car coupon, the OT server says, "Sorry, that's an old transaction number, and it's no longer any good. That's a bad coupon." But if my friend tries to redeem the coupon (say, sell it to someone else) the server knows that HIS coupon IS valid, since the transaction number on it is good, so the server performs the transfer as requested.

IN THIS WAY, INDIVIDUAL PIECES OF PROPERTY can be registered to their initial owners, and then transferred securely to other people, providing clean title!

And what is that coupon but a voucher? (on OT, a voucher is like a cashier's cheque... it's a cheque guaranteed by the server.) The coupon has an asset type ID, just like a cheque (the contract ID)... it has a transaction number, just like a cheque... it is functionally identical to a cheque! The only difference is that the instrument transfers a unique piece of property, instead of a specific AMOUNT of an asset type.

Therefore, since the cheque instrument can clearly be adapted for transfers, couldn't the cash instrument be similarly used for unique items, just as the cheque is?

That is, instead of putting a transaction number on the note, which is traceable, put a BLINDED TOKEN ID on the note, which is untraceable... The note can still be signed, and still be considered valid, even though the server has no way of knowing who the bearer is!

Of course, if the server gives me an "untraceable" note for a certain car, and then you deposit it, the server still clearly knows that I transferred it to you! (Even though the server didn't know what the actual token ID was on the instrument, it can still clearly see both ends of the transfer.) BUT! If ALL "cash titles" were transferred using a "title-only interface" (similar to a "cash only interface" that appears in the OT diagrams) where all actual "title exchanges" were performed BY THE SAME ACCOUNT EVERY TIME, then all of those property transfers become untraceable! Just like any other OT cash, you can see the Nym who withdraws, and the Nym who deposits, but you can't see who had it in between!