End the War on Freedom

Trubanc is an anonymous, digitally-signed vault and trading system that I've been working on since late July.

I've completed enough of a Trubanc web client to ask you to help me test it. Read the short documentation, ask me for a coupon with some usage tokens (bill at billstclair dot com), and register with the client.

Warning: the client and server are running, without encryption (no https), on a NearlyFreeSpeech.net web server in Arizona. Use it to help me test, but don't put anything of value there. I'm likely to occasionally break things during development, and the feds will likely steal it if they find out about it.

I haven't thought much about encryption for the Trubanc client/server link. I figured I'd just set up SSL on the server, and go with that. Today, I realized that I don't need SSL. Trubanc already has a public key infrastructure all set up. It can do it's own encryption, using the OpenSSL library just as the SSL protocol does. Here's an outline of the encryption protocol, using the same language I use in my server design, from the perspective of the client:

  sent: (<id>,getsessionkey,<bankid>,<reqid>)
  rcvd: (<bankid>,sessionkey,<id>,<pubkey encrypted: [<sessionid>,<sessionkey>]>)

  sent: [<sessionid>,<sessionkey encrypted: message>]
  rcvd: [<sessionid>,<sessionkey encrypted: response>]
           or
        [<sessionid>,unknown] if the <sessionid> isn't registered

  sent: [<sessionid>,
         <sessionkey encrypted: (<id>,closesession,<bankid>,<sessionid>)>]
  rcvd: [<sessionid>,
         <sessionkey encrypted:
           (<bankid>,@closesession,(<id>,closesession,<bankid>,<sessionid>))>]

This should be relatively easy to implement, and won't likely slow things down by much. Yay!

The Trubanc server is working. It's not complete yet, but there's enough there that I've started coding the client. If you click here, you'll see the result of a request for the bank's ID. It's running from a real database, with a couple of testing users in it.

I've also written a simple description of the Trubanc protocol: Trubanc in Plain English.

Yay!

On Monday, I talked about a new idea I had for a Loom-like system with public-key-signed balances. Well, I've been madly writing code since then. I'm calling it Trubanc. There's a design document, and you can peruse the code as I write it. I intend to keep it open source, so that it can be verified. The server is about 1/3 done. When I finish that, and an initial web client, I'll let you know, and you can try it out, with funny money, of course. Exciting!

Trubanc

If you know how, and are willing, I'd love the signature on the logo above to be curved and reduced so that it would fit from about 3 to 5 o'clock near the edge of the coin. The images I started with are here and here. I'll give a GoldNowBanc GoldGram to the first person to submit an image that I like (you'll need a Loom account to take it).

I talked for an hour last night with Patrick Chkoreff, the creator of loom.cc. We came up with a scheme for doing secure banking and trading, where both the bank and the customer can prove at all times what the customer's balances are and what outstanding spends he has, and to whom. That's all that either party needs to keep track of.

It uses public key signing on every exchanged message.

Users and banks are identified by the 160-bit fingerprint of their public key ID.

I intend to write a longer article, explaining the notation below, but I wanted to post this, so it's not just on my computer.

Create account: (id_a, public_key_a, random): signature_a
(This requires that somebody has pre-funded account id_a with tokens. Token balances need to be worked into the transactions below)

Sequence request: (id_a, "getsequence", random): signature_a
Sequence response: (id_bank, "sequence", sequence1): signature_bank

Spend order: (id_a, "spendto", id_b, sequence1, type, amount, comment1): signature_a
Balance: (id_bank, "balance", id_a, sequence1, type, balance): signature_bank
Confirm balance: (id_a, "confirmbalance", sequence1, type, balance): signature_a
Outstanding spends: (id_bank, "outstandingspends", id_a, sequence1, [sequences...]): signature_bank
Confirm outstanding spends: (id_a, "confirmoutstandingspends" , sequence1, [sequences...]): signature_a

Cancel Spend: (id_a, "cancelspend", id_b, sequence1, type, amount): signature_a
Balance: ... sequence2 ...
Confirm balance: ... sequence2 ...
Outstanding spends: ... sequence2 ...
Confirm outstanding spends: ... sequence2 ...

Get queue entry: (id_b, "getq", random): signature_b
Receipt: (id_bank, "receipt", (id_a, "sellto", id_b, sequence1, type, amount, comment1): signature_a): signature_bank
Confirm receipt: (id_b, "confirmreceipt", id_a, sequence1, type, amount): signature_b
Balance: (id_bank, "balance", id_b, sequence3, type, balance): signature_bank
Confirm balance: (id_b, "confirmbalance", sequence3, type, balance): signature_b

Get queue entry: (id_a, "getq", random): signature_a
Closed spend: (id_bank, "closedspend", ((id_b, "confirmedreceipt", id_a, sequence1, type, amount): signature_b)): signature_bank
Confirm closed spend: (id_a, "confirmclosedspend", id_b, sequence1, type, amount): signature_a
Outstanding spends: ... sequence4 ...
Confirm outstanding spends: ... sequence4 ...

Deny receipt: (id_b, "denyreceipt", id_a, sequence1, type, amount, comment2): signature_b

Get queue entry: id_a ...
Denied spend: (id_bank, "deniedspend", (id_b, "denyreceipt", id_a, sequence1, type, amount, comment2): signature_b): signature_bank
Confirm denied spend: (id_a, "confirmdeniedspend", id_b, sequence1, type, amount): signature_a
Balance: ... sequence5 ...
Confirm Balance: ... sequence5 ...
Outstanding spends: ... sequence5 ...
Confirm outstanding spends: ... sequence5 ...

Get confirmed balance: (id_a, "getconfirmedbalance", type, random): signature_a
Confirmed balance: (id_bank, "confirmedbalance", (id_a, "confirmbalance", sequence1, type, balance): signature_a): signature_bank

Get confirmed outstanding spends: (id_a, "getconfirmedoutstandingspends", random): signature_a
Confirmed outstanding spends: (id_bank, "confirmedoutstandingspends", (id_a, "confirmoutstandingspends" , sequence1, [sequences...]): signature_a): signature_bank

I updated my Loom iPhone interface, billstclair.com/loom/ip.php, to match Patrick's changes to the Loom interface. "Folder" renamed to "Wallet". "Location" renamed to "Contact". You can tap on a line in a contact's section of the wallet to take all the assets on that line. Also, you can tap on the contact name as well as the green dot (which I retained because I like it) to edit a contact in the "Loom Contacts" screen.

2008-02-17
New release of Loom software with many improvements:

• You now claim an asset from a contact with a single click. Therefore the "Take" button has been eliminated, and only "Give" remains.
• You can now add a new asset to your folder by copying and pasting a single piece of text. For example:

      id: 26ef701a952fe3d641a69bf859db71c2 scale: 7 precision: 3 name: Patrick GoldGrams

• Tabs in folder interface now show as "Wallet," "Contacts," and "Assets" to reflect simplified terminology.
• Each tab in folder interface now has a very thoroughly written context-sensitive Help link. Be sure to click Help as you run through the various tabs.
• No more green dots. If you want more detail on something, click it. To avoid visual clutter, we often use links that don't appear as links until you hover over them.
• When you disable history, the entire history display now disappears. Formerly it would still display your history without recording any new transactions until you enabled it again. We like the ability to hide the history altogether, cutting down on distractions and page load time when you really just want to move things around fast.
• Lots of silky smooth user interface features and refinements.
• A new feature in the Archive API, and consequently in the Content Management System, to guard against overlapping writes. Now if two people are editing text at a single location, or even uploading files to a single location, the system will detect if anything changed "under their feet" and not clobber the other user's changes. The system also gives a helpful message describing a simple recovery mechanism for integrating the overlapping changes.
• Although the Vending Machine API is not yet implemented, the new feature of claiming an asset with a single click is the perfect lead-in to how vending machines will operate inside folders. Soon, two-way trades will be utterly simple and rock-solid in all respects.

I've decided to create a GUI application for accessing Loom. I'm calling it Loomsheet. It will be written in Python, using wxPython for the GUI widgets. It will basically be a fancy spreadsheet, with live tables that can import and export their contents across the net. Most of the engine will not be Loom specific, but my use of it will be. So far, I've only reserved the domain, loomsheet.com and started on the design. I'll post another notice when there's something runnable. And, if you want to know details, you can follow the Atom feed for puts to the Git repository.

I've been writing PHP scripts recently to interact with the Loom.cc anonymous electronic vault and trading system. I've wanted to be able to show off my code, and my emacs design text files, without requiring the download of a source TAR file. So I wrote a little script that displays a text file, with a fixed width font and word wrap, and, optionally, searching for a phrase and/or displaying line numbers.

Go to billstclair.com/loom/viewtext.php?file=viewtext.php to direct the script to view itself.

You can add line numbers by adding "&numbers=yes" to that URL.

You can search for a phrase, e.g. "replace", by adding "&search=replace" to the URL. Each instance of the search string becomes a link that you can click on to move to the next one.

Finally, such file viewers are security risks if you're not careful. But I was. Only files explicitly named in "viewtext.txt" may be viewed. That list is displayed if you leave off the "file": billstclair.com/loom/viewtext.php. This makes it easy to drop a copy of viewtext.php in a directory on your web site, and enter the names of the files you want to show in viewtext.txt in that directory.

Go wild!

A GDBM database file is an easy way to persistently store key/value pairs. Loom uses one for its backing store. One problem with these databases is that they become fragmented over time, with lots of unfilled empty space: holes. They need to be periodically compressed. Patrick Chkeroff and I came up with a neat mechanism to do live compression. He has seen the Loom database file get 20 times bigger than it needed to be. He plans to integrate something similar to this mechanism into the Loom code.

The basic idea mirrors Lisp two-space incremental garbage collectors, but is a little simpler. Call the original GDBM database the "old" database. We're going to open a second database, called the "new" database. And change the database access code so that it will over time copy the old database to the new one, leaving the new one with a compressed version of the data in the old one, plus any changes the user code has made during the copy operation.

There's a working example in GDBM.php, in my Loom folder. You can copy and paste from that page or download it and my other Loom related code from billstclair.com/loom.

The idea is simple. There are three operations on a database, read, write, and delete (implemented in the code by get() and put() functions, where put() of a blank value means delete).

read($key):

1. If $key has a value in the new database, return it.
2. If $key has a value in the old database, return it.
3. Otherwise, return false, not in the database.

write($key, $value):

1. Write the value to the new database.
2. Delete the key from the old database.

delete($key)

1. Delete the key from the old database.
2. Delete the key from the new database.

To each of the operations, I also add a call to the copysome() function, which copies some values from the old database to the new one. After all values have been copied, we close both databases, delete the old one, which is now empty, rename new to old, and reopen the new old database. When the user requests another copy, we open another new database and start again.

copysome:

1. Fetch the first key/value pair in the old database
2. If the key does not yet have a value in the new database, insert the key/value pair there.
3. Delete the key from the old database.
   
4. Repeat for a configurable number of copies, or until the old database is empty

At no time is it necessary to close the database for off-line compression. All you need is enough disk space to store two copies of the data, and a slight slow-down in access speed during the copy.

GoldNow sells lots of different electronic currencies: c-gold, e-Bullion Gold, e-Bullion e-Currency, e-gold, GoldNowBanc GoldGrams, GoldNowBanc USD, Liberty Reserve USD, Loom Tokens, Pecunix. GoldNowBanc GoldGrams and GoldNowBanc USD are stored in Loom. Loom Tokens can be used to buy loom storage.

Their registration page sends you a sponsor link for a new Loom folder with 198 tokens. That's enough for most people's uses. Your cost for the "free" tokens is your contact information: snail mail, telephone, and email.

The e-currencies sell for spot price at transaction time plus 5%, and it costs an additional 5 to 10% for payment in money order or fund transfer. Details of which e-currencies and payment methods are available vary depending on your location (country).

Loom tokens cost $1/100.

I mentioned GoldNow in my first Loom article, but since then they've made it very easy to get a Loom folder, and to fund it with gold.

billstclair.com/loom/ip.php is a Loom client sized for the iPhone screen. Works on my iPhone. And in Firefox on my desktop machine. Make yourself a "Mobile" folder and give it a try.

Loomster.net is on-line. It's a wiki covering "Everything Loom." Not a lot there yet, and I have yet to receive my registration email containing my password, but I'm sure that will be ironed out soon, and then we who like Loom can fill it up with useful information. I added its feed to my news aggregator pages.

As promised, I worked up some screen shots of an even better scheme for keeping track of real and virtual assets at Loom.cc. This idea uses three folders. The "Personal" folder is for day-to-day business. It contains only positive balances. This is the only folder used for trading with others.

The "Issuer" folder is used for issuing assets that I control. It contains only negative balances. I've named my reserve asset types "~ .308 rounds" and "~ Gold Grams". Those are issued to match real commodities in my basement (this is a made-up scenario. I'm not telling how much ammo or gold I have in my basement). The preceding twiddle ("~") marks them as private asset types, not to be traded with anybody but myself. The "Bill .308 rounds" and "Bill GoldGrams" asset types are circulating currencies backed by the reserve commodities. I always issue exactly as many of these as I have in reserve (though there really might be more of the reserve commodities in my basement that I don't intend to promise to anybody).

The "Vault" folder is used to store savings and the private reserve assets:

If I get a new shipment of 1000 rounds of .308 that I want to use to back new "Bill .308 rounds", I issue both the reserve and circulating assets from the "Issuer" folder by moving them to my private "~ Xfer" location. Note that I always keep equal the amounts issued of "Bill .308 rounds" and "~ .308 rounds":

Then I take the reserve assets into the "Vault":

And I take the new circulating currency into my "Personal" folder, from which I can, hopefully, spend it to buy cool stuff:

If somebody wants to convert one of my currencies into its reserve commodity, this goes in reverse. I ask them to give the currency to an agreed-upon transfer location, then I take it into my personal folder:

and give it to my private "~ Xfer" location:

Then I give that amount of the corresponding private reserve asset from the "Vault" folder to the "~ Xfer" location:

Finally, I take both the currency and the reserve into the "Issuer" folder:

Now I can remove the commodity from my basement, ship it to Bob, and he can have some percussive therapy.

I doubt that I will personally issue a Loom currency any time soon. I'll be happy to use currencies issued by others who make that their business. But I've worked up this series of methods for keeping track so that issuers will have some ideas.

I have written client code for the Loom grid in both PHP and Java. Go to my Loom home page at billstclair.com/loom for information.

These libraries allow you to easily call the web API at https://loom.cc/. Use of the PHP version is demonstrated by a PHP translation of Patrick's Grid Tutorial. The Java class is self demonstrating; it can be used as a simple command line interface to the grid.

In a comment Creating Your Own Loom Currency article, I mentioned that Patrick Chkoreff uses a different mechanism than I proposed to make sure he doesn't issue more digital currency than he has real assets for backing. Here I elucidate that a little.

I'm going to imagine that I have in my basement some gold, some Liberty Dollars, and three calibers of ammunition. I set up a Loom folder to track those real assets, moving the amount I have of each into the "Storage" location in Loom.

In my regular Loom account, I have a digital currency corresponding to each:

I import the real asset "Storage" location into my regular account, but prepend the name with a "~" to mark it as a private location that I never use for trade.

I also imagine that I have received Patrick's digital gold and silver in payment. So my home folder now looks like this:

Now I just have to make sure I don't allow the negative number in front of each digital currency in my folder to exceed the corresponding amount in storage. Ooops. I'm doing fractional reserve banking in 7.62x39 rounds. Better buy some ammo or some currency.

This way of tracking issuance is especially nice when you issue more than one digital currency. It takes up minimal space on the issuance page. I could see having three folders, one for hard assets, one for issuance, and one for personal use.

This is the third in my series of articles about the Loom.cc Electronic Accounting System. Click the "Loom" category at the bottom of the article to find the others.

One nice thing about Loom is that it allows you to create your own asset types, your own private currencies. In a comment to his Digital Money World article, A Brief Loom Instructional, Mark Herpel described one unusual "currency":

If I wanted to set up a digital currency backed by gold stored in my gun safe in my basement, I could easily do that in Loom. First, I'd create two new asset types, "Gun Safe GoldGrams" and "Gun Safe GoldGrams Reserve". The former will be what I issue to people, and the latter will be to keep track of how much actual gold I have in my safe. Then I can easily see if I'm about to give out more Gun Safe Gold than I have in reserve, and buy more gold (or decide to risk being a fractional reserve banker, which no self-respecting Loom trader would do).

Here's the screen creating the "Gun Safe GoldGrams". I clicked on the "Random" link to generate the asset type, and typed in the Nickname, Scale, and Min Precision:

Next I created a "Gun Safe" location to hold my "Gun Safe GoldGrams Reserve":

Finally, I recorded my two-pound gold nest egg by transferring grams of "Gun Safe GoldGrams Reserve" to the "Gun Safe":

Now I'm ready to start selling Gun Safe GoldGrams, and moving them to transfer locations for my customers (well, I would be ready if I actually had a two-pound gold nest egg). As long as the number after the minus sign in the "Gun Safe GoldGrams" row remains smaller than the number in the "Gun Safe GoldGrams Reserve" row, my reserve is sufficient to cover my currency in circulation, and I'll sleep well at night.

I introduced the Loom.cc electronic accounting system on Monday. Since then, I talked extensively with it's creator, Patrick Chkoreff. He gave me a link to the source, and I got it working in a Linux virtual machine on my Mac (I wasn't able to install one of the Perl libraries it needs in Mac OS X). It took me a little while to figure out how to bootstrap the first folder, the one that owns the usage tokens, but I found a comment in the code that pointed me in the right direction. I made a suggestion to Patrick to make this easier in the future, and I think he'll probably do it. I'm running v58 of the software, which is an older version than the one that is currently running at Loom.cc. Mine is missing the "CMS".

The Loom Grid Help page gives a good overview of the logical implementation of the grid. But there are a few details of that representation that have important ramifications for the security of your assets in the system.
You still have to trust that Patrick's code does what he says it does, i.e. that Loom.cc is really running the code that he distributes, and you have to trust that he's using a secure web host. The latter seems pretty likely since "whois loom.cc" says that the nameservers are ns1.rayservers.com and ns2.rayservers.com, and rayservers.com's web page says that they specialize in security, availability, and high bandwidth. Only time and experience will tell how trustworthy Patrick is with our assets.

One of the first things I wondered about the security of the Loom.cc database is how much information someone who got access to a raw database files would be able to extract from it. Turns out that not much can be gleaned, but possibly more than ideal.

The database itself is currently implemented using GNU gdbm, a persistent hashtable mechanism that is part of most Linux distributions. The keys and data in this can be any string of bytes. It's quick and mature. Loom's interface to gdbm is centralized and very simple, so replacing it with another persistent hash-table mechanism wouldn't be hard.

The loom database is used to store two types of data, the grid of asset values and what Patrick calls the archive. In the source code I have, the archive is used only for storing your folder information, your name, the assets you know about and their names, and the locations you know about and their names. In the current development code, the archive enables a complete, secure Content Management System (CMS).

Except for the initialization of an asset, which stores -1 in the issuer location, changes to the grid are always done in pairs, subtracting the transferred amount from the source location and adding it to the destination location. The database key for a location is the concatenation of the asset id and and the SHA256 hash of the location. The value is the raw integer number of asset tokens, which is formatted for display according to how you configure the "Scale" and "Min Precision" on the "Edit Asset Type" web page. This allows identification of the values and raw integer asset IDs from a database dump, but no idea of the locations themselves. A knowledgable person could, however, recognize values for assets that they care about, and change the database to transfer assets from unknown locations to locations that they know, "stealing" assets from unknown Loom users. The advantage of the current scheme is that it enables auditing of the assets to make sure all the numbers add to -1. It might be better from a security standpoint, however, to hash the concatenated asset ID and location as the datbase key, and, possibly, encrypt the values, using the raw location as the encryption key, as is done in the archive.
Encrypting and storing the concatenation of the value and its hash would allow validation of a users's assets at login time, for a doubling of the value storage space.

The archive, where your folder information is stored, and where the CMS is stored (I think), is much more secure. The database key is the SHA256 hash of the location ID. The value is AES encrypted with the raw location. So, though you can see the hashes in the database, you need to know the unhashed locations to decrypt the data. The folder location ID is a hash of the login passphrase. The folder information is encoded as a text string in KV format, as printed when you fill in the text areas and click one of the buttons on the Loom Grid Tutorial page.

Loom.cc is Patrick Chkoreff's general-purpose digital accounting system. It enables creation of asset types, and accounts in each type. It is basically a huge, sparsely-populated spreadsheet, with 2^128 rows and 2^128 columns. Each column is an asset type. Each row is a "folder". Each "location" (spreadsheet cell) holds a single 128-bit number. The "issuer" location for each column contains a negative number, initial -1, and the other locations hold positive numbers. The sum of all the locations in a column is always -1. Units of each asset are created by decrementing the issuer location and incrementing another location. Your folder is a location for each asset that you hold.

You buy a location by exchanging "usage tokens", asset number 0, with the loom system. You must be given the location of some usage tokens to buy your folder and exchange locations. You trade with another user by one of you purchasing an exchange location, then moving funds from your personal folder to that location, and telling the other person the exchange location. You can then release the exchange location, and get back the usage tokens you used to purchase it, or continue to use it for exchanges with the other party.

The system allows you to assign names to locations, so that you can easily recognize them. It also provides transaction history, if you enable it.

Security is through secrecy of the locations. Given how hard it is to guess a 128-bit number, that's pretty good security. There's even an on-screen keyboard for typing location numbers, to make it harder for keystroke loggers. You're still trusting the security of https encryption, and, most of all, you're trusting the security and integrity of loom.cc. Caveat emptor.

I have not yet discovered any way to get an "invitation" location, containing usage tokens required to create your initial folder, though the e-gold vendors who use loom.cc will likely provide that.

Some of the articles about the Loom system say that it's open source, but I haven't found any links to the source. The grid itself could be implemented as a B-Tree, living in a single file, but Patrick Chkoreff likely used a commercial database.

Interesting links:

loom.cc news
loom.cc grid documentation
loom.cc archive documentation
loom.cc grid interface

dgcblog video tutorial
vertoro.com tutorial
PayPerCPM tutorial
StevensGold.com tutorial

DGC Blog Loom articles
Digital Money World Loom articles
DGC Magazine

CyberspaceATM, another Loom implementation
GoldNow, a place to buy usage tokens?