About

About the Open-Transactions project. Financial cryptography software. 73 articles.

What is Open-Transactions?

• Open-Transactions is an easy-to-use, financial crypto, digital cash and transaction library.
• Open-Transactions is open-source. Monetas, the biggest sponsor of Open-Transactions development, is also developing a commercial enterprise version.
• Open-Transactions includes a client API, a working server, a GUI test wallet (in Java) and a command-line wallet utility.
• Open-Transactions features: a large variety of financial instruments, markets, basket currencies, unforgeable account balances, digital cash, destruction of account history, Ricardian contracts, Smart Contracts (scriptable clauses), and more.

What does it do?

• Open-Transactions allows users to issue and manipulate digital assets.
• Any issuer can sign and distribute new currency contracts in order to create new digital asset types.
• Users may create many pseudonyms (public keys), each of which may own asset accounts of various types, on OT servers.
• Users can operate "cash-only" (without accounts) for maximum anonymity, using unlinkable digital cash.

Financial Instruments

• Users can transfer digital assets securely and provably, with receipts signed by all parties.
• Even an OT server cannot change balances, or forge transactions--since it cannot forge your signature on your receipt.
• Open-Transactions supports a range of financial instruments such as account transfer, cheques and vouchers (aka "cashier's cheques" or "banker's cheques"), in addition to cash.
• These instruments are all analogous to the same financial instruments that we all use at normal banks today. Everyone already has an intuitive understanding of these financial instruments, because we use them regularly in our normal daily lives.

Markets, Basket Currencies, and Smart Contracts

• Open-Transactions also implements higher-level, contract-based transactions such as payment plans and markets with trades.
• The markets on Open-Transactions support market orders, limit orders, fill-or-kill orders, day orders, stop orders, and stop limits, just like trading on a real market.
• Basket currencies are also supported, as well as payment plans (recurring payments.)
• Smart contracts: Multi-party agreements with scriptable clauses... including hooks, callbacks, internal state, etc.
• Client-side scripting: !/usr/bin/env ot The entire (mostly) high and low level OT API is available within your scripts.

Triple Signed Receipts

• All of this is accomplished in such a way that all parties are able to prove, at all times, which transactions have cleared and which instruments are authorized, without having to store their entire transaction history, but instead by merely keeping the last signed receipt.
• Without the special mechanism that makes this possible, all parties would otherwise be forced to store all receipts forever.
• Nyms and Asset Types have consistent IDs across all OT servers, since the ID is formed by hashing the relevant contract or public key.

Diagrams

Voting Pools

Architecture Overview (new)

Architecture Overview (old)

Financial Instruments  

Radio Interviews

"Trust No One" Miami Speech

AgoristRadio Interview, Part 1

AgoristRadio Interview, Part 2

Interview with "Let's Talk Bitcoin"

Interview with FutureMoneyTrends.com

Video Walkthrough

Desktop video 1 - Introduction

Desktop video 2 - Advanced

iPhone video 1 - Introduction

iPhone video 2 - Advanced

java testclient video 1

java testclient video 2

Official video archive (more videos)

---

Bitcoin donation address: 1NtTPVVjDsUfDWybS4BwvHpG2pdS9RnYyQ

IRC: #opentransactions at irc.freenode.net

Mailing list: [email protected]

Subscribe to mailing list

Components and GNU Licensing

---

Is Open-Transactions centralized?

The vision is not of a central server that you must trust. Rather, the vision is of federated servers you don't have to trust.

---

Potential vulnerabilities of Open-Transactions

Related Systems

Monetas - Enterprise platform based on OT.

---

Bitcoin - A censorship-resistant global ledger

Loom - Asset issuance and transactions

Magic Money - PGP-based Chaumian blinding (unlinkable cash)

OpenCoin.org - REST-based blinded tokens

OpenTransact - REST-based transaction protocol

PaySwarm - REST-based transaction protocol

PKTP - Public-Key Transaction Processor

Ricardo - Transaction system by Ian Grigg

Ripple - Consensus-based debt ledger

Truledger - Destruction of account history

Voucher-Safe - Secure asset issuance with auditing

---

Article: Toward a Private Digital Economy

In More Detail...

The server itself is a transaction processor in the cypherpunk tradition. In more detail:

• Many financial instruments are supported: Users can write cheques, purchase cashier's cheques ("vouchers"), and withdraw in unlinkable digital cash. The software uses Chaumian-style, blinded tokens courtesy of the Lucre library by Ben Laurie.
• It's like PGP FOR MONEY. The idea is to have many cash algorithms, not just Lucre. I’d like to add Chaum’s version, Brands’ version, etc. So that, just like PGP, the software should support as many of the top algorithms as possible, and make it easy to swap them out when necessary.
• User accounts are pseudonymous. A user account is a public key. (This is like PKTP by Andrew McMeikan.) You can open as many user accounts as you want. Full anonymity is possible only for "cash-only" transactions (where users only perform token exchanges, and do not open accounts), whereas pseudonymity means that transactions can be linked to the key that signed them. (While the real life identity of the owner is hidden, continuity of reputation becomes possible.) See full-color diagrams linked above.
• Any user can issue new digital currencies and digital asset types, by uploading the new [currency contract] to the server. (This functionality is comparable to Ricardo by Ian Grigg.)
• Users can open asset accounts of any type. You can have as many as you want, associated with each user account. (See Loom by Patrick Chkoreff.)
• Triple Signed Receipts / No Account History. On OT, entities are able to conduct transactions, verify instruments, and provably agree on current holdings via signed receipts, all without the need to store any transaction history. An asset account on OT is not according to the traditional sense of the word (an account normally being thought of as, "a list of transactions, with a balance, used in double-entry bookkeeping.") While the word "account" makes things easy to understand, an asset account on OT exists only in the mind of the account holder himself. He simply asks the server to agree with him that it exists, and to provide him with a signed receipt to that effect. In the user interface, OT is able to mimic the account metaphor, making usage intuitive, even though no actual account exists, or need be stored on either side, other than the signed receipt itself! (See Bill St. Clair's excellent Truledger for an example of this concept.)
• Open Transactions also features markets. Any two asset types can be traded against each other. The markets are full-featured and include limit orders, stop orders, fill-or-kill, day orders (date ranges), and stop limits.
• Open Transactions also supports basket currencies. Users can define their own, and the server handles the process of exchanging in and out of basket accounts. Baskets are treated by the software like any other asset type, (you can open accounts, transfer funds, withdraw cash, write cheques, and even trade basket currencies on markets.)
• Smart contracts: Multi-party agreements with scriptable clauses... including hooks, callbacks, internal state, etc. This concept was originated by Nick Szabo: smart contracts.
• Client-side scripting: The entire OT API is now available for use in OTscripts on the client side. Just remember to put this at the top of the file:

  #!/usr/local/bin/ot --script

• Open Transactions also supports payment plans. Users can sign contracts with each other, and the server will carry out the terms and implement the payment plan. (A future goal is to issue new asset types based on revenue from payment plans--so they can also be traded on markets.)
• Contracts, in general, are very important to Open Transactions; they are the building block of the entire library. Open Transactions uses a Ricardian-style contract, and all the various instruments, data files, and messages resemble PGP-signed XML files. All objects serialize to a string.
• The philosophy of the software is based around separation of powers (issuers and transaction servers being separate entities) as well as the distribution of risk. For example, Asset accounts can be distributed across multiple servers, and asset types can be distributed across multiple issuers (via baskets.) Read about the Auditing protocol.
• Potential future instruments include: Real Bills, dividend-paying stocks (the same mechanism can be used as interest paying bonds) and collateralized debt obligations. (OT supports payment plans, so it would be easy to group tranches of OT's payment plans to pay into a single reserve account, as backing for a new stock offering that could be traded on OT markets.) This is similar to how basket currencies are implemented. Stocks/Bonds would pay shareholders by dropping a cheque into your stock account's inbox. These features aren't available yet, but they are easy to add given the existing OT infrastructure.
• All communications are secured with OpenSSL. All messages are also signed and encrypted. All transactions require signatures from relevant parties including the server.
• Open Transactions is open-source, written in C++, object-oriented, and includes Native APIs for Java, Ruby, Python, PHP, Perl, C, D, C++, Objective-C, C#, Tcl, and LISP. (Also supporting JRuby, Jython, Scala, Clojure, Groovy, and any other language that works on the JVM.)
• The software is fully cross-platform: Linux, Mac OS X, FreeBSD, Android, and Windows are supported with makefiles, project files, and instructions.
• STORAGE... The library itself is storage neutral, and could be utilized across a variety of different storage systems. All objects serialize to a string, and it is very easy to add support for new storage methods. (Currently OT uses the filesystem with key/value pairs.) Adding a new storage method is as easy as subclassing OTDB::Storage and overriding a few methods. Use any DB you want.
• Messaging... The library itself is transfer-protocol neutral, and can be utilized across a variety of different transfer protocols. The default implementation uses the ZeroMQ library for transport. Transport is implemented as a callback function, so it's very easy (a few dozen lines of code) to swap in some other system, if you wish.
• OT currently supports MsgPack and protobuf for data packing, though new packers can be added by subclassing OTDB::Packer.

The intention is for this software to be integrated as many places as possible... Games, digital cash wallets, distributed data stores, secure voip apps, anonymous bit torrent networks, mixnets, remailers, nym servers, etc. There are many other potential uses.