Saturday, September 26, 2009

A Billion Dollar Thought Experiment

A few posts ago, I brought up the possibility that one could create an electric monetary system simply by having a big database with a fixed number of entries. Cash transactions would entail assigning an entry in the database to a new owner.

This program would be similar to the cash in your wallet. You will notice all those crisp hundred dollar bills bear unique serial numbers. (Well, there is only one lonely five dollar bill in my wallet ... that's a different story).

As the entries in the database are fixed, this system would not be subject to the counterfeiting problems of paper money.

I decided that in the Open Source Real Time eXchange that I would have a cash account that was just that, a database of real live cash. If you bought $100 in the cash account, it would point to a specific hundred dollar bill.

Speaking of hundred dollar bills: When I check books into the library, I tell the clerk that I use $100 bills as bookmarks. They know I am lying, but, like clock work, they thumb through the books I check in to see if I left a bookmark.

The cash account brings up an interesting thought experiment:

If I took a billion dollars out of my checking account, put that money in a super safe place under a rock at the bottom of the ocean, then sold shares of that money on the NASDAQ; we could learn a thing or two about the market.

One would think that my billion dollars would be worth a billion dollars. The shares in the IPO would sell for less than a billion dollars because of the transaction cost.

After the IPO, something really strange would happen. People who think they've found an investment that will grow at a rate faster than cash would start shorting my billion dollars. They would short my billion dollar cash account with gusto. The shorting would continue until the shares of the cash account were selling at about have a dollar a piece.

The thought experiment on trading a cash account is important. The value of a cash account should stay closely in line with the cash value of the cash. If traded on the OSTRX, this would happen. A pure cash equity on the NYSE or NASDAQ would be shorted.

This shorting of a cash account has essentially the same effect on the economy as counterfeit currency, it floods the market with bogus paper that pushes down the value of the real paper on the market.

In weighing market regulations, I think the regulators should examine questions like the viability of a billion dollar cash account. If the account isn't viable, then there is something wrong with the regulations.

4 comments:

RD said...

The transaction cost won't go away.

The database needed to run your 100 trillion row(conservative estimate) cash table, The security system, The logging system, And the simple transaction load of such a system is going to incur a transaction penalty somewhere. Another problem of row per dollar schemes is how to handle fractional quantity's. Ohh and High availability, I can't stress enough how important this is to any system running what your proposing, This is a subject I am very familiar with and it gets expensive fast in a redundant replicated way =p.

Then you have the software maintenance and initial build out, SQL wouldn't scale to this type of thing very well, you would ether need something custom or perhaps a column based storage database like the system Transunion/Equifax use for their credit history system.

y-intercept said...

The model with each dollar having a unique row is theoretical. A working currency database is likely to have denominations. There would be one database full of ones, another for the tens, another for the hundreds, another for the thousands, and perhaps on for the ten thousand bill.

One might do the denominations in binary as computers like binary.

BTW, I was actually thinking of doing the exchange at a lower level than SQL.

Let's say a company had a million shares of stock. Let's give each investor a unique 32 bit integer. The stock could then be represented as an array of a million 32 bit integers.

A byte is 8 bits. A million 32 bit integers is 4MB. That is small enough so that it would be easy to back up each night.

In this type of flat file, the position is the primary key. Also, you don't need an index. The key is the physical location of the entry in the array.

For a stock transaction, the system would identify a set of shares to trade. This would be a set of numbers like (4678, 12345-12555, 75555-75655). The program would verify ownership of the rows before the transaction. This is a very fast bit comparison.

On completing the transation it would run through the table again, checking each number in the table, and changing them to the new owner.

Both parties in the transaction would receive audit trails of the transaction.

Operations on flat files are substantially faster than SQL calls.

RD said...

Getting rid of denominations would grandly simplify the database and in fact cost much less to handle even if your column count was a hundred times larger.

Flat file won't work for this, you are going to need CoWS(copy on write support) to make transaction handling and rollbacks easy. You also are going to need some rather massive index's on this so we will have to add in the overhead of a b+ tree for each column(s) that need indexing.

Nightly backup's for this type of thing not only would be criminally irresponsible, but would be wholly insufficient. You need real time data replication to multiple geographic regions and global failover. Nightly tape copy's are nice but even loosing 10seconds of transaction data could represent billions of dollars worth of transactions.

Handling the unique ID for each stock, warrant, bond, option, cash bill would be better off as a universally unique identifier. Their is a performance penalty for using a UUID but for the subject at hand its worth it.

As for comparisons on data I wouldn't worry about that to much the bigger pain is in the storage back end, data Partitioning, replication, Load distribution, fail over, high availability.

If you haven't guessed it yet I do this type of stuff for a living(well for what they pay students....*grumbles*) =p hehe. Both the systems administration side(tho this part bores me), and heavy programming.

y-intercept said...

The great thing about an open source program is that people can really hash through issues like the database structure.

From a theoretical perspective, I like talking in terms of flat files because it emphasizes the logic. One could implement the flat file system with a room full of clerks marking pieces of paper.

On the technical end, I agree that it would be much easier to build the program with a robust database engine with built in transaction processing and redundancy. That argument emphasizes the technology.

A robust debate about the best platform for hosting an exchange is welcome as it emphasizes the concept is independent of the technology.

If this idea ever moved from pipe dream to actuality, I am quite sure that someone with street creds in the OS community (not me) would be the system architect.

It is in the spirit of robust debate that I develop my ideas.

I started leaning to a flat table idea because I wanted the ability to track every bit of data in the stock table. Different databases handle transaction processing and hashing differently; so a bit by bit comparison of what happens in a transaction would be different depending on the database.

If things were in flat files, then one could achieve a situation where the files were similar at any point in a transaction regardless of platform ... Linux, Unix, DOS, NT or other file structure.

Before I had access to databases with built in transaction processing, I was writing my own procedures for rolling back and committing transactions.

Since there will be only a few functions altering the data, it might be worth the effort to have the full transaction processing code written into the object that accesses the data.

Such a system is closer to the elusive Object Oriented Database.

If there was interest to start this program, the group that writes the program (not me) would be making these architectural decisions.

My gig is to concentrate on theory.

Since creating an exchange involves legal matters, the architectural discussion would follow (or co-incide) with a legal discussion.

To achieve a real time transaction, the database needs to be recognized as the actual legal document.

Since lawyers and judges have denser heads than programmers, the issue might be driven by what is preferrable in the view of the courts: Is it better for the legal document to be a UUID adjacent to the stock owner, or would it be better for the legal document to be a position in a physical table?

I don't know that answer.

The actual design of the OSTRX starts with a philosophical debate about ownership. In this debate the exchange is presented in very abstract terms.

Then there is an investigation of legal requirements and architectural design during which one selects the platform.

I flunked out of school;

The process would then jump into a cascading cycle of development.

BTW, you are correct that a daily backup is not sufficient. The system I described has transaction files and an audit trail. Running the transaction files on the previous day's records can recreate the day's transactions to any given moment, and the audit trail can recreate the transaction file.

Needless to say, it is also possible to save copies of the stock file throughout the day.

I was actually planning on writing the transaction files in a Pacioli fashion with separate debit and credit trails with balancing procedures to help insure data integrity.

The open source structure would invite participation from lawyers, CPAs, programmers, investors, the SEC or anyone interested in the process.