My thoughts as an enterprise Java developer.

Friday, October 31, 2008

Why do geeks celebrate Christmas on Halloween?

Because Oct. 31 = Dec. 25

Thursday, October 02, 2008

Digital money

I think digital money should have these features:
  1. Hard to counterfit
  2. Hard to duplicate (and use twice)
  3. Easy to transfer to another person with minimal involvement of a 3rd party
  4. Easy to use, track, store, verify, etc
  5. Transaction fees must be very, very low.
  6. Minimal Big Brother tracking.
Here is one idea for how to accomplish that:
A user would go to a website and enter payment info and the website would send the user an image file. The file would be a picture of the amount of money that it represents (for ease of use) and would have comments in it that record the originating website, amount and any other needed info. The website would generate the image so that is unique (i.e. the bits are unique) and would store the image bits and amount in a database. The file would have to be large enough so that a brute force attempt to generate random files would be too expensive.
When the user needs to split an amount (make change), they would send it to the website and request the new amounts. The website would verify that it was valid (in their DB), send new image files to the user, and delete the record for the old file.
When the user needs to send money to another person they would just get the correct amount (using splitting or multiple files) and send those files to the other person. The other person would send them to the website to get their own files so that the old file is invalid and they have a valid file. Once the other person saw that they were valid they would complete the transaction with the first person.
Verification consists of sending to the website to get an new file. If the file was invalid the webiste would just give an error message. Anytime a user receives money from another user they must verify it (get a new file) to make sure that it is valid.
The user could cash out the file by going to the website and requesting payment.
Transaction fees would be limited to the initial payment and requesting payment.

The user could have requested multiple files with various amounts to make it easier.
If someone tries to make a copy of the file in order to use it twice only the first copy would be validated.

The user would need to remember to not make any changes to the image (i.e. rotation) because that would invalidate the file. Therefore the image formats that Windows Explorer can rotate should be avoided or the files always marked as read-only.

This idea could work for trading anything (different currencies, stocks, etc). Each website would have its own file type but websites or users could translate between the different file types.

Comments?