End the War on Freedom

Trubanc is an anonymous, digitally-signed vault and trading system. Like Loom, it allows anyone to issue assets (digital currencies). Unlike Loom, which relies entirely on (very good) obscurity for security, Trubanc's digital signatures allow the bank and the customer to prove to each other that they agreed at a particular time on their balances. It does this while allowing destruction of transaction history for closed trades. Trubanc will initially provide server-based trading. Eventually, it will provide digital checks and bearer certificates.

I started working on Trubanc in August of 2008. I announced a public beta of the PHP implementation in December and added storage fees in March of 2009. In late March, I started converting the PHP to Common Lisp. Today, I'm announcing the first public beta of that implementation. Trubanc.com is now running the Lisp client and server, and you can download the client/server binary, and use it on your PC as a client, or on your own server, as your own Trubanc.

The client binary works in Windows, Linux, FreeBSD, and Mac OS X. I haven't yet built all 8 combinations of 32/64 bit and OS, but I've built the ones most requested by my early testers, and will build the others on request.

Client binaries are at trubanc.com/download. Client installation and usage instructions are at trubanc.com/client.html. Server installation and configuration instructions are at trubanc.com/server.html. Please help me test it.

After you've installed the client, send email to bill at billstclair dot com, encrypted with my PGP public key, and including yours, if you want privacy, and I'll send you a coupon with some usage tokens for a test account.

NuBux has got to be the simplest account interface imagineable. Register with an email address and password, and it gives you $1,000 to play with (demo system, obviously). You can spend to other email addresses, see a list of your transactions, and inspect each individual transaction. That's the whole thing. Open source. MIT license. A product of Pelle Braendgaard and Stake Ventures Inc.

Patrick Chkoreff has installed Version 86 of the Loom digital vault and payment system. He's done a number of user interface improvements, making it easier to add contacts and assets, and to invite new users to Loom. Bravo!

I have added storage fees to Trubanc.

One of the drawbacks of Loom is that there's no way to make money from Loom itself, except for small amounts of one-time income from new users for asset tokens. In order to make Trubanc a money-making proposition for the asset issuers, I have added storage fees. I expect that most Trubanc assets will be backed by precious metals in storage. It makes sense for the issuer, who must pay for the space and security of that storage, to be paid a small periodic fee. He can now set a yearly percentage rate charged for all users of his asset.

I'm going to describe the new feature with an example. I'm assuming two users, John and Mary. John creates a gold-backed asset, named "John GoldGrams", with a storage fee of 1%. The market will determine how much storage fee is viable. The Free Lakota Bank charges 1/20,000 per month, or 0.06% per year. C-gold charges 1% per year. E-gold too. Trubanc allows the asset issuer to decide what to charge, and to change it at any time.

Rather than keeping track of an average monthly balance, and assessing the storage charges monthly, Trubanc includes storage charges in every transaction, paid by the holder of the asset. So when you make a spend, you pay the fee on your original balance for the amount of time it's been there. And when you accept a spend from someone else, you pay the fee on the accepted amount, for the time that it's been in your inbox. Trubanc keeps fractional amounts on fees, so that these small amounts can add up for the asset issuer.

John creates his new asset:

To change the fee, fill in the new fee, and press the "Update Storage Fees" button:

Mary sells John her old car, and elects to take payment as 100 John GoldGrams. Here's her inbox after John spends the 100 grams to her:

After accepting the 100 gram spend, in the time it took me to write this, Mary has already lost a little to John's storage fees. She's paid less than 2 hundred thousandths of a gram, about 6 hundredths of a cent, some gold dust:

Mary pays John a gram for a few old CDs, and she loses a little more gold dust:

For the asset issuer, received storage fees are shown under the outbox. Here's John's account after Mary accepts the 100 gram spend and spends back 1 gram:

Clicking the "Move to Inbox" button moves the received fees to the inbox as a spend from the bank for "Storage fees":

Clicking the "Process Inbox" button receives the 1 gram for the CDs plus the gold dust for Mary's storage fees:

There's one more feature I haven't implemented yet. What I demoed above collects fees when balances change. In order to collect storage fees on balances that change infrequently, the asset issuer will be able to run a periodic batch job that visits every account, collecting fees since the last batch job was run and posting them as negative spends (remember, Trubanc can't change a user's balance without his digital signature approving the change, but it CAN post a bank charge as a negative spend).

This code is live at trubanc.com/client. If you want to play with it, just ask, and I'll give you a coupon to create an account or three.

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.