Warehouse Receipts

WAREHOUSE RECEIPTS, TITLE OF PROPERTY, and ARBITRATION

INITIAL UNDERSTANDING

The current system is account-based, meaning that the instruments always refer to assets that are in some account. (That is, even if you are operating cash-free, with no accounts, there is still a server account somewhere containing the backing funds for your cash. This is a security mechanism.)

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 tokens are 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 transfer mechanism; an instrument to be redeemed, when the "real value" 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.

I should also point out that the "account backing" on the server side, when it really comes down to it, is really nothing more than the signed agreement from the issuer, authorizing a certain amount of a specific currency, as described in its currency contract.

NOW WE TURN 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 whole warehouse of serial-numbered (and signed) "bars of gold" from the issuer?

Let's further assume that these "bars" are all otherwise identical, or that they are all in identical groups for denominations (1 clams, 5 clams, 10 clams, 20 clams, 50 clams, etc matching the cash denominations that are described in the currency contract.) This means, again, that each individual group contains notes that are all otherwise identical, besides their serial number, and are all signed by the issuer.

Now, can't the existing OT cash token mechanism be used for performing untraceable transfers of these serial numbers?

If I wanted to withdraw 10 serial-numbered bars of gold into untraceable cash form, couldn't the server just set aside 10 clams worth of the serial numbers back in the warehouse, and then issue me a matching number of (untraceable) cash tokens? Then whenever the cash tokens are redeemed in the future, the OT warehouse just takes some serial numbers out from the "circulation" pile and puts them back into the "warehouse" pile.

I don't really care what specific serial numbers I get from the warehouse when I redeem the cash notes, as long as the asset type is the same, and the quantity is the same. The exact serial numbers cannot be matched from withdrawal to deposit, only the quantity (since the tokens are blinded and their token IDs are different every time they are deposited.)

In fact, if only the quantity is actually being tracked, and the individual tokens cannot be matched to the individual serial numbers, it forces one to ask: Why not use the existing account-based system, since it's functionally identical? Why warehouse all of these signed receipts from the issuer at all, instead of just storing a single balance agreement like we do with accounts?

Because perhaps there are cases where the existence of explicitly numbered and signed notes from the issuer (versus an account balance) provides additional evidence that the digital assets, after having been issued, have now passed beyond the issuer's control and into circulation.

Notice the Federal Reserve is never held responsible for fraudulent transactions using their currency, though E-Gold is... Why? This is the exact distinction. Because the Federal Reserve has released their currency into circulation and they have no more control over it. Whereas E-Gold, the issuer of a currency, has direct control over all of the transactions of their currency -- and therefore they are held responsible to track and report all of those transactions.

Warehousing also more strongly presents the transaction server as merely performing warehousing services (which is true). That is, using the Chaumian cash tokens to serve as the "warehouse receipts" while the actual serial-numbered "bars of gold" are stored back in the "warehouse" on the OT server.

In this scenario, the OT server could be configured to run in "cash only" mode--so that there aren't any accounts at all. Instead, there is only the warehouse--and an interface for token exchanges. (Consider the consequences if such a server were to be destroyed or stolen: the issuer could cancel the serial numbers and issue them on a new server, and the users could produce their signed receipts to resolve all disputes.)

I think, BTW, that all of the technical properties are the same whether you use an account or a warehouse. Either can be used in cash-only mode. Either can have the issuer and the server as separate entities.

It seems to me, rather, that the real difference is legal, in that it makes a stronger legal clarification (in my non-lawyer opinion) that real digital assets, with serial numbers, have been issued and released into circulation, and that the issuer has no more reach over them, and that many other entities control them now, and that none of the parties involved, including the issuer or even the OT transaction server itself, manages any accounts for any users, nor has any power to view any of the transactions.

---

CLEAR TITLE for UNIQUE PIECES OF PROPERTY

From all this, now we can imagine an instrument where EACH serial numbered item, instead of belonging to an identical group, actually refers to a different contract ID each time. This is not useful for a circulating currency, but it is useful for attaching clear and transferrable title to unique pieces of property.

Imagine if I have a car, and I want to put it in the "warehouse". First 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 in order to "register" the existence of this new property. Of course, I am already the owner of the car in reality. Registering it this way, in a commonly trusted registry, just gives me more proof and leverage regarding this fact. My public key is included in the original contract, and I have also signed it with that key. (So only I may upload it...)

The server doesn't have to issue a new currency based on that contract (like it normally would when a new contract is uploaded...) Instead, the server just stores the contract on a registry. 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.) No, I cannot use that ID to open an asset account, since it's not a currency contract, but rather, a property contract. But I CAN "store" it on the server as my asset, and transfer it to someone else, or sell it, or put it into escrow, ETC! It becomes title of property.

How will this all work?

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, which is signed out to me. (Let's say, transaction number 5.)

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

As you can see, escrow MUST be built into the server for people to even be able to safely negotiate unique pieces of property! 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. (Outside of markets, this restriction is also true for account-based instruments. Without escrow, each transfer is one-way and you have no guarantee that the corresponding payment will be made in return. Escrow enables safe two-way transfers.)

When the car is given to my friend, the server burns my old coupon, which was transaction #5 in reference to my car's ID, and then it generates for my friend a NEW coupon, say with transaction # 9, ALSO in reference to the same car ID that my original coupon referenced. (Now my friend has the newest, and the only valid, coupon for that car! He is now the owner.)

NOW: if I try to redeem the old car coupon, the OT server says, "Sorry, 5 is an old transaction number, and it's no longer any good. That's a bad coupon." The server even has a signed receipt from me by this time, proving that transaction #5 is no longer signed out to me. But when my friend tries to redeem his coupon (say, to sell the car 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 the event of any dispute, my friend can prove his title by producing his last signed receipt from the server (showing that transaction #9 is still signed out to him), and by producing his coupon, which is signed by the server, and which shows that transaction #9 is in reference to a car contract, and is made out to him!

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 really, but a form of 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! (Or, a voucher, since it's guaranteed by the server instead of by a user account.) The only difference is that the instrument transfers a unique piece of property, instead of a specific AMOUNT of an asset type. (So it has no amount.)

Therefore, since the cheque instrument can clearly be adapted for transfers of property title, 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 the actual token ID, it can still clearly see both ends of that transfer. This is because the car itself is unique and can only belong to one person at a time. It I withdrew it, and you deposited it... the untraceable token ID by itself, does us no good...)

UNTRACEABLE TRANSFER of UNIQUE PIECES OF PROPERTY

BUT! If ALL titles being transferred via the cash instrument were additionally 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! In effect, they become bearer coupons to unique pieces of property. Just like any other OT cash, you can see the Nym who withdrew it, and you can see the Nym who deposits it, but you can't see all the Nyms who had it in between!

I find it interesting, by the way, that the storage of unique items in these warehouses, must lend some weight to the legal argument that serial-numbered items can also be stored in such warehouses.

---

ARBITRATION

Will Strong Encrypton Protect Privacy and Make Government Obsolete?

(From http://www.independent.org/events/transcript.asp?eventID=20): "You and I sign a contract. In the contract, we specify a private arbitrator. The contract includes the private arbitrator’s public key. The contract is digitally signed by both you and me. Now, you think I violated the contract. You demand arbitration. The arbitrator rules that I owe you damages. I refuse to pay. The arbitrator writes a brief statement that I agreed to—that he would be the arbitrator of disputes, that he gave a verdict, and that I refused to pay the damages. Digitally signs it and gives it to you. You now have a package. That package consists of the original contract which I digitally signed, so provably I agreed to it, and the arbitrator’s verdict, which he digitally signed, so provably the arbitrator I agreed to, said that I cheated. You may now e-mail that package to anybody else in the industry. — You want the arbitrator who gets the right result at low cost. This is a market mechanism for generating efficient law for the private market."

What Open Transactions adds to this picture is that due to the Triple-Signed Receipts (with a transaction number being "signed out" to a specific Nym as long as its instrument is still outstanding), such "Verdict" packages can thus be amended and revoked as necessary, according to their terms. Whether a debt has been paid, an arbiter needs to reverse a mistake, or an instrument is simply old or expired, parties can prove instrument status and validity simply by producing their last signed receipt.

How would this work on OT?

Alice and Bob agree to terms, and communicate them to the Judge (arbitration service.) The Judge actually issues the contract on the OT server (terms may be encrypted if the parties prefer to keep them private, with the relevant public keys available in the contract.) The Judge uses one of his transaction numbers (#13) to issue the contract onto the server.

From there, Alice and Bob can both download the contract from the server (or a hash of it) and examine it to be sure that the terms and arbitrar are all correctly outlined. (All they need is the contract ID, which is a hash of the contract.)

Once they are satisfied, each submits a new transaction, under a new #, requesting to be bound to the original contract (by ID). For example, Alice burns transaction #24 to sign on, and Bob burns transaction #45. Both request to sign on to the same Contract ID.

As long as the contract remains open, the Judge will have #13 signed out, Alice has #24 signed out, and Bob has #45 signed out. Therefore none of them can claim they aren't responsible for those numbers, since their #s appear on all of their receipts. (Until the Judge decides to RELEASE the contract, which frees the parties, but this also delivers a receipt to them all, containing the Judge's signed request to do so.)

Later there is a dispute about the fulfillment of the agreement (a dispute filed by either party, which causes a dispute receipt to go into the Judge's inbox). Alice says Bob is refusing to do the floor tiles. Next the Judge makes a decision, which also creates a receipt into each party's inbox. He decides that Bob has broken the contract. (Optionally this history can also be stored on the server and queried based on ContractID--some contracts may have publicly available history in this way.)

At this point Alice now has a signed receipt showing the original contract, showing Bob's original request to sign on and his transaction #45 and his signature, and also the Judge's signature on the ruling that Bob violated the agreement, showing the Judge's transaction #13, and of course also showing Alice's #24.

Alice can now present this receipt in any Court, or to any entity, proving the ruling of the arbitration Judge. If Bob wishes to disprove her to the same entity (or on a registry somewhere), all he must do is produce a newer receipt showing that he's not responsible for #45.

Of course if the Judge is an entity with little credibility, then no one may care whether the number is on Bob's receipt or not. Bob may also optionally remove the number from his future transaction statements by disputing the ruling, but he cannot get away with this, since the same dispute process would undoubtably drop a receipt into the inboxes of all concerned parties, so they'd all have his signature on the dispute request. Later any of them could produce this in order to prove what happened.