From Open Transactions
Revision as of 01:04, 16 January 2016 by FellowTraveler (talk | contribs) (updates to some old info)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search


Yes... we have the QT/C++ client GUI Moneychanger (Qt-based Desktop Client)


Is this the real stuff? With blinded tokens? As in, invented by David Chaum?

Yes, Open Transactions provides a full and working implementation of Chaumian blinded tokens. Specifically, the Wagner variant as implemented by Ben Laurie in his Lucre Project.

Here's an intro article on digital cash.

In the near future, I will also add Chaum's algorithm as well as Brands' -- Both are available in credlib. To do this, FYI, basically I would make new subclasses of OTMint and OTToken, which call credlib functions instead of Lucre functions. Then you could specify which algorithms you prefer, in your currency contract.


A user account is numbered (it consists of a PGP key), so in this respect, it is pseudonymous (meaning, transactions can be tied to each other, but not to your real-life identity, presuming you use I2P or Tor.) The benefits of pseudo-anonymity are that your online Pseudonym (or "Nym") has the potential to gain reputation over time, and also, that many more instruments become possible when using accounts: Cheques, transfers, payment plans, markets with trades, etc. (See the diagram)

Whether you use an account or not, The digital cash instrument itself is always untraceable, either way. Meaning, the server can see that account# 38272 exchanged a token, but it doesn't know what withdrawal the token originally came from, and it won't know where and when it will eventually be spent. (Because tokens are blinded when the server signs them, and the server only sees a token's ID after it has been redeemed.) In fact, the server doesn't even know if you're just exchanging the same token over and over again because you're bored. (To learn more about the mathematics, google about "Chaumian blinding".)

Then by adding an HTTPS cash-only interface (for token exchange), you gain full anonymity (as long as the user connects over I2P). But of course, in this case the user cannot use accounts, cheques, transfers, or cashier's cheques, since he is now operating "cash-only".

By full anonymity, I mean that all token exchanges, while already untraceable between the parties, are now additionally mixed with all of the other users' token exchanges (which are also being performed at the same cash-only interface), since the same user account is used for all of them (a dummy server Nym). There is also no record of any account balance changing, since no asset account is needed to exchange a token... and your real-life identity is hidden when connecting over an anonymous network. Here's a diagram of the fully-anonymous operation of OT.

If the OT server itself is running on a network such as I2P, then the server may also choose to hide its identity and physical location, if it so chooses. Issuers may do the same. (Of course, this does not solve issues of trust.)


Cash is the most accurate analogy.

When you withdraw cash from the bank, and then later someone else deposits it, the bank has a record of a withdrawal and a deposit, but they don't know that it's the SAME cash, and they don't know who had it in between, or how many hands it passed through along the way. They simply can't trace it. These traits are also true of digital cash.

The other digital financial instruments are much the same as their paper equivalents:

  • account transfer (a PGP-signed message, given directly to the bank, transferring funds to some other account),
  • digital cheque (a signed message, given to the recipient, authorizing bank to transfer funds when presented),
  • digital vouchers (like a cashier’s cheque. Funds are transferred to bank, who then issues a cheque. Bank becomes payer.),
  • digital cash (Like a real cash withdrawal. Funds are transferred to bank, who then issues blinded, untraceable, bearer certificates),

New: 2-way trades and re-occurring billing are also now functional!

Remember, physical cash is not the actual value, it is only a transfer mechanism. YOU have to trust your government that your physical cash is backed with real value. (Whether that is gold, or silver, or "their full faith and credit" or whatever they claim that their currency is backed with.)

Digital cash is ALSO NOT actual value, it is ONLY a transfer mechanism. YOU have to trust the issuer of that cash, and the contract he used to issue it, and decide whether you trust that it is backed with real value. There is no escaping this basic fact (of electronic trading of any good) -- someone has to store the actual gold, or whatever it is, that supplies the actual backing value to the currency. And that is why Open Transactions is designed as best possible to distribute risk across multiple issuers (through basket currencies) as well as distributing risk in other ways (across a federation of transaction servers, across a diversity of jurisdictions, etc)

In Open Transactions, anyone can issue a currency. But the users still decide what they want to trade and who they want to trust.

So I can just give myself 1000000000000 Weaselbucks and then I can pay you in weaselbucks?
Maybe I just don't get it.

Most users will not issue any currency -- they will merely trade in established currencies, or baskets of those currencies. But anyone could issue a currency if he wanted to -- and the market ultimately decides which currencies actually get used. Most likely the currency people will choose to trade in will be some sort of Pecunix or other digital gold currency, not "weaselbucks."

In Open Transactions, you can issue a currency onto multiple transaction servers (as many as you want.) A single currency can also have multiple issuers (via using basket currencies.) Users may choose to distribute their funds across a multiplicity of servers in a diversity of locations. A user's wallet software could even be written to have a list of servers, and do this distribution automatically.

Imagine an eco-system with various different entities...

Open Transactions is the software for the transaction server.

Anyone choosing to act as an issuer could connect to such a transaction server and issue a currency. (Or even operate his own server.)

MOREOVER, there will be a multiplicity of issuers and transaction servers, all operating in a diversity of jurisdictions. This is like the concept of "Federated Software" such as that proposed by the Diaspora project.

There are other entities in this eco-system as well. The exchange companies in the local markets perform the work of exchanging digital currencies for the local "coin of the realm." The exchanger, for you, might be your local coin shop. (Exchangers always pop up wherever there are multiple currencies. You could even buy chinese video game money right now, if you wanted to.)

Digital currencies such as Pecunix, E-Gold (or Bitcoin) could all be used as backing for currencies issued on Open Transactions. It's all up to the issuer, who may or may not also be one of those entities. Users will take advantage of baskets in order to distribute risk across their favorite issuers.


If you Google about "chaumian digital cash" you will find plenty of articles explaining it, including a good article from Wired.

In Open Transactions, when the client software withdraws cash, it constructs blinded prototokens and sends them to the server. The server debits the asset account, signs the prototokens, and then sends those tokens back to the client, who unblinds them. (Now they are now ready to spend.)

If you are an anonymous user connecting over Tor, then this step will occur through one of the server's exchange accounts, over an HTTPS interface specially set up for cash exchanges. (Meaning, you don't even need to have an account.)

Later, when the token is spent, the payee deposits it into his own account at the server. (Or exchanges it.) When he does, the server sees the Token ID for the first time; it has no way of tracing it back to the withdrawal. The server then stores the token ID into a spent token database, in order to prevent double-spending of the token.

You can see the full progression of the blinding code if you look here:

    else if (OTClient::notarizeWithdrawal == requestedCommand) // NOTARIZE WITHDRAWAL
    void OTServer::NotarizeWithdrawal(OTPseudonym & theNym, OTAccount theAccount, OTTransaction & tranIn, OTTransaction & tranOut)
    void OTClient::ProcessWithdrawalResponse(OTTransaction & theTransaction, OTServerConnection & theConnection, OTMessage & theReply) [The tokens are ready to spend now, and untraceable. Later, the client spends some tokens, by passing them to another wallet user. That payee deposits the tokens to verify them (perhaps immediately withdrawing again, if he just wants to exchange them for new ones.) The server has no way of knowing where the tokens came from, since they were blinded when they were issued. The server also has no way of knowing if the tokens represent a new payment to me from someone else, or if I am just exchanging and re-exchanging tokens that I already had, perhaps to fix an approaching expiration date. Below this point, that payee is now the client, since he now has the tokens...]
    else if (OTClient::notarizePurse == requestedCommand) // NOTARIZE PURSE (deposit)
    void OTServer::NotarizeDeposit(OTPseudonym & theNym, OTAccount & theAccount, OTTransaction & tranIn, OTTransaction & tranOut)

Also I suggest reading the OTToken and OTMint classes to see the actual Lucre calls being made.

Update: The Spent Token Database is now operational as well!


Bitcoin is a distributed, p2p-based cryptocurrency, and its properties are quite complementary with Open Transactions. Both systems seem to solve different problems and indeed they solve problems for each other.

Bitcoin gives OT: a universal "glue" between servers, a network of existing exchangers, and a publicly-auditable, reserve currency that cannot be confiscated or shut down.

OT gives Bitcoin: Chaumian cash, instant finality of settlement, a wide range of financial instruments, and convertibility to other currencies on OT Markets. (Coming soon: voting pools for safe Bitcoin storage on low-trust OT servers.)

In more detail:

Bitcoin Pros:

  • Bitcoin cannot be confiscated since there are no real-world assets backing it.
  • Bitcoin cannot be shut down since there is no central server. (Unlike Napster...)
  • Bitcoin is publicly auditable, meaning reserves of Bitcoin can be verified. (This is a benefit of Bitcoin, for using it as a backing reserve, but it means that anonymizing layers are still necessary.)
  • Bitcoin cannot be counterfeited. Bitcoin is curiously similar to gold: it's perfectly fungible, recognizable, limited, evenly divisible, liquid, costly to obtain, valued, useful for trade, useful as a store of value, and possession is control. That is impressive!

Bitcoin Cons:

  • Bitcoin cannot be used for issuing currencies based on different asset types. (It's better to think of the Bitcoins themselves as a commodity, which is available p2p in a public way, but which could also be exchanged untraceably on an OT server the same as any other commodity or asset type.)
  • Bitcoin is not untraceable by itself. (Due to being publicly auditable.)
  • Bitcoin does not feature immediate settlement. (It takes time for several blocks before your transaction is secure. Ten minutes to an hour.)

Opportunities: Since Bitcoin is publicly auditable, use it as the backing reserves for a currency issued on OT.

Now those Bitcoins can be used untraceably as OT cash. Plus, all of the other instruments become available, and they can have instant finality of settlement (with receipts, if you prefer.) There are cheques, transfers, invoices, payment plans, vouchers, etc. The BTC is also now easily convertible in-or-out of any of the other asset types traded on OT markets.

I would also like to point out that Bitcoin will probably serve as a "glue" between OT Servers and between various currencies, since it can be issued on any OT Server, and traded against all the other asset types on any server. This makes Bitcoin a universal medium as a result of its unique properties.

To prevent Bitcoins from being stolen from any single OT server, my proposal is to bail them into voting pools in the blockchain itself, so that 40 out of 50 other servers in the pool must verify signatures and vote before voting to release bitcoins and bail them out of the pool. (These servers must share audit data to make this possible. The concept is discussed in more depth here.)

NOTE: Some people have speculated that I might be Satoshi Nakamoto (creator of Bitcoin.) But I cannot take credit for his genius. Definitely: not me. The most likely candidate IMO is Wei Dai--but perhaps it will always be a mystery. OT will still greatly benefit from his invention, however. So thanks, whoever you are.


OT clients will end up as p2p software, since they derive benefits from comparing notes on the servers. An OT client could be written that is simultaneously a Bitcoin node, and even also a Ripple node as well. In fact, over the long time I think it will also merge with anonymous networks. I think there is a lot of potential for development on the client/wallet/anonymous-node side where all these sorts of technologies will start to be tied together.

I would like to see the server side of OT become completely distributed as well. However, I expect that in the near future this picture will more closely resemble a federated system such as that proposed by Diaspora. Remember that even Tor has directory servers, as well as special bridge nodes and relay nodes. An Open Transactions server would be a similar service, and could run hidden on an anonymous network, and could even profit while doing so, since OT makes anonymous profits possible. More importantly, this means that digital cash software like OT can help solve problems of resource allocation on anonymous networks.


OT, at a basic level, is client/server. (There must be a signer in order to have chaumian cash.) Contrast this with fully distributed digital commodities, like Bitcoin, which rely on block chains and therefore cannot be untraceable.

However, OT will end up with P2P Clients and Federated Servers. Here's why:

On the server side, my vision for OT is of FEDERATED servers, similar to DIASPORA or the FREEDOM BOX. That is, many servers, operated by separate entities, forming a single eco-system for all, but with no central point of failure. Just like Diaspora. (And those servers could run on anonymous networks. In the past, anonymous servers had no way of receiving payment, and thus remained the realm of enthusiasts and hobbyists--but OT solves this.)

This is already becoming the case. For example, Loom is operational, and we know it will not be the only transaction server in the world. Thus the same issuers will undoubtably issue the same digital assets on Loom AND other transaction servers simultaneously. Therefore we can already see that there will be multiple issuers, and multiple transaction servers, and that these separate entities will operate in a diversity of jurisdictions, and indeed this is already what is happening.

Because the SAME digital asset types, from the SAME issuer, will be available on MORE THAN ONE server, this means that transfers from server to server can be negotiated by the issuers directly, as well as by the users (via a Ripple-like protocol.) In other words, cutting the transaction servers themselves out of the loop.

For example, if I wanted to move some FT-Gold from Server A to Server B, then I don't have to involve Server A or B directly. Instead, I just make the request to FT-Gold, and THEY do the transfer, since they already exist at both ends.

Similarly, wallet users themselves can perform this function. They can even devise lists and rules about WHICH asset types they accept, and WHICH servers they trust, and how much of a cut they charge for exchange... allowing funds to "flow" p2p from user to user, even changing currency types along the way. (This is the whole idea behind Ryan Fugger's Ripple system.) So if I have dollars, and I want to pay someone who only accepts gold, then the Ripple just finds a "6 degrees of separation" between us through our friends, and converts the currency as it ripples.

I think that servers can also directly negotiate transfers to other servers. (Since they both have signed receipts from the same issuer, they can potentially negotiate the transfer between each other, from server to server, and drop the receipts into the issuer's accounts on both sides. This might require the issuer to run a server of his own for the transfer protocol to work, I have to think about it.)

This, btw, does NOT mean that the cash tokens from one server would be redeemable at another server. They would not: When a SPECIFIC TOKEN has been issued by a SPECIFIC SERVER, then that token must be REDEEMED at the SAME SERVER. This is because only that server knows for sure if the tokens are still good. But the funds can nevertheless flow rather easily between servers, as described above, once they have been redeemed.

I would also like to point out that Bitcoin will probably serve as a "glue" between OT Servers and between various currencies, since it can be issued on any OT Server, and traded against all the other asset types on any server. This makes Bitcoin a universal medium as a result of its unique properties.

ON THE CLIENT SIDE, the wallets ALSO NEED TO BE P2P! This is because the wallets need to COMPARE NOTES with each other on the various servers, TO KEEP THE SERVERS HONEST.

For example, if a server gave you a different public mint file than it gave to the other users, then your cash -- which you thought was untraceable -- suddenly becomes fully traceable. Therefore your wallet has a strong incentive to compare its copy of the public mint file (or a hash of that file) with the same data of other wallets on the p2p network.

The wallets will also need to be p2p due to the "Ripple" possibilities outlined above. Users will automatically earn percentage cuts for money flows through their wallets, and centralized sources will no longer be necessary for "wire transfers" as they were in the 20th Century.

EVERY TRANSACTION must be accompanied by a signed receipt containing a balance agreement. This means that in the event of a dispute, or if any specific transaction server goes down, ALL OF THE USERS should be able to present their LATEST SIGNED RECEIPTS to the issuer, and recreate their accounts.

Since the cash is untraceable, it becomes possible for transaction servers to run, AT A PROFIT, anonymously and untraceably, on an anonymous network such as I2P. (Meaning, even though a server is NECESSARY, and I can't currently get around that, it CAN BE HIDDEN, AND FEDERATED, and PAID FOR. Think of it like a Tor Directory Server or something.)

Just as the issuer on Loom does not actually operate the Loom server, so will the issuers who use various OT servers be able to operate independently of the server operation itself. Even unauthorized 3rd parties could issue their own "pecunix-backed" currency on an OT server(s) somewhere, if they wanted to--and it is up to the market to DECIDE WHO THEY TRUST.

A single currency can also be distributed across multiple issuers (using basket currencies.) A user might feel unsafe putting his currency in 100% pecunix. Perhaps he prefers 33% pecunix, 33% goldmoney, and 33% c-gold. That's fine! Users can define baskets and trade them on markets, etc, and distribute a single currency across multiple issuers. Even a hundred issuers! The basket currencies do not take any additional system resources, they are just another asset type ID the same as any normal asset type.

Another example of risk distribution: A nice wallet software can be designed to automatically distribute funds across MULTIPLE SERVERS. The little "pile of gold" that I see on the screen might actually be distributed across 10 accounts on 10 different servers. But this is seamless for me (LIKE DIASPORA) since transfers are possible between the servers, since the same issuers are available on multiple servers.

For the user it's as easy as making a list of the servers he trusts, and the asset types that he trusts, and the wallet can be programmed to DO THE REST AUTOMATICALLY.

So FYI, OT is NOT fully-distributed/p2p, and in fact cannot be so currently (the cash instrument needs a server somewhere in order to be untraceable), but it still has a vision for the DISTRIBUTION OF RISK and for solving THE NAPSTER PROBLEM (single point of failure.)


The first big difference is that E-Gold and Pecunix are actual companies, whereas Open Transactions is merely a piece of software, that could be downloaded and used by anyone.

As far as I know, e-gold and other outfits like it specialize primarily in one specific instrument: account transfer. Not cheques or cash -- only account transfer. (This means that none of them offer untraceable cash.)

Open Transactions supports account transfer, and digital cheques, and digital cash.

An outfit like Pecunix (btw, they are no relation to this project) could potentially use this software to issue cash backed in their gold. Also, there is nothing to prevent other, 3rd-party entities from issuing Pecunix or E-Gold backed currencies on an Open Transaction server. In that case, the issuer is merely a third party whose currency contract promises to be backed with [name your favorite digital gold currency].

In that case, people could simply connect to the server and trade those currencies, even without the direct involvement of entities such as E-Gold or Pecunix. It's now between the trader, the server operator, and the issuer (and the exchanger.) Pecunix, in this scenario, would serve as the backing for the currency, but would have no direct involvement with the operation of the transaction server itself (or, even, with the issuer, since the two could deal through the various exchangers in the various local jurisdictions.)


Loom was what inspired me that the issuers could be a separate entity from the server operator. The issuer, on Loom, is just another user, who has decided to issue a new currency. There might be hundreds of different currencies issued on Loom. This separation of powers is also used in Open Transactions. Congratulations to Patrick Chkoreff for his excellent work in developing Loom.


Ripple is a great idea from Ryan Fugger. The concept is that users can be socially networked and issue credit to each other. This makes it possible for funds to "flow" through users so that two otherwise unrelated parties, using two otherwise unrelated payment systems, can still send payments to each other, via a "six degrees of separation" through a social network of mutual friends. (Sort of like Hawala.)

I believe that Ripple, or something like it, will be built into a future version of the client software for Open Transactions (or something like it.) It's just obviously on the horizon, as far as I can tell. This will allows users all over to send funds into different payment systems without having to involve a central authority or do a wire transfer. Instead, the transfer will just flow through other users and cut out any "banking system transfer" entirely.

With users incorporating such software, it will no longer even be necessary to add "server transfer" features to Open Transactions. Users will do their own transfers using Ripple. I can't wait to see the first really cool client software that incorporates all of these ideas.


The Open Transactions protocol for account-to-account transfers is similar to the one in Truledger. Bill St. Clair made a big contribution with his work on Trueledger.

When using the ACCOUNT TRANSFER instrument (instead of cheques, or cash) these are the signatures that are received by all parties:

- Alice gets the server's signature on her transfer request (whether it is accepted or rejected, she still gets a signed receipt.)
- She gets Bob's signature (in her inbox) accepting her transfer when he processes his own inbox. \n
- She also gets the server's signature on that.
- She'll also get the server's signature on an agreement of balance at the same time.

- Bob gets Alice's signature sending the original transfer, which appears in his inbox. \n
- He also has the server's signature on that.
- Then, when he accepts her transfer, he will get a signed receipt from the server when his balance is updated.
- He will also have a signed balance agreement from the server at this time.

- The server gets Alice's signature on the transfer request.
- The server gets Bob's signature accepting Alice's transfer.
- The server gets Alice's signature acknowledging Bob's acceptance (when she removes his accept notice from her inbox.)
- The server will also have Alice AND Bob's agreement on both of their balances, allowing the server to destroy any other records.

Not to complicate things, but on each of the above (on each balance agreement), there is also:
- a list of transaction numbers still outstanding (signed out by the Nym).
- a list of pending transactions, and signed receipts, awaiting approval in the inbox.
- ...and a similar list of pending outgoings (in the outbox.)

You can see why we call it "Triple-Signed Receipts" for account transfer!

For more info, check out Bill St. Clair's document: [1]


Ian Grigg has commented that Open Transactions is along the same lines as Ricardo.

Open Transactions has definitely adopted the Ricardian Contract form, which is one of his innovations.


eCache is an actual, anonymous internet bank, whereas Open Transactions is the sort of software that such a bank might run. (As a library, OT has many more uses than this, but this is a pretty good description for the OT server software.)

As far as I know, eCache supports a "Tor / HTTPS, Cash-Only Interface" like the one described in this FAQ, and their users exchange bearer tokens through it, backed in gold and other precious metals.

(What actual software they use over at eCache, and their math implementation, I have no idea -- I haven't seen their code.)


This is easy: the server operator just provides an HTTPS interface where people can paste their tokens and receive new ones. This way the super-paranoid people can still exchange tokens all they want without creating an "account". (Notice that it must be the server operator who provides this interface, otherwise you now have to trust the interface provider.)

Keep in mind, that an "account" on an Open Transactions server is not like an account at a bank. It's just a communication key. It consists of ONLY a PGP public key -- and its primary purpose is so the server can encrypt your replies before sending them back to you. You can open as many "accounts" as you wish, and each of these can open as many asset accounts as you wish, and you can connect to them over Tor, and...

Here is the most critical part: even if you use an account, which you don't have to do, digital cash is STILL UNTRACEABLE. The blinded tokens can be withdrawn and deposited at will, (in fact that's all an exchange is) and the server cannot trace where they came from or who you will spend them to. Cash is like this whether you use an account or not.

In fact, even if you exchange a thousand tokens, the server doesn't even know whether you are just exchanging the same token over and over again a thousand times or whether it is actually a new token each time. And it has no idea where it came from.


If I write you a cheque for $50, and then you present it at the OT Server, (at that time selecting a specific account to deposit it to) then the server will take $50 out of my account (the one the cheque is drawn on), and put $50 into your selected account.

Whereas if I write you a cheque for -$50 (NEGATIVE 50!), and then you present it at the server (at that time selecting a specific account to pay it from), then the server will take $50 out of your selected account, and put it into my account (the one the invoice is drawn on.)

So it is the exact thing happening either way. The only difference is, when you use a negative amount, the functionality mirrors that of an invoice, so I decided to allow negative amounts on a cheque (the wallet software should know to display such instruments as invoices, as opposed to regular cheques, since it can see the amount.)

Negative transfers do not occur with any other instrument, such as payment plans, markets, cash, and account transfer. They are only allowed with cheques, because the functionality is so useful on both sides (and requires voluntary signing and submission on both sides in order to be processed, in any case...)


-- The Open Transactions library itself is entirely agnostic to transport! All messages serialize to a string and you can transport them however you wish.

-- The Server, API, and Test Client currently use the ZeroMQ library for all transport.

-- This code is easy to swap out, due to its localization to a single callback.

-- The library does all the heavy lifting of generating and processing the OTMessages.

-- In most cases, the developers will make easy calls to the API, which abstracts away the lower-level HTTP calls (that are being made behind the scenes to transfer the messages.) Instead the developer uses higher-level functions like "Withdraw Cash" or "Write Cheque."


  • Internally, the software uses signed XML contracts nearly exclusively, and is agnostic to where and how they are stored.
  • All of the classes serialize to a STRING
  • There is also an OTStorage abstraction used throughout the library, which is capable of storing and retrieving plain strings, binary data, and data objects from "OT local storage".
  • Binary data is compressed and packed to architecture-neutral formats. Msgpack and Protobuf are both supported packers (based on compile-time and run-time options.)
  • OT comes with a default subclass of OTStorage (OTStorageFS) that reads/writes to the filesystem. But by providing your own subclass, you can change OT to use any storage location you want.
  • OT Storage paths are usable as keys or as filenames. So "nyms/a6b123874ef2v1cc3.nym" could be the key in a table instead of a filename on a filesystem.
  • I assume this will eventually move towards some distributed db or "data haven". I would like to integrate with such a project. (This is another great opportunity IMO -- integrating digital cash with distributed data stores and anonymous networks.)

Feedback? Anyone?


FellowTraveler, does your blinded digital money work like Chaum's, in that a double-spend reveals the identity of the double-spender (in as much as a public key is an identity...)

The answer is NO.

When digital cash is issued, a blind signature is employed, meaning that at redemption, the server can see that the cash is good, but it has no way of knowing which withdrawal it actually came from. (If you continually exchange the same cash token over and over again, the server simply cannot tell whether it is the same token every single time, or whether it is a completely different token each time. It simply cannot see where the token originally came from.)

Once a token is spent, then the server CAN see its actual Token ID, which it records into a spent token database. If someone tries to double-spend that token, the server will refuse to accept it because it is already recorded as spent. While the server cannot see the perpetrator, it does have the potential to access the ID of the other victim who deposited it before you tried to (assuming, that is, that such info is stored in the spent token record, and assuming that an anonymous cash-only interface wasn't used) which may help in tracking down the perpetrator in real life.

Right now, Open Transactions does not store the User ID of the depositor. (Even if it did, this couldn't prove who or where he got it from.) If the token is still good, then the deposit or exchange will be successful, and in the case of an exchange, the user will be issued a replacement token, which is again, untraceable, and now only he knows the token ID of it, since it is new and blind-signed. At this point no one else can possibly spend it but him.

If a merchant receives a token from someone, and tries to exchange it, and the server refuses it (because it was found in the spent token database) then in this case, while you may see the victim (the merchant) you cannot see the perpetrator who originally withdrew it. This is untraceable.

So what could be done?

What the server could do is leave a notice in the inbox of the victims, warning them that a certain piece of cash they ALL tried to process was double-spent and fraudulent, and via this, try to find out the common source of the cash in real life, (if that was the server policy to do such a thing.)

Although this could possibly lead to the perpetrator in real life, it will probably not ever be necessary. In practice, this will not be a problem: No one will ever accept cash in the first place without exchanging the tokens first to validate and secure them. In other words, if you are standing in front of me, or if I am selling to you online, I will obviously not accept your cash (or your purchase) if the cash doesn't validate with the server. Instead, I'll simply refuse the transaction.

Similarly, if you are somewhere else on the internet, then we are probably communicating through a "cash streaming protocol." As soon as the little pieces of digital postage stop verifying, then I will stop serving you the high-speed anonymous download that you were doing through my computer's anonymous network node.


GOOD NEWS: Open Transactions is now available for Linux! Make sure you download the latest version of the code.


GOOD NEWS: Open Transactions is now available for FreeBSD!


GOOD NEWS: Open Transactions is now available for Windows!


GOOD NEWS: Open Transactions is now available for Android!

All supported platforms come with easy makefiles, project files, and instructions.

RUBY / PYTHON / PHP / Java ?

Open Transactions now comes with Native APIs for:

Java, Ruby, Python, Perl, PHP, C, C++, Obj-C, C#, Tcl, and Lisp.

Open Transactions was written in C++ because Lucre itself is written in C++ and Java, and Open Transactions was originally conceived as a usable wrapper for Lucre. (Lucre is what does the actual math for the Chaumian properties of the digital cash.)

How about portability?

The software now builds and runs on Mac OS X, FreeBSD, Linux, Android, and Windows. It also comes with Native APIs for many languages (see above.)


You deserve praise for Open-Transaction, a most valuable piece of work. Unfortunately however, for various software engineering reasons, (integration, portability, reliability, ease of verification...) it should have been a C (not C++) library. (If it was, I would probably start right now implementing something 'operational' based on it).

My questions are:
1) would you consider turning main components of it into C?
2) would you assist someone attempting to do the same?

Thank you for your kind words.

I don't think I could spend the time rewriting it in C unless there was some money in it for me. (I just can't afford to burn another 2 months of my life.)

However, it shouldn't be too difficult to convert...

  1. The library doesn't use any exception handling -- it's all return values.
  2. I would convert the class members to a struct.
  3. I would convert the class methods to normal functions, with an additional "this" pointer passed in (for the struct)
  4. Have to make sure to call the constructor / destructor by hand whenever a struct is created or deleted.
  5. Is there anything else? Historically, C++ was processed into C code before compilation, so it seems to me that you should actually be able to download a TOOL that will convert the code FOR you. That would probably be the fastest/easiest and would enable to keep the two versions current with each other.

I see this software more as a standard than as an implementation; I'd love to see different versions of it released in different languages, I just can't afford to write them all myself.

One more thing: I mainly wrote this code in order to make Lucre (the blinded token portion) available for actual use (instead of just being a demonstration of the math.) And the Lucre library (by Ben Laurie) is also written in C++ (and Java.)

So Lucre itself would also need to be converted, whether by hand or using a tool.

NOTE: There is now a C function API that comes with Open Transactions.


The OTToken class was originally designed for cut-and-choose, because I mistakenly thought it would be necessary with Lucre. You can read more about that "here.":http://wiki.github.com/FellowTraveler/Open-Transactions/lucre-and-denominations

Basically, Open Transactions does not need cut-and-choose in order to still have effective blinding and thus, still be untraceable. However, the library DOES support cut-and-choose, since it was originally designed under the assumption that it would be necessary. Pretty cool, huh?


I would like to incorporate as many different digital cash protocols as possible into this software. If you have some good code in C or C++, I would love to check it out. I would like to see the community eventually add whatever new protocols they wish to the software over time, so that it supports all the top algorithms and protocols. (JUST LIKE PGP -- THAT'S THE IDEA.)

In the near future, I will also add Chaum's algorithm as well as Brands' -- Both are available in credlib. To do this, FYI, basically I would make new subclasses of OTMint and OTToken, which call credlib functions instead of Lucre functions. Then you could specify which algorithms you prefer, in your currency contract.


The data is always either encrypted, or just base64-encoded.

If the data is only base64-encoded, then type "decode" and paste the data. Now hit enter and you will see the decoded contents.

But if the data is encrypted, it will probably start with 3 A's ("AAA"). Type "decrypt" on the command-line (testwallet). Now paste the data and hit enter. The decrypted data will be displayed on your screen. This will only work if the nym is loaded (as long as you have typed "load" you'll be fine.)


The mint must be generated separately from the server process. (Otherwise the server would freeze up for 10 minutes while the keys are being generated.)

Thus, there is a separate utility called "createmint.exe" located in the transaction/data_folder directory. Run it for instructions. It may ask for specific IDs, which can all be found inside this file: transaction/data_folder/notaryServer.xml

Eventually the server will automatically spawn createmint as a separate process whenever it needs to, but for now, you have to run it by hand if your mint has expired.

The Moneychanger GUI is smart enough to check the expiration date on any Mint, and download the latest version if it's expired.

(Why do Mints expire, you ask? Because otherwise the spent-token database would become a maintenance nightmare, where server operators are forced to store an ever-growing database--forever!)


Look in the Open-Transactions/sample-contracts folder: The .otc files ARE SIGNED. The .xml files are NOT signed.

(Otherwise they are identical.)

The public key of the issuer must be INSIDE the contract. (In the sample contracts, it's the first key that appears.)

The contract must be SIGNED with THAT SAME KEY.

Go to Open-Transactions/testwallet/data_folder and you'll find a file called signcontract.exe, which you can use for signing contracts. You can also use the testwallet.exe (command line utility) to sign contracts. Soon a "contract signing page" will be added to Moneychanger, but I haven't gotten around to it yet.

Warning: Since the contract's ID is usually a hash of the contract, then you will obtain an entirely different ID if the contents are changed by even one bit. As a result of this, contracts are VERY FICKLE ABOUT WHITESPACE! There should be no whitespace before the contract, in the contract file, and neither should there be any whitespace after it, except for a single newline at the end of the dashline (the bottom line of the signature.)

The GUI will make this easier in the future by stripping whitespace as appropriate before generating the ID.


  • Transaction fees can easily be added, since transactions consist already of multiple items in a list.
  • He can also make money from expired vouchers and expired cash, which both revert to the bank.
  • He could issue a fractional reserve contract and make money from investments...
  • The OT server also supports usage credits (charging by API call.)
  • See the Business Cases page for more on this...


The various components of Open-Transactions were released in June 2010 under the AGPLv3 license.

Open-Transactions has since been re-released in 2015 under the MPLv2 license.