- Open-Transactions allows users to issue and manipulate digital assets. Users may create pseudonyms (public keys), issue currencies, and create asset accounts. Users can transfer digital assets securely between accounts (even a server cannot change balances or forge transactions.) Users can also operate "cash-only" (without accounts) for maximum anonymity.
- Open-Transactions supports a range of financial instruments, such as cheques, vouchers, and untraceable digital cash. These are all analogous to the same financial instruments that we all use at normal banks today.
- 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. OT also supports basket currencies.
- 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, just to prove their story in the event of a dispute. (Any system where parties cannot "prove their story" will eventually break down and fail.) Thankfully, this is not a problem in Open-Transactions, which proves everything using only the last signed receipt.
- NEW: Smart Contracts (scriptable clauses.)
- NEW: Client-side scripting, with full access to the OT Client API.
The real beauty of Open-Transactions is the as-yet-unwritten future of new ideas that you can build with it, and the future liberty and security of your children that you can help to protect by doing so, in a very real and tangible way.
Features: Untraceable digital cash, destruction of account history, Ricardian Contracts, a large variety of financial instruments, Smart Contracts (scriptable clauses), Markets, Basket currencies, unforgeable account balances, and more.
The basic principles of OT
Here's a good intro by the developer of OT, FellowTraveller from the Bitcoin Forum
The contracts are Ricardian-style contracts, and they are used to denote the servers as well as the asset types. Any new currency on OT is issued by the issuer uploading that currency to any OT server. (The currency will have the same ID across all servers.)
You can see a sample currency contract here. The functionality of OT is similar to Ricardo, which is described here (with pictures!), and here is the Ian Grigg URL on Ricardian Contracts.
Triple-Signed Receipts are employed so that servers are unable to forge transactions or change balances. (The server cannot forge your signature on the receipt. The receipt is the account.) The core transaction engine is designed in this way, so that the same protection is afforded to all instruments (such as market receipts, cheque receipts, etc.)
Destruction of Account History
For its core account system and financial instruments, Open-Transactions uses balance agreement and transaction numbers on every receipt, in such a way that the parties to any transaction can prove their balances, and which instruments are valid, without having to store their entire transaction history, and instead by simply producing their last signed receipt. I describe how it all works right here. A similar protocol (Truledger) is very well described here, with examples.
Untraceable digital cash
Open Transactions uses Chaumian Blinding to offer the untraceable cash. See a sample piece of OT cash and an article here. There are various digital cash libraries floating around out there. Currently I am using Lucre.
Many Financial Instruments
Cheques, Cash, Markets, Payment Plans (recurring), Withdrawals and Deposits, Account-to-account transfer, Receipts, Inboxes, Contracts, etc. More coming. See this for more details.
Instead of a centralized model, OT tries to federate its services wherever possible. For example:
- The same currency could be issued at multiple servers.
- The same currency would have the same ID across all servers.
- The same Nym would have the same ID across all servers.
- Server-to-server transfers are possible through the issuer, since the issuer already has a presence on every server where he's issued.
- Users can trade in basket currencies, which distribute risk across multiple issuers.
- (coming soon) OT Servers will implement voting pools for Bitcoin, meaning a hacker could not steal your Bitcoin from a server unless he'd also hacked 90 of the other servers in the pool, and gotten their private keys and their passphrases.
- A clever wallet software could distribute the assets of a single "account" across multiple servers, and abstract that away in the user interface.
Open-Transactions has recently had smart contracts implemented, using the ChaiScript scripting language which embeds into C++.
Bitmessage + Open Transactions
A very interesting thread started in BitcoinTalk here about joining the Bitcoin-based messaging system, Bitmessage, with Open Transactions to produce a completely p2p anonymous transaction system far superior to Bitcoin or Ripple in terms of security, anonymity and the power of financial instruments it provides. Here's some more links about it:
Here's another interesting conversation from the #agora channel about the potential merger.
- SERVER-TO-SERVER WIRING PROTOCOL
- CURRENCY CONVERSION PROTOCOL
- OPEN-TRANSACTIONS-TO-BANK PROTOCOL
- N: How will the Bitmessage app and OT apps run together? like will one be a plugin of the other or both run and use each other's API's?
- F: N you could make an OT plugin for Bitmessage, or you could make an App that uses the OT API and the Bitmessage API
- N: yeah I figured that was the two options but just wondered if one of those was already underway :-)
- F: which one are you coding ?
- N: um..... :(
- F: currently I am working on OT API and on iPhone app for OT.
- H: this document (local copy) is saying that these exchanger services, since they worked with liberty reserve are now property that the gov is seizing. so they are taking domain names of companies that worked as exchangers for LR. these are not the LR domains these are wm-center etc.
- F: I have hired a C++ architect who is doing all the C++ architecture and web architecture.
- F: I have hired an Objective-C coder who is working on the iPhone app
- F: I am working on the OT API and the iPhone app and the systray App
- F: I only just proposed the BM/OT thing a couple days ago
- F: I will have to hire more coders to do that, or open-source community will have to work on it.
- F: H I think it's very unfortunate about the Liberty Reserve situation, especially since I know the complete solution so that none of those people had to be arrested and have their domains confiscated. somehow they prefer prison.Here, BTW, is the solution:
- F: The solution is for the issuers to create colored coins which are backed in fiat.
- F: The issuers can comply with AML/KYC for all bank-wires in-and-out. (Buying and selling their own colored coins.)
- F: This way the issuer is not involved in any transactions at all, other than compliant bailments in/out of the system.
- F: The colored coins can then be issued onto Open-Transactions servers (by the users themselves) by uploading them into multi-sig voting pools on the blockchain, so that the servers can transact those coins without having to be trusted not to steal them. This layer is where all the actual market trading and payments would occur.
- F: This way the issuer is entirely divorced from the transaction processing, and -- similar to the Federal Reserve -- cannot be held responsible for how those monies are used after they have been released into the wild.
- H: similar in some aspects to the split of responsibilities with voucher safe
- F: yes definitely, and I'm an admirer of voucher safe, but the system above is much less vulnerable, and here's why:
- F: Let's say that an OT issuer, issues his gold-based currency onto an OT server.
- F: the issuer is not directly processing any transactions, so he cannot be held responsible for them...
- F: but you CAN put a GUN to his head, and make him STOP USING THAT SERVER
- F: That is the same problem with Loom, and the same problem with Truledger, and the same problem with Voucher Safe
- F: That is why I said, have the issuer FIRST issue his currency as COLORED COINS
- F: he ONLY buys/sells colored coins via BANK WIRES, and he FULLY complies with KYC/ AML
- F: then SEPARATELY from that, the USERS upload those colored coins to OT servers (into multisig voting pools)
- F: there they are transacted in a way that is TOTALLY divorced from the issuer
- F: and by "totally divorced" I don't just mean that the issuer doesn't process the transactions
- F: I mean the issuer never even talks to the OT server at all!
- F: In fact, he might never even KNOW about the OT server
- F: you CANNOT put a gun to his head and force him to stop using the server, because via the blockchain, he is TOTALLY divorced from it.
- F: Do you see? This is the solution!
- F: This is the ONLY solution.
- F: Liberty Reserve 2 and Liberty Reserve 3 are going to KEEP getting FUCKED until they do this.
- F: it will not stop.
See also the Free software brochure :-)