Open Transactions - User contributions [en]

File:Metier-screenshot.png

2021-03-01T22:23:02Z

FellowTraveler:

Main Page

2019-07-21T19:34:32Z

FellowTraveler:

== Open-Transactions ==

'''[http://www.opentransactions.org/open-transactions.pdf Click here for white paper.]'''

The Open-Transactions project is a collaborative effort to develop a robust, commercial-grade, fully-featured, '''free-software toolkit''' implementing the [[OTX|OTX protocol]] as well as a full-strength '''financial cryptography''' [[List_of_Classes|library]], API, GUI, command-line interface, and prototype notary server. The project is managed by a worldwide community of volunteers that use the Internet to communicate, plan, and develop the Open-Transactions toolkit and its related documentation.

===Financial Cryptography===

Financial cryptography means using using strong cryptographic techniques to create secure financial instruments, such as digital signing to create non-repudiable contracts, and encryption to create untraceable digital cash. In OT, transactions are unforgeable, receipts are destructible, and balances cannot be falsified or changed without user consent. OT is able to prove all balances, as well as which instruments are valid, and which transactions have closed, without storing any history except the last signed receipt.

Open-Transactions implements financial instruments as Ricardian Contracts; contracts which can be understood both by humans and manipulated by software.

All contracts in Open-Transactions use the same basic structure: all parties involved sign an agreement which is notarized by an independent third party witness. This technique is known as [[Triple-Signed Receipts]]. Importantly, transactions are formed and signed on the client side first, before being notarized by any server. An OT client is thus ensured that an OT notary server cannot falsify his receipts against his will, since the server can't forge the client's signature.

This basic structure can be built upon to create many types of financial instruments.

===Financial Instruments===

Financial instruments are any representation of a financial agreement between two or more parties.

The simplest financial instrument is a deposit agreement. A custodian of some asset (legal tender, or maybe gold) stores it on behalf of a depositor and agrees to redeem it on demand when presented with proof of a valid claim on the asset.

Other types of financial instruments include securities, of which there can be many variations. A security is an instrument that entitles the bearer to a certain revenue stream, either because it represents a loan or perhaps because it represents equity in a business.

Financial instruments in Open-Transactions have an issuer, who creates the contracts and is responsible for fulfilling the terms, and one or more bearers. Financial instruments are liabilities of the issuer owed to the bearers.

===Working with Financial Instruments===

Open-Transactions is designed to provide the highest security possible for both the issuers and bearers of financial instruments. Servers in Open-Transactions act as notaries which can witness and confirm balances, but cannot change them. Every party associated in a financial instrument can prove their balance to any other party, and no party can alter the balance of any other party without their agreement. Even a malicious notary cannot do this.

Open-Transactions represents quantities of a given unit type as deposit agreements, which are signed by the bearer and a notary.

Portions of a balance may be transferred between users via several asset-independent transaction types, including:

; Transfers
: An atomic movement of funds from one account to a different account, like a bank account-to-account transfer.
; Cheques
: A payment which is not deducted from the sender's account until the recipient claims it.
; Vouchers
: A payment which is deducted from the senders account at the time of creation.
; Invoices
: A payment request which the recipient can opt to pay from any of his accounts.
; Cash
: Anonymous cryptographic tokens which can be securely redeemed by the recipient without revealing the sender.
; Market offers
: Open agreements to exchange a given quantity of one instrument type for a given quantity of another instrument type.
; Smart Contracts
: Customizable agreements between multiple parties, containing user-defined scripted clauses, hooks, and variables.

==Use Cases==

===Encouraged use cases===

Encouraged uses cases are officially supported by Open-Transactions.

====Deposit accounting====

Entities that hold assets on behalf of depositors can use Open-Transactions to issue promissory notes as negotiable instruments.

Examples of such depositories includes:

* Precious metals
* Central bank currencies
* Cryptocurrencies

====Payments====

Users of OT negotiable instruments can authorize recurring payments to pay for services which operate on a billing cycle.

====Bearer Securities====

The negotiable instruments created by Open-Transactions can be used as the basis for financial products such as loans.

===Discouraged use cases===

Discouraged use cases are not supported by Open-Transactions, either because they violate the security requirements, or because they conflict with the philosophical goals of the project.

In many cases, discouraged use cases may be achievable, but users are required to create and support their own smart contracts.

====Third party balance editing====

The only entity in Open-Transactions that can edit a balance is the holder of that balance receipt. Open-Transactions does not and will not include any functionality to bypass this design decision.

------------------

=== More Information ===

[http://opentransactions.org/wiki/index.php/About About Open-Transactions]

This product includes software developed by Ben Laurie for use in the [https://github.com/benlaurie/lucre Lucre] project.

Credit for the OT logo goes to: [http://www.michpalmer.com/ moltenmich]

=== Mailing list and IRC ===

Mailing list: ot-dev@opentransactions.org

[http://opentransactions.org/mailman/listinfo/ot-dev_opentransactions.org Subscribe to mailing list]

IRC channel: '''#opentransactions''' on irc.freenode.net

=== Sponsors and Contributors ===

The OT community gratefully acknowledges the support and contributions of the following individuals and businesses to OT development: Chris Odom, Cameron Garnham, Randy Waterhouse, [[Monetas]].

=== Install Programs ===

[http://nightowl.cc/Moneychanger.dmg Mac OSX install for Moneychanger GUI] Self-contained.
<br />Note: This Mac install of Moneychanger includes the notary server as well.<br />It can be found at: /Applications/moneychanger-qt.app/Contents/MacOS/opentxs-notary

[https://bitcointalk.org/index.php?topic=77301.msg859040#msg859040 (old) Windows binary installer ]

=== White Paper ===

[http://www.opentransactions.org/open-transactions.pdf Open-Transactions White Paper]

=== Source Code ===

[http://github.com/Open-Transactions/opentxs Open-Transactions source code on github] (core library, client API, and 'opentxs' command-line client)

[http://github.com/Open-Transactions/opentxs-notary Notary server source code on github] (Install OT core first)

[http://github.com/Open-Transactions/Moneychanger Moneychanger GUI source code on github] (Install OT core first, and then build Moneychanger with the latest version of Qt Creator)

Monetas

2016-01-17T06:37:05Z

FellowTraveler:

Monetas is a software company based in Zug, Switzerland, that was cofounded by Chris Odom, the creator of Open-Transactions. [http://www.opentransactions.org/open-transactions.pdf (Click for white paper.) ]

Chris Odom [http://opentransactions.org/forum/index.php?topic=11922.0 stepped down] from Monetas in March 2015 and [http://opentransactions.org/forum/index.php?topic=11925.0 cofounded] [http://stashcrypto.com/ Stash]. He said, ''"When I cofounded Monetas in 2012 with Johann Gevers, our vision for the company was of a mobile money app and commercial notary software inspired by Open-Transactions, and with an emphasis on Africa."''

Monetas was a major supporter of Open-Transactions development for several years, and spent significant financial and human resources on developing Open-Transactions from 2012 through 2015, while also implementing their own commercial notary and mobile wallet software inspired by Open-Transactions.

Monetas has generously released their improvements to Open-Transactions under the [https://www.mozilla.org/en-US/MPL/2.0/ MPLv2] license, and the company is now solely focused on their own commercial implementation.

Monetas' official website: http://monetas.net

FAQ

2016-01-16T01:04:24Z

FellowTraveler: updates to some old info

'''DO YOU HAVE A GUI YET?'''

Yes... we have the QT/C++ client GUI [https://github.com/Open-Transactions/Moneychanger Moneychanger (Qt-based Desktop Client)]

-----

'''CHAUMIAN CASH?'''

<blockquote>Is this the '''real''' stuff? With blinded tokens? As in, invented by David Chaum?
</blockquote>
Yes, Open Transactions provides a full and working implementation of Chaumian blinded tokens. Specifically, the Wagner variant as implemented by Ben Laurie in his [http://anoncvs.aldigital.co.uk/lucre/ Lucre Project].

Here's an intro [http://www.cs.bham.ac.uk/~mdr/teaching/modules06/netsec/lectures/DigitalCash.html article on digital cash].

In the near future, I will also add Chaum's algorithm as well as Brands' -- Both are available in [http://www.cypherspace.org/credlib/ 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.

<hr />

<br>'''EXPLAIN THE DIFFERENCE BETWEEN "NUMBERED ACCOUNTS" and "UNTRACEABLE" and "ANONYMOUS"'''

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 [[Instruments|many more instruments]] become possible when using accounts: Cheques, transfers, payment plans, markets with trades, etc. ([http://billstclair.com/ot/OT-Pseudonym-Instruments.jpg 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 [http://billstclair.com/ot/OT-Anon-CashOnly.jpg 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.)

<hr />

<br>'''WHY DO YOU USE THE WORD "CASH" -- ISN'T THAT CONFUSING?'''

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),
<br>'''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.'''''

<hr />

<br>'''So I can just give myself 1000000000000 Weaselbucks and then I can pay you in weaselbucks?'''
<br>''' 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.

<hr />

<br>'''HOW DOES THE CASH WORK?'''

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:

<ol start="1" style="list-style-type: decimal;">
<li>WITHDRAW (CREATE) PROTOTOKENS
<br>OTClient.cpp:
<br>else if (OTClient::notarizeWithdrawal == requestedCommand) // NOTARIZE WITHDRAWAL
<li>SIGN PROTOTOKENS
<br>OTServer.cpp:
<br />void OTServer::NotarizeWithdrawal(OTPseudonym & theNym, OTAccount theAccount, OTTransaction & tranIn, OTTransaction & tranOut)
<li>UNBLIND TOKENS
<br>OTClient.cpp:
<br />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...]

<li>DEPOSIT TOKENS (IN PURSE)
<br>OTClient.cpp:
<br>else if (OTClient::notarizePurse == requestedCommand) // NOTARIZE PURSE (deposit)
<li>VERIFY TOKENS
<br>OTServer.cpp:
<br />void OTServer::NotarizeDeposit(OTPseudonym & theNym, OTAccount & theAccount, OTTransaction & tranIn, OTTransaction & tranOut)</li></ol>

'''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!

<hr />

<br>'''HOW DOES THIS COMPARE TO BITCOIN?'''

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. [[CENTRALIZED|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.

<hr />

<br>'''IS OT "DISTRIBUTED" or "FEDERATED" or "P2P" or "CLIENT/SERVER" ...OR WHAT?'''

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.)

<hr />

<br>'''HOW DOES THIS COMPARE TO E-GOLD OR PECUNIX?'''

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.)

<hr />

<br>'''HOW DOES ''OPEN TRANSACTIONS'' COMPARE TO ''LOOM''?'''

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 [http://loom.cc/ Loom].

<hr />

<br>'''HOW DOES ''OPEN TRANSACTIONS'' COMPARE TO ''RIPPLE''?'''

[http://ripple-project.org/ 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.

<hr />

'''HOW DOES ''OPEN TRANSACTIONS'' COMPARE TO TRULEDGER (formerly ''TRUBANC'')?'''

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 [http://truledger.com/ Trueledger].

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

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

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

THE SERVER
<br>- The server gets Alice's signature on the transfer request.
<br>- The server gets Bob's signature accepting Alice's transfer.
<br>- The server gets Alice's signature acknowledging Bob's acceptance (when she removes his accept notice from her inbox.)
<br>- 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:
<br>- a list of transaction numbers still outstanding (signed out by the Nym). <br>- a list of pending transactions, and signed receipts, awaiting approval in the inbox.
<br>- ...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: [http://truledger.com/doc/plain-english.html]

<hr />

<br>''HOW DOES ''OPEN TRANSACTIONS'' COMPARE TO ''RICARDO'' BY SYSTEMICS?''

[http://www.financialcryptography.com/ Ian Grigg] has commented that Open Transactions is along the same lines as Ricardo.

Open Transactions has definitely adopted the '''[http://iang.org/papers/ricardian_contract.html Ricardian Contract]''' form, which is one of his innovations.

<hr />

<br>'''HOW DOES ''OPEN TRANSACTIONS'' COMPARE TO ''eCache''?'''

'''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.)

<hr />

<br>'''WHAT IF I WANT TO EXCHANGE TOKENS, BUT WITHOUT CREATING AN ACCOUNT?'''

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.

<hr />

<br>'''AN INVOICE IS JUST A NEGATIVE CHEQUE? PLEASE EXPLAIN.'''

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...)

<hr />

<br>'''THE TRANSPORT LAYER...'''

-- '''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 [[Messaging|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."

<hr />

<br>'''WHAT DATABASE DOES OPEN TRANSACTIONS USE?'''

* 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?

<hr />

<br>'''WHAT ABOUT CHAUM'S TRICK FOR IDENTIFYING THE DOUBLE-SPENDER?'''

<blockquote>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...)
</blockquote>
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.

<hr />

<br>'''LINUX?'''

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

<hr />

<br>'''FreeBSD?'''

GOOD NEWS: Open Transactions is now available for FreeBSD!

<hr />

<br>'''WINDOWS?'''

GOOD NEWS: Open Transactions is now available for Windows!

<hr />

<br>'''ANDROID?'''

GOOD NEWS: Open Transactions is now available for Android!

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

<hr />

<br>'''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.)

<br>'''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.)

<hr />

<br>'''CAN YOU CONVERT THE LIBRARY TO ''C'' ?'''

<blockquote>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:
<br>1) would you consider turning main components of it into C?
<br>2) would you assist someone attempting to do the same?
</blockquote>
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...

# The library doesn't use any exception handling -- it's all return values.
# I would convert the class members to a struct.
# I would convert the class methods to normal functions, with an additional "this" pointer passed in (for the struct)
# Have to make sure to call the constructor / destructor by hand whenever a struct is created or deleted.
# 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.

<hr />

<br>'''WHAT ABOUT CHAUM'S CUT-AND-CHOOSE PROTOCOL?'''

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?

<hr />

<br>'''WHAT ABOUT BRANDS' PROTOCOL? WHAT ABOUT XYZ PROTOCOL?'''

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 [http://www.cypherspace.org/credlib/ 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.

<hr />

<br>'''HOW DO I VIEW THE BASE64-ENCODED DATA THAT APPEARS IN THE FILES AND MESSAGES?'''

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.)

<hr />

<br>'''WHY IS CASH WITHDRAWAL FAILING?'''

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!)

<hr />

<br>'''WHAT IF I WANT TO CREATE MY OWN CONTRACTS?'''

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.

<hr />

<br>'''HOW CAN THE SERVER OPERATOR MAKE MONEY?'''

* 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...

<hr />

<br>'''LICENSE ?'''

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.

Monetas

2016-01-02T05:21:10Z

FellowTraveler: minor fix

Monetas is a software company based in Zug, Switzerland, that was cofounded by Chris Odom, the creator of Open-Transactions. [http://www.opentransactions.org/open-transactions.pdf (Click for white paper.) ]

Chris Odom [http://opentransactions.org/forum/index.php?topic=11922.0 stepped down] from Monetas in March 2015 and [http://opentransactions.org/forum/index.php?topic=11925.0 cofounded] [http://stashcrypto.com/ Stash]. He said, ''"When I cofounded Monetas in 2012 with Johann Gevers, our vision for the company was of a mobile money app and commercial notary software inspired by Open-Transactions, and with an emphasis on Africa."''

Monetas was a major supporter of Open-Transactions development for several years, and spent significant financial and human resources on developing Open-Transactions from 2012 through 2015, while also implementing their own commercial notary and mobile wallet software inspired by Open-Transactions.

Monetas has generously released their improvements to Open-Transactions under the [https://www.mozilla.org/en-US/MPL/2.0/ MPLv2] license, and the company is now focused only on their own commercial implementation.

Monetas' official website: http://monetas.net

OTX

2015-12-16T05:23:59Z

FellowTraveler: updated link

== OTX Protocol ==

For using OT in your own application, see the [[API|article on the high-level API.]]

For more details on how these messages work, see the [[Messaging|article on messaging.]]

Also see the [[Transactions|article on transaction messages.]]

=== Version 0.1 ===

These are the messages used by versions of the opentxs client and server up to [https://github.com/Open-Transactions/Open-Transactions 0.93]

For specifics on each message, see the [https://github.com/Open-Transactions/opentxs/blob/develop/src/core/Message.cpp#L2600 opentxs::Message.cpp file.]

{|class="wikitable" border="1" cellspacing="0" cellpadding="5" style="border: 1px solid black; border-collapse: collapse;"
|- style="font-weight:bold;"
|Message||Action||Response||Transactional (Y/N)
|-
|checkServerID||Like a server “ping”.||@checkServerID||N
|-
|createUserAccount||Register Nym + Credentials at Server||@createUserAccount||Y
|-
|createUserAccount||(If already exists) Download Nym from server||@createUserAccount||N
|-
|deleteUserAccount||Delete Nym from server||@deleteUserAccount||Y
|-
|getRequest||Get current request number for Nym||@getRequest||N
|-
|getContract||Download contract by ID||@getContract||N
|-
|getMint||Download Mint by Asset ID||@getMint||N
|-
|getMarketList||Download list of markets||@getMarketList||N
|-
|getMarketOffers||Download offers active on market||@getMarketOffers||N
|-
|getMarketRecentTrades||Download recent trades for market||@getMarketRecentTrades||N
|-
|getNym_MarketOffers||Download list of offers on market for Nym||@getNym_MarketOffers||N
|-
|checkUser||Download public credentials for a Nym||@checkUser||N
|-
|usageCredits||Get Nym's usage credits from server||@usageCredits||N
|-
|usageCredits||Set Nym's usage credits for server (admin)||@usageCredits||Y
|-
|sendUserMessage||Send message to another Nym||@sendUserMessage||Y
|-
|sendUserInstrument||Send payment instrument to another Nym||@sendUserInstrument||Y
|-
|issueAssetType||Issue currency or stock based on contract||@issueAssetType||Y
|-
|queryAssetTypes||Download list of asset types from server||@queryAssetTypes||N
|-
|issueBasket||Issue basket currency onto server||@issueBasket||Y
|-
|createAccount||Create asset account on server||@createAccount||Y
|-
|getAccount||Download account balance from server||@getAccount||N
|-
|deleteAssetAccount||Delete asset account from server||@deleteAssetAccount||Y
|-
|getTransactionNum||Ask server for 100 new transaction numbers||@getTransactionNum||Y
|-
|getNymbox||Download Nymbox from server||@getNymbox||N
|-
|getInbox||Download Inbox from server||@getInbox||N
|-
|getOutbox||Download outbox from server||@getOutbox||N
|-
|getBoxReceipt||Download box receipt from server||@getBoxReceipt||N
|-
|processInbox||Process inbox items||@processInbox||Y
|-
|processNymbox||Process nymbox items||@processNymbox||Y
|-
|triggerClause||Trigger clause on running smart contract||@triggerClause||Y
|-
|notarizeTransactions||“transfer” acct-to-acct||@notarizeTransactions||Y
|-
|notarizeTransactions||“deposit” cash||@notarizeTransactions||Y
|-
|notarizeTransactions||“deposit” cheque||@notarizeTransactions||Y
|-
|notarizeTransactions||“withdrawal” of cash||@notarizeTransactions||Y
|-
|notarizeTransactions||“withdrawal” of voucher||@notarizeTransactions||Y
|-
|notarizeTransactions||Place a “marketOffer”||@notarizeTransactions||Y
|-
|notarizeTransactions||Activate a “paymentPlan”||@notarizeTransactions||Y
|-
|notarizeTransactions||Activate a “smartContract”||@notarizeTransactions||Y
|-
|notarizeTransactions||“cancelCronItem” - Cancel a market offer, payment plan or smart contract.||@notarizeTransactions||Y
|-
|notarizeTransactions||“exchangeBasket” (Into the basket)||@notarizeTransactions||Y
|-
|notarizeTransactions||“exchangeBasket” (Out of the basket)||@notarizeTransactions||Y
|-
|notarizeTransactions||“payDividend” to shareholders||@notarizeTransactions||Y
|}

=== Version 0.2 ===

For more details on message contents and formats, see [https://github.com/Open-Transactions/protocol-docs GitHub documentation]

{|class="wikitable" border="1" cellspacing="0" cellpadding="5" style="border: 1px solid black; border-collapse: collapse;"
|- style="font-weight:bold;"
|Old name||New name||Response Message
|-
|createUserAccount||registerNym||registerNymResponse
|-
|}

[[About|Click here to return to the About page.]]

About

2015-12-05T05:55:47Z

FellowTraveler: /* Video Walkthrough */ Removed desktop video walkthru as well, since it contains footage showing the Monetas OT iPhone client. (Will post a new replacement video soon.)

__NOTOC__
<div class="plainlinks">
{| id="mp-topbanner" style="width:100%; background:#f6f6f6; margin-top:1.2em; border:1px solid #ddd;"
| style="width:61%; color:#000;" |

{| style="width:100%; border:none; background:none;"
| style="text-align:center; white-space:nowrap; color:#000;" |
<div style="font-size:162%; border:none; margin:0; padding:.1em; color:#000;">About the Open-Transactions project.</div>
<div style="top:+0.2em; font-size:95%;">Financial cryptography software.</div>
<div id="articlecount" style="width:100%; text-align:center; font-size:85%;">[[Special:Statistics|{{NUMBEROFARTICLES}}]] [[Special:Allpages|articles]].</div>
|}
|}

<div style="float:left; max-width: 550px;">

<big>'''What is Open-Transactions?'''</big>

* Open-Transactions is an [[Use Cases|easy-to-use]], financial crypto, [[Sample Cash|digital cash]] and transaction [[List of Classes|library]].
* Open-Transactions is open-source.
* Open-Transactions includes a [[API|client API]], a working [[Otserver|server]], a cross-platform [https://github.com/Open-Transactions/Moneychanger GUI] and a [[opentxs|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, [http://iang.org/papers/ricardian_contract.html Ricardian contracts], Smart Contracts (scriptable clauses), and more.

<big>'''What does it do?'''</big>

* Open-Transactions allows users to issue and manipulate digital assets.
* Any issuer can sign and distribute new [[Sample Currency Contract|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"''' for maximum anonymity, using '''[[Sample Cash|untraceable digital cash]]'''.

<big>'''Financial Instruments'''</big>
* Users can transfer digital assets ''securely and provably'', with [[Triple-Signed Receipts|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 '''[[Instruments|financial instruments]]''' such as account transfer, '''[[Sample-Cheque|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.

<big>'''Markets, Basket Currencies, and Smart Contracts'''</big>
* Open-Transactions also implements higher-level, '''contract-based transactions''' such as '''payment plans''' and '''markets with trades'''.
* The [[Markets|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]]: <code>!/usr/bin/env ot</code> The entire (mostly) high and low level OT API is available within your scripts.

<big>'''Triple Signed Receipts'''</big>
* 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.

<big>'''Is Open-Transactions [[CENTRALIZED|centralized]]?'''</big>
* No—quite the opposite. Open-Transactions is highly '''decentralized'''.
* Typical centralized servers have power over their users, but in OT, '''no server has power over the clients it serves''', because:
# An OT server does not control user transactions—it merely notarizes them.
# Anyone can operate an OT server, and users can go to any OT server to notarize transactions. Thus OT servers compete with each other to attract users to use their notary services.
# Anyone can download an OT client, and use it to execute transactions on any OT server, or any group of OT servers.
# OT uses triple-signed receipts, so transaction parties have independent cryptographic proof of transactions and balances.
# OT servers do not store user assets. Rather, cryptocurrencies are stored in voting pools so the server can't steal them.

In every way, '''the user is in control, not the server'''—even when you're using servers you do not trust. These characteristics generate a '''federated''' network architecture—similar to the internet, and it has the same virtues as the internet—openness, decentralization, resilience, censorship-resistance, and user control.

The community behind OT is strongly committed to developing systems that give users full control over their own assets and information.

</div>

<div style="float:right; max-width: 300px; margin: -20px 10px 0 20px;">

== White Paper ==

[http://www.opentransactions.org/open-transactions.pdf OT White Paper]

== Diagrams ==

[[Voting_Pool_Deposit_Process|Voting Pools]]

[http://i.imgur.com/HTyAJjg.png Architecture Overview (new)]

[http://billstclair.com/ot/ot-diagram.jpg Architecture Overview (old)]

[http://billstclair.com/ot/OT-Pseudonym-Instruments.jpg Financial Instruments]

== Radio Interviews ==

[https://www.youtube.com/watch?v=teNzIFu5L70 "Trust No One" Miami Speech]

[http://agoristradio.com/?p=234 AgoristRadio Interview, Part 1]

[http://agoristradio.com/?p=246 AgoristRadio Interview, Part 2]

[https://www.youtube.com/watch?v=vtJcUM5-TeA Interview with "Let's Talk Bitcoin"]

[http://www.youtube.com/watch?v=HSgpStCTw2g Interview with FutureMoneyTrends.com]

== Video Walkthrough ==

[http://localhost:3000/img/iphone-app.png iPhone App screenshot]

-----

[[Components and GNU Licensing]]

[[Vulnerabilities|Potential vulnerabilities]] of Open-Transactions

== Related Systems ==

[http://bitcoin.org/ Bitcoin] - A censorship-resistant global ledger

[[Stash]] - Enterprise platform based on OT.

[[Monetas]] - Transaction platform inspired by OT.

[https://loom.cc/help Loom] - Asset issuance and transactions

[http://www.csee.umbc.edu/~woodcock/cmsc482/proj1/magmoney.html Magic Money] - PGP-based Chaumian blinding (unlinkable cash)

[http://opencoin.org/ OpenCoin.org] - REST-based blinded tokens

[http://www.opentransact.org/ OpenTransact] - REST-based transaction protocol

[https://payswarm.com/ PaySwarm] - REST-based transaction protocol

[https://www.facebook.com/publickeytransaction PKTP] - Public-Key Transaction Processor

[http://wiki.dgcmagazine.com/index.php?title=Ricardo Ricardo] - Transaction system by Ian Grigg

[https://ripple.com/ Ripple] - Consensus-based debt ledger

[https://www.stellar.org/ Stellar] - Ripple-based

[http://truledger.com/ Truledger] - Destruction of account history

[http://www.voucher-safe.com/index.cfm Voucher-Safe] - Secure asset issuance with auditing

---------

Article: [http://pelagic.wavyhill.xsmail.com/Private_Digital_Economy.html Toward a Private Digital Economy]

</div>

<div style="clear: both; padding-top: 40px;">

== In More Detail... ==

The server itself is a [[Transactions|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 '''[[Sample Cash|unlinkable digital cash]]'''. The software uses Chaumian-style, blinded tokens courtesy of the [http://anoncvs.aldigital.co.uk/lucre/ 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 [http://pktp.co.cc/ 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 [[Sample Currency Contract|currency contract]] to the server. (This functionality is comparable to [http://www.systemics.com/docs/sox/overview.html Ricardo] by [http://financialcryptography.com/ Ian Grigg].)
* '''Users can open asset accounts of any type.''' You can have as many as you want, associated with each user account. (See [http://loom.cc/ Loom] by Patrick Chkoreff.)
* [[Triple-Signed Receipts|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 [http://truledger.com/ Truledger] for an [http://truledger.com/doc/plain-english.html 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: [http://szabo.best.vwh.net/contractlanguage.html 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: <pre>#!/usr/local/bin/ot --script</pre>
* 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 '''[[Sample Currency Contract | 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: [http://www.goldstandardinstitute.net/2010/06/what-is-a-real-bill/ 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 [[API]]s''' for '''Java, Ruby, Python, PHP, Perl, C, [http://www.digitalmars.com/d/2.0/overview.html 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 [http://zeromq.org/ 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.

</div>

Monetas

2015-12-05T01:40:59Z

FellowTraveler: added link to mplv2 license

Monetas is a software company based in Zug, Switzerland, that was cofounded by Chris Odom, the creator of Open-Transactions. [http://www.opentransactions.org/open-transactions.pdf (Click for white paper.) ]

Chris Odom [http://opentransactions.org/forum/index.php?topic=11922.0 stepped down] from Monetas in March 2015 and [http://opentransactions.org/forum/index.php?topic=11925.0 cofounded] [http://stashcrypto.com/ Stash]. He said, ''"When I cofounded Monetas in 2012 with Johann Gevers, our vision for the company was of a mobile money app and commercial notary software inspired by Open-Transactions, and with an emphasis on Africa."''

Monetas was a major supporter of Open-Transactions development, and spent significant financial and human resources on developing Open-Transactions from 2012 through 2015, while also implementing their own commercial notary and mobile wallet software inspired by Open-Transactions.

Monetas has generously released their improvements to Open-Transactions under the [https://www.mozilla.org/en-US/MPL/2.0/ MPLv2] license, and the company is now focused only on their own commercial implementation.

Monetas' official website: http://monetas.net

About

2015-12-05T01:34:05Z

FellowTraveler: /* Video Walkthrough */ Android video was posted in Jan 2015 at request of Johann Gevers and removed Dec 2015 again at request of Johann Gevers

__NOTOC__
<div class="plainlinks">
{| id="mp-topbanner" style="width:100%; background:#f6f6f6; margin-top:1.2em; border:1px solid #ddd;"
| style="width:61%; color:#000;" |

{| style="width:100%; border:none; background:none;"
| style="text-align:center; white-space:nowrap; color:#000;" |
<div style="font-size:162%; border:none; margin:0; padding:.1em; color:#000;">About the Open-Transactions project.</div>
<div style="top:+0.2em; font-size:95%;">Financial cryptography software.</div>
<div id="articlecount" style="width:100%; text-align:center; font-size:85%;">[[Special:Statistics|{{NUMBEROFARTICLES}}]] [[Special:Allpages|articles]].</div>
|}
|}

<div style="float:left; max-width: 550px;">

<big>'''What is Open-Transactions?'''</big>

* Open-Transactions is an [[Use Cases|easy-to-use]], financial crypto, [[Sample Cash|digital cash]] and transaction [[List of Classes|library]].
* Open-Transactions is open-source.
* Open-Transactions includes a [[API|client API]], a working [[Otserver|server]], a cross-platform [https://github.com/Open-Transactions/Moneychanger GUI] and a [[opentxs|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, [http://iang.org/papers/ricardian_contract.html Ricardian contracts], Smart Contracts (scriptable clauses), and more.

<big>'''What does it do?'''</big>

* Open-Transactions allows users to issue and manipulate digital assets.
* Any issuer can sign and distribute new [[Sample Currency Contract|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"''' for maximum anonymity, using '''[[Sample Cash|untraceable digital cash]]'''.

<big>'''Financial Instruments'''</big>
* Users can transfer digital assets ''securely and provably'', with [[Triple-Signed Receipts|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 '''[[Instruments|financial instruments]]''' such as account transfer, '''[[Sample-Cheque|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.

<big>'''Markets, Basket Currencies, and Smart Contracts'''</big>
* Open-Transactions also implements higher-level, '''contract-based transactions''' such as '''payment plans''' and '''markets with trades'''.
* The [[Markets|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]]: <code>!/usr/bin/env ot</code> The entire (mostly) high and low level OT API is available within your scripts.

<big>'''Triple Signed Receipts'''</big>
* 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.

<big>'''Is Open-Transactions [[CENTRALIZED|centralized]]?'''</big>
* No—quite the opposite. Open-Transactions is highly '''decentralized'''.
* Typical centralized servers have power over their users, but in OT, '''no server has power over the clients it serves''', because:
# An OT server does not control user transactions—it merely notarizes them.
# Anyone can operate an OT server, and users can go to any OT server to notarize transactions. Thus OT servers compete with each other to attract users to use their notary services.
# Anyone can download an OT client, and use it to execute transactions on any OT server, or any group of OT servers.
# OT uses triple-signed receipts, so transaction parties have independent cryptographic proof of transactions and balances.
# OT servers do not store user assets. Rather, cryptocurrencies are stored in voting pools so the server can't steal them.

In every way, '''the user is in control, not the server'''—even when you're using servers you do not trust. These characteristics generate a '''federated''' network architecture—similar to the internet, and it has the same virtues as the internet—openness, decentralization, resilience, censorship-resistance, and user control.

The community behind OT is strongly committed to developing systems that give users full control over their own assets and information.

</div>

<div style="float:right; max-width: 300px; margin: -20px 10px 0 20px;">

== White Paper ==

[http://www.opentransactions.org/open-transactions.pdf OT White Paper]

== Diagrams ==

[[Voting_Pool_Deposit_Process|Voting Pools]]

[http://i.imgur.com/HTyAJjg.png Architecture Overview (new)]

[http://billstclair.com/ot/ot-diagram.jpg Architecture Overview (old)]

[http://billstclair.com/ot/OT-Pseudonym-Instruments.jpg Financial Instruments]

== Radio Interviews ==

[https://www.youtube.com/watch?v=teNzIFu5L70 "Trust No One" Miami Speech]

[http://agoristradio.com/?p=234 AgoristRadio Interview, Part 1]

[http://agoristradio.com/?p=246 AgoristRadio Interview, Part 2]

[https://www.youtube.com/watch?v=vtJcUM5-TeA Interview with "Let's Talk Bitcoin"]

[http://www.youtube.com/watch?v=HSgpStCTw2g Interview with FutureMoneyTrends.com]

== Video Walkthrough ==

[https://drive.google.com/open?id=0B1PBS_CyC2E_SkRjaVliOXJITGM Desktop video 1 - Introduction]

[https://drive.google.com/open?id=0B1PBS_CyC2E_MEk4ZDNtVGtRMHc Desktop video 2 - Advanced]

[http://localhost:3000/img/iphone-app.png iPhone App screenshot]

[http://vimeo.com/28141679 java testclient video 1]

[http://vimeo.com/28142096 java testclient video 2]

-----

[[Components and GNU Licensing]]

[[Vulnerabilities|Potential vulnerabilities]] of Open-Transactions

== Related Systems ==

[http://bitcoin.org/ Bitcoin] - A censorship-resistant global ledger

[[Stash]] - Enterprise platform based on OT.

[[Monetas]] - Transaction platform inspired by OT.

[https://loom.cc/help Loom] - Asset issuance and transactions

[http://www.csee.umbc.edu/~woodcock/cmsc482/proj1/magmoney.html Magic Money] - PGP-based Chaumian blinding (unlinkable cash)

[http://opencoin.org/ OpenCoin.org] - REST-based blinded tokens

[http://www.opentransact.org/ OpenTransact] - REST-based transaction protocol

[https://payswarm.com/ PaySwarm] - REST-based transaction protocol

[https://www.facebook.com/publickeytransaction PKTP] - Public-Key Transaction Processor

[http://wiki.dgcmagazine.com/index.php?title=Ricardo Ricardo] - Transaction system by Ian Grigg

[https://ripple.com/ Ripple] - Consensus-based debt ledger

[https://www.stellar.org/ Stellar] - Ripple-based

[http://truledger.com/ Truledger] - Destruction of account history

[http://www.voucher-safe.com/index.cfm Voucher-Safe] - Secure asset issuance with auditing

---------

Article: [http://pelagic.wavyhill.xsmail.com/Private_Digital_Economy.html Toward a Private Digital Economy]

</div>

<div style="clear: both; padding-top: 40px;">

== In More Detail... ==

The server itself is a [[Transactions|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 '''[[Sample Cash|unlinkable digital cash]]'''. The software uses Chaumian-style, blinded tokens courtesy of the [http://anoncvs.aldigital.co.uk/lucre/ 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 [http://pktp.co.cc/ 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 [[Sample Currency Contract|currency contract]] to the server. (This functionality is comparable to [http://www.systemics.com/docs/sox/overview.html Ricardo] by [http://financialcryptography.com/ Ian Grigg].)
* '''Users can open asset accounts of any type.''' You can have as many as you want, associated with each user account. (See [http://loom.cc/ Loom] by Patrick Chkoreff.)
* [[Triple-Signed Receipts|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 [http://truledger.com/ Truledger] for an [http://truledger.com/doc/plain-english.html 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: [http://szabo.best.vwh.net/contractlanguage.html 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: <pre>#!/usr/local/bin/ot --script</pre>
* 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 '''[[Sample Currency Contract | 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: [http://www.goldstandardinstitute.net/2010/06/what-is-a-real-bill/ 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 [[API]]s''' for '''Java, Ruby, Python, PHP, Perl, C, [http://www.digitalmars.com/d/2.0/overview.html 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 [http://zeromq.org/ 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.

</div>

About

2015-12-05T01:24:29Z

FellowTraveler: /* Video Walkthrough */ iPhone videos were added Oct 2013 by request of Johann Gevers, and removed Dec 2015, again by request of Johann Gevers.

__NOTOC__
<div class="plainlinks">
{| id="mp-topbanner" style="width:100%; background:#f6f6f6; margin-top:1.2em; border:1px solid #ddd;"
| style="width:61%; color:#000;" |

{| style="width:100%; border:none; background:none;"
| style="text-align:center; white-space:nowrap; color:#000;" |
<div style="font-size:162%; border:none; margin:0; padding:.1em; color:#000;">About the Open-Transactions project.</div>
<div style="top:+0.2em; font-size:95%;">Financial cryptography software.</div>
<div id="articlecount" style="width:100%; text-align:center; font-size:85%;">[[Special:Statistics|{{NUMBEROFARTICLES}}]] [[Special:Allpages|articles]].</div>
|}
|}

<div style="float:left; max-width: 550px;">

<big>'''What is Open-Transactions?'''</big>

* Open-Transactions is an [[Use Cases|easy-to-use]], financial crypto, [[Sample Cash|digital cash]] and transaction [[List of Classes|library]].
* Open-Transactions is open-source.
* Open-Transactions includes a [[API|client API]], a working [[Otserver|server]], a cross-platform [https://github.com/Open-Transactions/Moneychanger GUI] and a [[opentxs|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, [http://iang.org/papers/ricardian_contract.html Ricardian contracts], Smart Contracts (scriptable clauses), and more.

<big>'''What does it do?'''</big>

* Open-Transactions allows users to issue and manipulate digital assets.
* Any issuer can sign and distribute new [[Sample Currency Contract|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"''' for maximum anonymity, using '''[[Sample Cash|untraceable digital cash]]'''.

<big>'''Financial Instruments'''</big>
* Users can transfer digital assets ''securely and provably'', with [[Triple-Signed Receipts|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 '''[[Instruments|financial instruments]]''' such as account transfer, '''[[Sample-Cheque|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.

<big>'''Markets, Basket Currencies, and Smart Contracts'''</big>
* Open-Transactions also implements higher-level, '''contract-based transactions''' such as '''payment plans''' and '''markets with trades'''.
* The [[Markets|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]]: <code>!/usr/bin/env ot</code> The entire (mostly) high and low level OT API is available within your scripts.

<big>'''Triple Signed Receipts'''</big>
* 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.

<big>'''Is Open-Transactions [[CENTRALIZED|centralized]]?'''</big>
* No—quite the opposite. Open-Transactions is highly '''decentralized'''.
* Typical centralized servers have power over their users, but in OT, '''no server has power over the clients it serves''', because:
# An OT server does not control user transactions—it merely notarizes them.
# Anyone can operate an OT server, and users can go to any OT server to notarize transactions. Thus OT servers compete with each other to attract users to use their notary services.
# Anyone can download an OT client, and use it to execute transactions on any OT server, or any group of OT servers.
# OT uses triple-signed receipts, so transaction parties have independent cryptographic proof of transactions and balances.
# OT servers do not store user assets. Rather, cryptocurrencies are stored in voting pools so the server can't steal them.

In every way, '''the user is in control, not the server'''—even when you're using servers you do not trust. These characteristics generate a '''federated''' network architecture—similar to the internet, and it has the same virtues as the internet—openness, decentralization, resilience, censorship-resistance, and user control.

The community behind OT is strongly committed to developing systems that give users full control over their own assets and information.

</div>

<div style="float:right; max-width: 300px; margin: -20px 10px 0 20px;">

== White Paper ==

[http://www.opentransactions.org/open-transactions.pdf OT White Paper]

== Diagrams ==

[[Voting_Pool_Deposit_Process|Voting Pools]]

[http://i.imgur.com/HTyAJjg.png Architecture Overview (new)]

[http://billstclair.com/ot/ot-diagram.jpg Architecture Overview (old)]

[http://billstclair.com/ot/OT-Pseudonym-Instruments.jpg Financial Instruments]

== Radio Interviews ==

[https://www.youtube.com/watch?v=teNzIFu5L70 "Trust No One" Miami Speech]

[http://agoristradio.com/?p=234 AgoristRadio Interview, Part 1]

[http://agoristradio.com/?p=246 AgoristRadio Interview, Part 2]

[https://www.youtube.com/watch?v=vtJcUM5-TeA Interview with "Let's Talk Bitcoin"]

[http://www.youtube.com/watch?v=HSgpStCTw2g Interview with FutureMoneyTrends.com]

== Video Walkthrough ==

[https://www.youtube.com/watch?v=5qtTayW-RyM Android demo video (Monetas)]

[https://drive.google.com/open?id=0B1PBS_CyC2E_SkRjaVliOXJITGM Desktop video 1 - Introduction]

[https://drive.google.com/open?id=0B1PBS_CyC2E_MEk4ZDNtVGtRMHc Desktop video 2 - Advanced]

[http://localhost:3000/img/iphone-app.png iPhone App screenshot]

[http://vimeo.com/28141679 java testclient video 1]

[http://vimeo.com/28142096 java testclient video 2]

-----

[[Components and GNU Licensing]]

[[Vulnerabilities|Potential vulnerabilities]] of Open-Transactions

== Related Systems ==

[http://bitcoin.org/ Bitcoin] - A censorship-resistant global ledger

[[Stash]] - Enterprise platform based on OT.

[[Monetas]] - Transaction platform inspired by OT.

[https://loom.cc/help Loom] - Asset issuance and transactions

[http://www.csee.umbc.edu/~woodcock/cmsc482/proj1/magmoney.html Magic Money] - PGP-based Chaumian blinding (unlinkable cash)

[http://opencoin.org/ OpenCoin.org] - REST-based blinded tokens

[http://www.opentransact.org/ OpenTransact] - REST-based transaction protocol

[https://payswarm.com/ PaySwarm] - REST-based transaction protocol

[https://www.facebook.com/publickeytransaction PKTP] - Public-Key Transaction Processor

[http://wiki.dgcmagazine.com/index.php?title=Ricardo Ricardo] - Transaction system by Ian Grigg

[https://ripple.com/ Ripple] - Consensus-based debt ledger

[https://www.stellar.org/ Stellar] - Ripple-based

[http://truledger.com/ Truledger] - Destruction of account history

[http://www.voucher-safe.com/index.cfm Voucher-Safe] - Secure asset issuance with auditing

---------

Article: [http://pelagic.wavyhill.xsmail.com/Private_Digital_Economy.html Toward a Private Digital Economy]

</div>

<div style="clear: both; padding-top: 40px;">

== In More Detail... ==

The server itself is a [[Transactions|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 '''[[Sample Cash|unlinkable digital cash]]'''. The software uses Chaumian-style, blinded tokens courtesy of the [http://anoncvs.aldigital.co.uk/lucre/ 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 [http://pktp.co.cc/ 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 [[Sample Currency Contract|currency contract]] to the server. (This functionality is comparable to [http://www.systemics.com/docs/sox/overview.html Ricardo] by [http://financialcryptography.com/ Ian Grigg].)
* '''Users can open asset accounts of any type.''' You can have as many as you want, associated with each user account. (See [http://loom.cc/ Loom] by Patrick Chkoreff.)
* [[Triple-Signed Receipts|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 [http://truledger.com/ Truledger] for an [http://truledger.com/doc/plain-english.html 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: [http://szabo.best.vwh.net/contractlanguage.html 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: <pre>#!/usr/local/bin/ot --script</pre>
* 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 '''[[Sample Currency Contract | 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: [http://www.goldstandardinstitute.net/2010/06/what-is-a-real-bill/ 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 [[API]]s''' for '''Java, Ruby, Python, PHP, Perl, C, [http://www.digitalmars.com/d/2.0/overview.html 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 [http://zeromq.org/ 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.

</div>

About

2015-12-01T00:44:08Z

FellowTraveler: /* Related Systems */ Changed Monetas link to say "Transaction Platform"

__NOTOC__
<div class="plainlinks">
{| id="mp-topbanner" style="width:100%; background:#f6f6f6; margin-top:1.2em; border:1px solid #ddd;"
| style="width:61%; color:#000;" |

{| style="width:100%; border:none; background:none;"
| style="text-align:center; white-space:nowrap; color:#000;" |
<div style="font-size:162%; border:none; margin:0; padding:.1em; color:#000;">About the Open-Transactions project.</div>
<div style="top:+0.2em; font-size:95%;">Financial cryptography software.</div>
<div id="articlecount" style="width:100%; text-align:center; font-size:85%;">[[Special:Statistics|{{NUMBEROFARTICLES}}]] [[Special:Allpages|articles]].</div>
|}
|}

<div style="float:left; max-width: 550px;">

<big>'''What is Open-Transactions?'''</big>

* Open-Transactions is an [[Use Cases|easy-to-use]], financial crypto, [[Sample Cash|digital cash]] and transaction [[List of Classes|library]].
* Open-Transactions is open-source.
* Open-Transactions includes a [[API|client API]], a working [[Otserver|server]], a cross-platform [https://github.com/Open-Transactions/Moneychanger GUI] and a [[opentxs|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, [http://iang.org/papers/ricardian_contract.html Ricardian contracts], Smart Contracts (scriptable clauses), and more.

<big>'''What does it do?'''</big>

* Open-Transactions allows users to issue and manipulate digital assets.
* Any issuer can sign and distribute new [[Sample Currency Contract|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"''' for maximum anonymity, using '''[[Sample Cash|untraceable digital cash]]'''.

<big>'''Financial Instruments'''</big>
* Users can transfer digital assets ''securely and provably'', with [[Triple-Signed Receipts|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 '''[[Instruments|financial instruments]]''' such as account transfer, '''[[Sample-Cheque|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.

<big>'''Markets, Basket Currencies, and Smart Contracts'''</big>
* Open-Transactions also implements higher-level, '''contract-based transactions''' such as '''payment plans''' and '''markets with trades'''.
* The [[Markets|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]]: <code>!/usr/bin/env ot</code> The entire (mostly) high and low level OT API is available within your scripts.

<big>'''Triple Signed Receipts'''</big>
* 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.

<big>'''Is Open-Transactions [[CENTRALIZED|centralized]]?'''</big>
* No—quite the opposite. Open-Transactions is highly '''decentralized'''.
* Typical centralized servers have power over their users, but in OT, '''no server has power over the clients it serves''', because:
# An OT server does not control user transactions—it merely notarizes them.
# Anyone can operate an OT server, and users can go to any OT server to notarize transactions. Thus OT servers compete with each other to attract users to use their notary services.
# Anyone can download an OT client, and use it to execute transactions on any OT server, or any group of OT servers.
# OT uses triple-signed receipts, so transaction parties have independent cryptographic proof of transactions and balances.
# OT servers do not store user assets. Rather, cryptocurrencies are stored in voting pools so the server can't steal them.

In every way, '''the user is in control, not the server'''—even when you're using servers you do not trust. These characteristics generate a '''federated''' network architecture—similar to the internet, and it has the same virtues as the internet—openness, decentralization, resilience, censorship-resistance, and user control.

The community behind OT is strongly committed to developing systems that give users full control over their own assets and information.

</div>

<div style="float:right; max-width: 300px; margin: -20px 10px 0 20px;">

== White Paper ==

[http://www.opentransactions.org/open-transactions.pdf OT White Paper]

== Diagrams ==

[[Voting_Pool_Deposit_Process|Voting Pools]]

[http://i.imgur.com/HTyAJjg.png Architecture Overview (new)]

[http://billstclair.com/ot/ot-diagram.jpg Architecture Overview (old)]

[http://billstclair.com/ot/OT-Pseudonym-Instruments.jpg Financial Instruments]

== Radio Interviews ==

[https://www.youtube.com/watch?v=teNzIFu5L70 "Trust No One" Miami Speech]

[http://agoristradio.com/?p=234 AgoristRadio Interview, Part 1]

[http://agoristradio.com/?p=246 AgoristRadio Interview, Part 2]

[https://www.youtube.com/watch?v=vtJcUM5-TeA Interview with "Let's Talk Bitcoin"]

[http://www.youtube.com/watch?v=HSgpStCTw2g Interview with FutureMoneyTrends.com]

== Video Walkthrough ==

[https://www.youtube.com/watch?v=5qtTayW-RyM Android demo video (Monetas)]

[https://drive.google.com/open?id=0B1PBS_CyC2E_SkRjaVliOXJITGM Desktop video 1 - Introduction]

[https://drive.google.com/open?id=0B1PBS_CyC2E_MEk4ZDNtVGtRMHc Desktop video 2 - Advanced]

[https://drive.google.com/open?id=0B1PBS_CyC2E_cTl3bXZpWnBBSVE iPhone video 1 - Introduction]

[https://drive.google.com/open?id=0B1PBS_CyC2E_dS1hd3RYaENQQzg iPhone video 2 - Advanced]

[http://vimeo.com/28141679 java testclient video 1]

[http://vimeo.com/28142096 java testclient video 2]

-----

[[Components and GNU Licensing]]

[[Vulnerabilities|Potential vulnerabilities]] of Open-Transactions

== Related Systems ==

[http://bitcoin.org/ Bitcoin] - A censorship-resistant global ledger

[[Stash]] - Enterprise platform based on OT.

[[Monetas]] - Transaction platform inspired by OT.

[https://loom.cc/help Loom] - Asset issuance and transactions

[http://www.csee.umbc.edu/~woodcock/cmsc482/proj1/magmoney.html Magic Money] - PGP-based Chaumian blinding (unlinkable cash)

[http://opencoin.org/ OpenCoin.org] - REST-based blinded tokens

[http://www.opentransact.org/ OpenTransact] - REST-based transaction protocol

[https://payswarm.com/ PaySwarm] - REST-based transaction protocol

[https://www.facebook.com/publickeytransaction PKTP] - Public-Key Transaction Processor

[http://wiki.dgcmagazine.com/index.php?title=Ricardo Ricardo] - Transaction system by Ian Grigg

[https://ripple.com/ Ripple] - Consensus-based debt ledger

[https://www.stellar.org/ Stellar] - Ripple-based

[http://truledger.com/ Truledger] - Destruction of account history

[http://www.voucher-safe.com/index.cfm Voucher-Safe] - Secure asset issuance with auditing

---------

Article: [http://pelagic.wavyhill.xsmail.com/Private_Digital_Economy.html Toward a Private Digital Economy]

</div>

<div style="clear: both; padding-top: 40px;">

== In More Detail... ==

The server itself is a [[Transactions|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 '''[[Sample Cash|unlinkable digital cash]]'''. The software uses Chaumian-style, blinded tokens courtesy of the [http://anoncvs.aldigital.co.uk/lucre/ 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 [http://pktp.co.cc/ 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 [[Sample Currency Contract|currency contract]] to the server. (This functionality is comparable to [http://www.systemics.com/docs/sox/overview.html Ricardo] by [http://financialcryptography.com/ Ian Grigg].)
* '''Users can open asset accounts of any type.''' You can have as many as you want, associated with each user account. (See [http://loom.cc/ Loom] by Patrick Chkoreff.)
* [[Triple-Signed Receipts|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 [http://truledger.com/ Truledger] for an [http://truledger.com/doc/plain-english.html 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: [http://szabo.best.vwh.net/contractlanguage.html 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: <pre>#!/usr/local/bin/ot --script</pre>
* 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 '''[[Sample Currency Contract | 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: [http://www.goldstandardinstitute.net/2010/06/what-is-a-real-bill/ 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 [[API]]s''' for '''Java, Ruby, Python, PHP, Perl, C, [http://www.digitalmars.com/d/2.0/overview.html 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 [http://zeromq.org/ 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.

</div>

MediaWiki:Sidebar

2015-12-01T00:25:39Z

FellowTraveler: Removed Monetas link from main sidebar; it was a vestige of the Monetas period.

Signature status

2015-11-30T22:23:35Z

FellowTraveler: /* Schema */ fixed link

The [[startwithdrawal]] API call returns a list of signatures which can be shared with other members of the voting pool to create an valid withdrawal transaction.

The list is formatted as a JSON object.

==Schema==

<include src="https://raw.githubusercontent.com/Open-Transactions/rfc/master/json/schema/signaturestatus-01.json" />

==Example==

* Input 0 is a 2-of-3 multisig script and none of the required signatures have been supplied
* Input 1 is a 2-of-3 multisig script and all of the required signatures have been supplied

<include src="https://raw.githubusercontent.com/Monetas/rfc/master/json/data/signaturestatus-01.json" />

[[Category:Voting Pool Technical Specifications]]

Stash

2015-10-12T02:50:01Z

FellowTraveler: minor edit

Stash is an Austin based software company that was [http://opentransactions.org/forum/index.php?topic=11925.0 cofounded] in 2015 by Cliff Baltzley, the founder of [https://www.hushmail.com/ Hushmail] and Chris Odom, the creator of Open-Transactions and cofounder of [[Monetas]]. [http://www.opentransactions.org/open-transactions.pdf (Click here for Open-Transactions white paper.) ]

Stash's mission: To give all users full control over their own money.

Official site: http://stashcrypto.com

Monetas

2015-10-12T02:48:46Z

FellowTraveler: minor edit

Monetas is a software company based in Zug, Switzerland, that was cofounded by Chris Odom, the creator of Open-Transactions. [http://www.opentransactions.org/open-transactions.pdf (Click for white paper.) ]

Chris Odom [http://opentransactions.org/forum/index.php?topic=11922.0 stepped down] from Monetas in March 2015 and [http://opentransactions.org/forum/index.php?topic=11925.0 cofounded] [http://stashcrypto.com/ Stash]. He said, ''"When I cofounded Monetas in 2012 with Johann Gevers, our vision for the company was of a mobile money app and commercial notary software inspired by Open-Transactions, and with an emphasis on Africa."''

Monetas was a major supporter of Open-Transactions development, and spent significant financial and human resources on developing Open-Transactions from 2012 through 2015, while also implementing their own commercial notary and mobile wallet software.

Monetas has generously released their improvements to Open-Transactions under the MPLv2 license, and the company is now focused only on their own commercial implementation.

Official site: http://monetas.net

Stash

2015-10-12T02:47:45Z

FellowTraveler: added link

Stash is an Austin based software company that was [http://opentransactions.org/forum/index.php?topic=11925.0 cofounded] by Cliff Baltzley, the founder of [https://www.hushmail.com/ Hushmail] and Chris Odom, the creator of Open-Transactions and cofounder of [[Monetas]]. [http://www.opentransactions.org/open-transactions.pdf (Click here for Open-Transactions white paper.) ]

Stash's mission: To give all users full control over their own money.

Official site: http://stashcrypto.com

Monetas

2015-10-12T02:45:11Z

FellowTraveler: added zug

Monetas is a software company based in Zug, Switzerland, that was cofounded by Chris Odom, the creator of Open-Transactions. [http://www.opentransactions.org/open-transactions.pdf (Click for white paper.) ]

Chris Odom [http://opentransactions.org/forum/index.php?topic=11922.0 stepped down] from Monetas in March 2015 and [http://opentransactions.org/forum/index.php?topic=11925.0 cofounded] [http://stashcrypto.com/ Stash]. He said, ''"When I cofounded Monetas in 2012 with Johann Gevers, our vision for the company was of a mobile money app and commercial notary software inspired by Open-Transactions, and with an emphasis on Africa."''

Monetas was a major supporter of Open-Transactions development, and spent significant financial and human resources on developing Open-Transactions from 2012 through early 2015, while also implementing their own commercial notary and mobile wallet software.

Monetas has generously released their improvements to Open-Transactions under the MPLv2 license, and the company is now focused only on their own commercial implementation.

Official site: http://monetas.net

Monetas

2015-10-12T02:44:16Z

FellowTraveler: added link

Monetas is a Switzerland based software company that was cofounded by Chris Odom, the creator of Open-Transactions. [http://www.opentransactions.org/open-transactions.pdf (Click for white paper.) ]

Chris Odom [http://opentransactions.org/forum/index.php?topic=11922.0 stepped down] from Monetas in March 2015 and [http://opentransactions.org/forum/index.php?topic=11925.0 cofounded] [http://stashcrypto.com/ Stash]. He said, ''"When I cofounded Monetas in 2012 with Johann Gevers, our vision for the company was of a mobile money app and commercial notary software inspired by Open-Transactions, and with an emphasis on Africa."''

Monetas was a major supporter of Open-Transactions development, and spent significant financial and human resources on developing Open-Transactions from 2012 through early 2015, while also implementing their own commercial notary and mobile wallet software.

Monetas has generously released their improvements to Open-Transactions under the MPLv2 license, and the company is now focused only on their own commercial implementation.

Official site: http://monetas.net

About

2015-10-11T00:00:39Z

FellowTraveler: /* Related Systems */ Added Stash link

__NOTOC__
<div class="plainlinks">
{| id="mp-topbanner" style="width:100%; background:#f6f6f6; margin-top:1.2em; border:1px solid #ddd;"
| style="width:61%; color:#000;" |

{| style="width:100%; border:none; background:none;"
| style="text-align:center; white-space:nowrap; color:#000;" |
<div style="font-size:162%; border:none; margin:0; padding:.1em; color:#000;">About the Open-Transactions project.</div>
<div style="top:+0.2em; font-size:95%;">Financial cryptography software.</div>
<div id="articlecount" style="width:100%; text-align:center; font-size:85%;">[[Special:Statistics|{{NUMBEROFARTICLES}}]] [[Special:Allpages|articles]].</div>
|}
|}

<div style="float:left; max-width: 550px;">

<big>'''What is Open-Transactions?'''</big>

* Open-Transactions is an [[Use Cases|easy-to-use]], financial crypto, [[Sample Cash|digital cash]] and transaction [[List of Classes|library]].
* Open-Transactions is open-source.
* Open-Transactions includes a [[API|client API]], a working [[Otserver|server]], a cross-platform [https://github.com/Open-Transactions/Moneychanger GUI] and a [[opentxs|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, [http://iang.org/papers/ricardian_contract.html Ricardian contracts], Smart Contracts (scriptable clauses), and more.

<big>'''What does it do?'''</big>

* Open-Transactions allows users to issue and manipulate digital assets.
* Any issuer can sign and distribute new [[Sample Currency Contract|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"''' for maximum anonymity, using '''[[Sample Cash|untraceable digital cash]]'''.

<big>'''Financial Instruments'''</big>
* Users can transfer digital assets ''securely and provably'', with [[Triple-Signed Receipts|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 '''[[Instruments|financial instruments]]''' such as account transfer, '''[[Sample-Cheque|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.

<big>'''Markets, Basket Currencies, and Smart Contracts'''</big>
* Open-Transactions also implements higher-level, '''contract-based transactions''' such as '''payment plans''' and '''markets with trades'''.
* The [[Markets|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]]: <code>!/usr/bin/env ot</code> The entire (mostly) high and low level OT API is available within your scripts.

<big>'''Triple Signed Receipts'''</big>
* 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.

<big>'''Is Open-Transactions [[CENTRALIZED|centralized]]?'''</big>
* No—quite the opposite. Open-Transactions is highly '''decentralized'''.
* Typical centralized servers have power over their users, but in OT, '''no server has power over the clients it serves''', because:
# An OT server does not control user transactions—it merely notarizes them.
# Anyone can operate an OT server, and users can go to any OT server to notarize transactions. Thus OT servers compete with each other to attract users to use their notary services.
# Anyone can download an OT client, and use it to execute transactions on any OT server, or any group of OT servers.
# OT uses triple-signed receipts, so transaction parties have independent cryptographic proof of transactions and balances.
# OT servers do not store user assets. Rather, cryptocurrencies are stored in voting pools so the server can't steal them.

In every way, '''the user is in control, not the server'''—even when you're using servers you do not trust. These characteristics generate a '''federated''' network architecture—similar to the internet, and it has the same virtues as the internet—openness, decentralization, resilience, censorship-resistance, and user control.

The community behind OT is strongly committed to developing systems that give users full control over their own assets and information.

</div>

<div style="float:right; max-width: 300px; margin: -20px 10px 0 20px;">

== White Paper ==

[http://www.opentransactions.org/open-transactions.pdf OT White Paper]

== Diagrams ==

[[Voting_Pool_Deposit_Process|Voting Pools]]

[http://i.imgur.com/HTyAJjg.png Architecture Overview (new)]

[http://billstclair.com/ot/ot-diagram.jpg Architecture Overview (old)]

[http://billstclair.com/ot/OT-Pseudonym-Instruments.jpg Financial Instruments]

== Radio Interviews ==

[https://www.youtube.com/watch?v=teNzIFu5L70 "Trust No One" Miami Speech]

[http://agoristradio.com/?p=234 AgoristRadio Interview, Part 1]

[http://agoristradio.com/?p=246 AgoristRadio Interview, Part 2]

[https://www.youtube.com/watch?v=vtJcUM5-TeA Interview with "Let's Talk Bitcoin"]

[http://www.youtube.com/watch?v=HSgpStCTw2g Interview with FutureMoneyTrends.com]

== Video Walkthrough ==

[https://www.youtube.com/watch?v=5qtTayW-RyM Android demo video (Monetas)]

[https://drive.google.com/open?id=0B1PBS_CyC2E_SkRjaVliOXJITGM Desktop video 1 - Introduction]

[https://drive.google.com/open?id=0B1PBS_CyC2E_MEk4ZDNtVGtRMHc Desktop video 2 - Advanced]

[https://drive.google.com/open?id=0B1PBS_CyC2E_cTl3bXZpWnBBSVE iPhone video 1 - Introduction]

[https://drive.google.com/open?id=0B1PBS_CyC2E_dS1hd3RYaENQQzg iPhone video 2 - Advanced]

[http://vimeo.com/28141679 java testclient video 1]

[http://vimeo.com/28142096 java testclient video 2]

-----

[[Components and GNU Licensing]]

[[Vulnerabilities|Potential vulnerabilities]] of Open-Transactions

== Related Systems ==

[http://bitcoin.org/ Bitcoin] - A censorship-resistant global ledger

[[Stash]] - Enterprise platform based on OT.

[[Monetas]] - Mobile payments inspired by OT.

[https://loom.cc/help Loom] - Asset issuance and transactions

[http://www.csee.umbc.edu/~woodcock/cmsc482/proj1/magmoney.html Magic Money] - PGP-based Chaumian blinding (unlinkable cash)

[http://opencoin.org/ OpenCoin.org] - REST-based blinded tokens

[http://www.opentransact.org/ OpenTransact] - REST-based transaction protocol

[https://payswarm.com/ PaySwarm] - REST-based transaction protocol

[https://www.facebook.com/publickeytransaction PKTP] - Public-Key Transaction Processor

[http://wiki.dgcmagazine.com/index.php?title=Ricardo Ricardo] - Transaction system by Ian Grigg

[https://ripple.com/ Ripple] - Consensus-based debt ledger

[https://www.stellar.org/ Stellar] - Ripple-based

[http://truledger.com/ Truledger] - Destruction of account history

[http://www.voucher-safe.com/index.cfm Voucher-Safe] - Secure asset issuance with auditing

---------

Article: [http://pelagic.wavyhill.xsmail.com/Private_Digital_Economy.html Toward a Private Digital Economy]

</div>

<div style="clear: both; padding-top: 40px;">

== In More Detail... ==

The server itself is a [[Transactions|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 '''[[Sample Cash|unlinkable digital cash]]'''. The software uses Chaumian-style, blinded tokens courtesy of the [http://anoncvs.aldigital.co.uk/lucre/ 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 [http://pktp.co.cc/ 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 [[Sample Currency Contract|currency contract]] to the server. (This functionality is comparable to [http://www.systemics.com/docs/sox/overview.html Ricardo] by [http://financialcryptography.com/ Ian Grigg].)
* '''Users can open asset accounts of any type.''' You can have as many as you want, associated with each user account. (See [http://loom.cc/ Loom] by Patrick Chkoreff.)
* [[Triple-Signed Receipts|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 [http://truledger.com/ Truledger] for an [http://truledger.com/doc/plain-english.html 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: [http://szabo.best.vwh.net/contractlanguage.html 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: <pre>#!/usr/local/bin/ot --script</pre>
* 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 '''[[Sample Currency Contract | 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: [http://www.goldstandardinstitute.net/2010/06/what-is-a-real-bill/ 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 [[API]]s''' for '''Java, Ruby, Python, PHP, Perl, C, [http://www.digitalmars.com/d/2.0/overview.html 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 [http://zeromq.org/ 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.

</div>

Stash

2015-10-10T23:59:15Z

FellowTraveler: added mission

Stash is an Austin based software company that was [http://opentransactions.org/forum/index.php?topic=11925.0 cofounded] by Cliff Baltzley, the founder of [https://www.hushmail.com/ Hushmail] and Chris Odom, the creator of Open-Transactions. [http://www.opentransactions.org/open-transactions.pdf (Click for white paper.) ]

Stash's mission: To give all users full control over their own money.

Official site: http://stashcrypto.com

Stash

2015-10-10T23:57:31Z

FellowTraveler: added press release link

Stash is an Austin based software company that was [http://opentransactions.org/forum/index.php?topic=11925.0 cofounded] by Cliff Baltzley, the founder of [https://www.hushmail.com/ Hushmail] and Chris Odom, the creator of Open-Transactions. [http://www.opentransactions.org/open-transactions.pdf (Click for white paper.) ]

Official site: http://stashcrypto.com

Stash

2015-10-10T23:55:42Z

FellowTraveler: created page

Stash is an Austin based software company that was cofounded by Cliff Baltzley, the founder of [https://www.hushmail.com/ Hushmail] and Chris Odom, the creator of Open-Transactions. [http://www.opentransactions.org/open-transactions.pdf (Click for white paper.) ]

Official site: http://stashcrypto.com

MediaWiki:Sidebar

2015-10-10T23:45:04Z

FellowTraveler: re-arranged order

MediaWiki:Sidebar

2015-10-10T23:44:45Z

FellowTraveler: added Stash

Monetas

2015-10-10T22:38:08Z

FellowTraveler: added Stash link

Monetas is a Switzerland based software company that was cofounded by Chris Odom, the creator of Open-Transactions. [http://www.opentransactions.org/open-transactions.pdf (Click for white paper.) ]

Chris Odom [http://opentransactions.org/forum/index.php?topic=11922.0 stepped down] from Monetas in March 2015 and [http://opentransactions.org/forum/index.php?topic=11925.0 cofounded Stash]. He said, ''"When I cofounded Monetas in 2012 with Johann Gevers, our vision for the company was of a mobile money app and commercial notary software inspired by Open-Transactions, and with an emphasis on Africa."''

Monetas was a major supporter of Open-Transactions development, and spent significant financial and human resources on developing Open-Transactions from 2012 through early 2015, while also implementing their own commercial notary and mobile wallet software.

Monetas has generously released their improvements to Open-Transactions under the MPLv2 license, and the company is now focused only on their own commercial implementation.

Official site: http://monetas.net

About

2015-08-01T18:29:54Z

FellowTraveler: /* Video Walkthrough */ removed a dead link

__NOTOC__
<div class="plainlinks">
{| id="mp-topbanner" style="width:100%; background:#f6f6f6; margin-top:1.2em; border:1px solid #ddd;"
| style="width:61%; color:#000;" |

{| style="width:100%; border:none; background:none;"
| style="text-align:center; white-space:nowrap; color:#000;" |
<div style="font-size:162%; border:none; margin:0; padding:.1em; color:#000;">About the Open-Transactions project.</div>
<div style="top:+0.2em; font-size:95%;">Financial cryptography software.</div>
<div id="articlecount" style="width:100%; text-align:center; font-size:85%;">[[Special:Statistics|{{NUMBEROFARTICLES}}]] [[Special:Allpages|articles]].</div>
|}
|}

<div style="float:left; max-width: 550px;">

<big>'''What is Open-Transactions?'''</big>

* Open-Transactions is an [[Use Cases|easy-to-use]], financial crypto, [[Sample Cash|digital cash]] and transaction [[List of Classes|library]].
* Open-Transactions is open-source.
* Open-Transactions includes a [[API|client API]], a working [[Otserver|server]], a cross-platform [https://github.com/Open-Transactions/Moneychanger GUI] and a [[opentxs|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, [http://iang.org/papers/ricardian_contract.html Ricardian contracts], Smart Contracts (scriptable clauses), and more.

<big>'''What does it do?'''</big>

* Open-Transactions allows users to issue and manipulate digital assets.
* Any issuer can sign and distribute new [[Sample Currency Contract|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"''' for maximum anonymity, using '''[[Sample Cash|untraceable digital cash]]'''.

<big>'''Financial Instruments'''</big>
* Users can transfer digital assets ''securely and provably'', with [[Triple-Signed Receipts|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 '''[[Instruments|financial instruments]]''' such as account transfer, '''[[Sample-Cheque|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.

<big>'''Markets, Basket Currencies, and Smart Contracts'''</big>
* Open-Transactions also implements higher-level, '''contract-based transactions''' such as '''payment plans''' and '''markets with trades'''.
* The [[Markets|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]]: <code>!/usr/bin/env ot</code> The entire (mostly) high and low level OT API is available within your scripts.

<big>'''Triple Signed Receipts'''</big>
* 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.

<big>'''Is Open-Transactions [[CENTRALIZED|centralized]]?'''</big>
* No—quite the opposite. Open-Transactions is highly '''decentralized'''.
* Typical centralized servers have power over their users, but in OT, '''no server has power over the clients it serves''', because:
# An OT server does not control user transactions—it merely notarizes them.
# Anyone can operate an OT server, and users can go to any OT server to notarize transactions. Thus OT servers compete with each other to attract users to use their notary services.
# Anyone can download an OT client, and use it to execute transactions on any OT server, or any group of OT servers.
# OT uses triple-signed receipts, so transaction parties have independent cryptographic proof of transactions and balances.
# OT servers do not store user assets. Rather, cryptocurrencies are stored in voting pools so the server can't steal them.

In every way, '''the user is in control, not the server'''—even when you're using servers you do not trust. These characteristics generate a '''federated''' network architecture—similar to the internet, and it has the same virtues as the internet—openness, decentralization, resilience, censorship-resistance, and user control.

The community behind OT is strongly committed to developing systems that give users full control over their own assets and information.

</div>

<div style="float:right; max-width: 300px; margin: -20px 10px 0 20px;">

== White Paper ==

[http://www.opentransactions.org/open-transactions.pdf OT White Paper]

== Diagrams ==

[[Voting_Pool_Deposit_Process|Voting Pools]]

[http://i.imgur.com/HTyAJjg.png Architecture Overview (new)]

[http://billstclair.com/ot/ot-diagram.jpg Architecture Overview (old)]

[http://billstclair.com/ot/OT-Pseudonym-Instruments.jpg Financial Instruments]

== Radio Interviews ==

[https://www.youtube.com/watch?v=teNzIFu5L70 "Trust No One" Miami Speech]

[http://agoristradio.com/?p=234 AgoristRadio Interview, Part 1]

[http://agoristradio.com/?p=246 AgoristRadio Interview, Part 2]

[https://www.youtube.com/watch?v=vtJcUM5-TeA Interview with "Let's Talk Bitcoin"]

[http://www.youtube.com/watch?v=HSgpStCTw2g Interview with FutureMoneyTrends.com]

== Video Walkthrough ==

[https://www.youtube.com/watch?v=5qtTayW-RyM Android demo video (Monetas)]

[https://drive.google.com/open?id=0B1PBS_CyC2E_SkRjaVliOXJITGM Desktop video 1 - Introduction]

[https://drive.google.com/open?id=0B1PBS_CyC2E_MEk4ZDNtVGtRMHc Desktop video 2 - Advanced]

[https://drive.google.com/open?id=0B1PBS_CyC2E_cTl3bXZpWnBBSVE iPhone video 1 - Introduction]

[https://drive.google.com/open?id=0B1PBS_CyC2E_dS1hd3RYaENQQzg iPhone video 2 - Advanced]

[http://vimeo.com/28141679 java testclient video 1]

[http://vimeo.com/28142096 java testclient video 2]

-----

[[Components and GNU Licensing]]

[[Vulnerabilities|Potential vulnerabilities]] of Open-Transactions

== Related Systems ==

[http://bitcoin.org/ Bitcoin] - A censorship-resistant global ledger

[[Monetas]] - Enterprise platform inspired by OT.

[https://loom.cc/help Loom] - Asset issuance and transactions

[http://www.csee.umbc.edu/~woodcock/cmsc482/proj1/magmoney.html Magic Money] - PGP-based Chaumian blinding (unlinkable cash)

[http://opencoin.org/ OpenCoin.org] - REST-based blinded tokens

[http://www.opentransact.org/ OpenTransact] - REST-based transaction protocol

[https://payswarm.com/ PaySwarm] - REST-based transaction protocol

[https://www.facebook.com/publickeytransaction PKTP] - Public-Key Transaction Processor

[http://wiki.dgcmagazine.com/index.php?title=Ricardo Ricardo] - Transaction system by Ian Grigg

[https://ripple.com/ Ripple] - Consensus-based debt ledger

[https://www.stellar.org/ Stellar] - Ripple-based

[http://truledger.com/ Truledger] - Destruction of account history

[http://www.voucher-safe.com/index.cfm Voucher-Safe] - Secure asset issuance with auditing

---------

Article: [http://pelagic.wavyhill.xsmail.com/Private_Digital_Economy.html Toward a Private Digital Economy]

</div>

<div style="clear: both; padding-top: 40px;">

== In More Detail... ==

The server itself is a [[Transactions|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 '''[[Sample Cash|unlinkable digital cash]]'''. The software uses Chaumian-style, blinded tokens courtesy of the [http://anoncvs.aldigital.co.uk/lucre/ 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 [http://pktp.co.cc/ 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 [[Sample Currency Contract|currency contract]] to the server. (This functionality is comparable to [http://www.systemics.com/docs/sox/overview.html Ricardo] by [http://financialcryptography.com/ Ian Grigg].)
* '''Users can open asset accounts of any type.''' You can have as many as you want, associated with each user account. (See [http://loom.cc/ Loom] by Patrick Chkoreff.)
* [[Triple-Signed Receipts|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 [http://truledger.com/ Truledger] for an [http://truledger.com/doc/plain-english.html 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: [http://szabo.best.vwh.net/contractlanguage.html 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: <pre>#!/usr/local/bin/ot --script</pre>
* 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 '''[[Sample Currency Contract | 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: [http://www.goldstandardinstitute.net/2010/06/what-is-a-real-bill/ 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 [[API]]s''' for '''Java, Ruby, Python, PHP, Perl, C, [http://www.digitalmars.com/d/2.0/overview.html 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 [http://zeromq.org/ 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.

</div>

About

2015-08-01T18:29:35Z

FellowTraveler: /* Video Walkthrough */ updated video links

__NOTOC__
<div class="plainlinks">
{| id="mp-topbanner" style="width:100%; background:#f6f6f6; margin-top:1.2em; border:1px solid #ddd;"
| style="width:61%; color:#000;" |

{| style="width:100%; border:none; background:none;"
| style="text-align:center; white-space:nowrap; color:#000;" |
<div style="font-size:162%; border:none; margin:0; padding:.1em; color:#000;">About the Open-Transactions project.</div>
<div style="top:+0.2em; font-size:95%;">Financial cryptography software.</div>
<div id="articlecount" style="width:100%; text-align:center; font-size:85%;">[[Special:Statistics|{{NUMBEROFARTICLES}}]] [[Special:Allpages|articles]].</div>
|}
|}

<div style="float:left; max-width: 550px;">

<big>'''What is Open-Transactions?'''</big>

* Open-Transactions is an [[Use Cases|easy-to-use]], financial crypto, [[Sample Cash|digital cash]] and transaction [[List of Classes|library]].
* Open-Transactions is open-source.
* Open-Transactions includes a [[API|client API]], a working [[Otserver|server]], a cross-platform [https://github.com/Open-Transactions/Moneychanger GUI] and a [[opentxs|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, [http://iang.org/papers/ricardian_contract.html Ricardian contracts], Smart Contracts (scriptable clauses), and more.

<big>'''What does it do?'''</big>

* Open-Transactions allows users to issue and manipulate digital assets.
* Any issuer can sign and distribute new [[Sample Currency Contract|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"''' for maximum anonymity, using '''[[Sample Cash|untraceable digital cash]]'''.

<big>'''Financial Instruments'''</big>
* Users can transfer digital assets ''securely and provably'', with [[Triple-Signed Receipts|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 '''[[Instruments|financial instruments]]''' such as account transfer, '''[[Sample-Cheque|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.

<big>'''Markets, Basket Currencies, and Smart Contracts'''</big>
* Open-Transactions also implements higher-level, '''contract-based transactions''' such as '''payment plans''' and '''markets with trades'''.
* The [[Markets|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]]: <code>!/usr/bin/env ot</code> The entire (mostly) high and low level OT API is available within your scripts.

<big>'''Triple Signed Receipts'''</big>
* 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.

<big>'''Is Open-Transactions [[CENTRALIZED|centralized]]?'''</big>
* No—quite the opposite. Open-Transactions is highly '''decentralized'''.
* Typical centralized servers have power over their users, but in OT, '''no server has power over the clients it serves''', because:
# An OT server does not control user transactions—it merely notarizes them.
# Anyone can operate an OT server, and users can go to any OT server to notarize transactions. Thus OT servers compete with each other to attract users to use their notary services.
# Anyone can download an OT client, and use it to execute transactions on any OT server, or any group of OT servers.
# OT uses triple-signed receipts, so transaction parties have independent cryptographic proof of transactions and balances.
# OT servers do not store user assets. Rather, cryptocurrencies are stored in voting pools so the server can't steal them.

In every way, '''the user is in control, not the server'''—even when you're using servers you do not trust. These characteristics generate a '''federated''' network architecture—similar to the internet, and it has the same virtues as the internet—openness, decentralization, resilience, censorship-resistance, and user control.

The community behind OT is strongly committed to developing systems that give users full control over their own assets and information.

</div>

<div style="float:right; max-width: 300px; margin: -20px 10px 0 20px;">

== White Paper ==

[http://www.opentransactions.org/open-transactions.pdf OT White Paper]

== Diagrams ==

[[Voting_Pool_Deposit_Process|Voting Pools]]

[http://i.imgur.com/HTyAJjg.png Architecture Overview (new)]

[http://billstclair.com/ot/ot-diagram.jpg Architecture Overview (old)]

[http://billstclair.com/ot/OT-Pseudonym-Instruments.jpg Financial Instruments]

== Radio Interviews ==

[https://www.youtube.com/watch?v=teNzIFu5L70 "Trust No One" Miami Speech]

[http://agoristradio.com/?p=234 AgoristRadio Interview, Part 1]

[http://agoristradio.com/?p=246 AgoristRadio Interview, Part 2]

[https://www.youtube.com/watch?v=vtJcUM5-TeA Interview with "Let's Talk Bitcoin"]

[http://www.youtube.com/watch?v=HSgpStCTw2g Interview with FutureMoneyTrends.com]

== Video Walkthrough ==

[https://www.youtube.com/watch?v=5qtTayW-RyM Android demo video (Monetas)]

[https://drive.google.com/open?id=0B1PBS_CyC2E_SkRjaVliOXJITGM Desktop video 1 - Introduction]

[https://drive.google.com/open?id=0B1PBS_CyC2E_MEk4ZDNtVGtRMHc Desktop video 2 - Advanced]

[https://drive.google.com/open?id=0B1PBS_CyC2E_cTl3bXZpWnBBSVE iPhone video 1 - Introduction]

[https://drive.google.com/open?id=0B1PBS_CyC2E_dS1hd3RYaENQQzg iPhone video 2 - Advanced]

[http://vimeo.com/28141679 java testclient video 1]

[http://vimeo.com/28142096 java testclient video 2]

[http://open-transactions.github.io/tv/ Official video archive (more videos)]

-----

[[Components and GNU Licensing]]

[[Vulnerabilities|Potential vulnerabilities]] of Open-Transactions

== Related Systems ==

[http://bitcoin.org/ Bitcoin] - A censorship-resistant global ledger

[[Monetas]] - Enterprise platform inspired by OT.

[https://loom.cc/help Loom] - Asset issuance and transactions

[http://www.csee.umbc.edu/~woodcock/cmsc482/proj1/magmoney.html Magic Money] - PGP-based Chaumian blinding (unlinkable cash)

[http://opencoin.org/ OpenCoin.org] - REST-based blinded tokens

[http://www.opentransact.org/ OpenTransact] - REST-based transaction protocol

[https://payswarm.com/ PaySwarm] - REST-based transaction protocol

[https://www.facebook.com/publickeytransaction PKTP] - Public-Key Transaction Processor

[http://wiki.dgcmagazine.com/index.php?title=Ricardo Ricardo] - Transaction system by Ian Grigg

[https://ripple.com/ Ripple] - Consensus-based debt ledger

[https://www.stellar.org/ Stellar] - Ripple-based

[http://truledger.com/ Truledger] - Destruction of account history

[http://www.voucher-safe.com/index.cfm Voucher-Safe] - Secure asset issuance with auditing

---------

Article: [http://pelagic.wavyhill.xsmail.com/Private_Digital_Economy.html Toward a Private Digital Economy]

</div>

<div style="clear: both; padding-top: 40px;">

== In More Detail... ==

The server itself is a [[Transactions|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 '''[[Sample Cash|unlinkable digital cash]]'''. The software uses Chaumian-style, blinded tokens courtesy of the [http://anoncvs.aldigital.co.uk/lucre/ 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 [http://pktp.co.cc/ 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 [[Sample Currency Contract|currency contract]] to the server. (This functionality is comparable to [http://www.systemics.com/docs/sox/overview.html Ricardo] by [http://financialcryptography.com/ Ian Grigg].)
* '''Users can open asset accounts of any type.''' You can have as many as you want, associated with each user account. (See [http://loom.cc/ Loom] by Patrick Chkoreff.)
* [[Triple-Signed Receipts|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 [http://truledger.com/ Truledger] for an [http://truledger.com/doc/plain-english.html 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: [http://szabo.best.vwh.net/contractlanguage.html 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: <pre>#!/usr/local/bin/ot --script</pre>
* 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 '''[[Sample Currency Contract | 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: [http://www.goldstandardinstitute.net/2010/06/what-is-a-real-bill/ 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 [[API]]s''' for '''Java, Ruby, Python, PHP, Perl, C, [http://www.digitalmars.com/d/2.0/overview.html 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 [http://zeromq.org/ 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.

</div>

About

2015-08-01T18:12:00Z

FellowTraveler: /* Related Systems */ changed link

__NOTOC__
<div class="plainlinks">
{| id="mp-topbanner" style="width:100%; background:#f6f6f6; margin-top:1.2em; border:1px solid #ddd;"
| style="width:61%; color:#000;" |

{| style="width:100%; border:none; background:none;"
| style="text-align:center; white-space:nowrap; color:#000;" |
<div style="font-size:162%; border:none; margin:0; padding:.1em; color:#000;">About the Open-Transactions project.</div>
<div style="top:+0.2em; font-size:95%;">Financial cryptography software.</div>
<div id="articlecount" style="width:100%; text-align:center; font-size:85%;">[[Special:Statistics|{{NUMBEROFARTICLES}}]] [[Special:Allpages|articles]].</div>
|}
|}

<div style="float:left; max-width: 550px;">

<big>'''What is Open-Transactions?'''</big>

* Open-Transactions is an [[Use Cases|easy-to-use]], financial crypto, [[Sample Cash|digital cash]] and transaction [[List of Classes|library]].
* Open-Transactions is open-source.
* Open-Transactions includes a [[API|client API]], a working [[Otserver|server]], a cross-platform [https://github.com/Open-Transactions/Moneychanger GUI] and a [[opentxs|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, [http://iang.org/papers/ricardian_contract.html Ricardian contracts], Smart Contracts (scriptable clauses), and more.

<big>'''What does it do?'''</big>

* Open-Transactions allows users to issue and manipulate digital assets.
* Any issuer can sign and distribute new [[Sample Currency Contract|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"''' for maximum anonymity, using '''[[Sample Cash|untraceable digital cash]]'''.

<big>'''Financial Instruments'''</big>
* Users can transfer digital assets ''securely and provably'', with [[Triple-Signed Receipts|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 '''[[Instruments|financial instruments]]''' such as account transfer, '''[[Sample-Cheque|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.

<big>'''Markets, Basket Currencies, and Smart Contracts'''</big>
* Open-Transactions also implements higher-level, '''contract-based transactions''' such as '''payment plans''' and '''markets with trades'''.
* The [[Markets|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]]: <code>!/usr/bin/env ot</code> The entire (mostly) high and low level OT API is available within your scripts.

<big>'''Triple Signed Receipts'''</big>
* 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.

<big>'''Is Open-Transactions [[CENTRALIZED|centralized]]?'''</big>
* No—quite the opposite. Open-Transactions is highly '''decentralized'''.
* Typical centralized servers have power over their users, but in OT, '''no server has power over the clients it serves''', because:
# An OT server does not control user transactions—it merely notarizes them.
# Anyone can operate an OT server, and users can go to any OT server to notarize transactions. Thus OT servers compete with each other to attract users to use their notary services.
# Anyone can download an OT client, and use it to execute transactions on any OT server, or any group of OT servers.
# OT uses triple-signed receipts, so transaction parties have independent cryptographic proof of transactions and balances.
# OT servers do not store user assets. Rather, cryptocurrencies are stored in voting pools so the server can't steal them.

In every way, '''the user is in control, not the server'''—even when you're using servers you do not trust. These characteristics generate a '''federated''' network architecture—similar to the internet, and it has the same virtues as the internet—openness, decentralization, resilience, censorship-resistance, and user control.

The community behind OT is strongly committed to developing systems that give users full control over their own assets and information.

</div>

<div style="float:right; max-width: 300px; margin: -20px 10px 0 20px;">

== White Paper ==

[http://www.opentransactions.org/open-transactions.pdf OT White Paper]

== Diagrams ==

[[Voting_Pool_Deposit_Process|Voting Pools]]

[http://i.imgur.com/HTyAJjg.png Architecture Overview (new)]

[http://billstclair.com/ot/ot-diagram.jpg Architecture Overview (old)]

[http://billstclair.com/ot/OT-Pseudonym-Instruments.jpg Financial Instruments]

== Radio Interviews ==

[https://www.youtube.com/watch?v=teNzIFu5L70 "Trust No One" Miami Speech]

[http://agoristradio.com/?p=234 AgoristRadio Interview, Part 1]

[http://agoristradio.com/?p=246 AgoristRadio Interview, Part 2]

[https://www.youtube.com/watch?v=vtJcUM5-TeA Interview with "Let's Talk Bitcoin"]

[http://www.youtube.com/watch?v=HSgpStCTw2g Interview with FutureMoneyTrends.com]

== Video Walkthrough ==

[https://www.youtube.com/watch?v=5qtTayW-RyM Android demo video (Monetas)]

[http://goo.gl/Ea6rzq Desktop video 1 - Introduction]

[http://goo.gl/i0J3AF Desktop video 2 - Advanced]

[http://goo.gl/8Dxak1 iPhone video 1 - Introduction]

[http://goo.gl/u6xqHc iPhone video 2 - Advanced]

[http://vimeo.com/28141679 java testclient video 1]

[http://vimeo.com/28142096 java testclient video 2]

[http://open-transactions.github.io/tv/ Official video archive (more videos)]

-----

[[Components and GNU Licensing]]

[[Vulnerabilities|Potential vulnerabilities]] of Open-Transactions

== Related Systems ==

[http://bitcoin.org/ Bitcoin] - A censorship-resistant global ledger

[[Monetas]] - Enterprise platform inspired by OT.

[https://loom.cc/help Loom] - Asset issuance and transactions

[http://www.csee.umbc.edu/~woodcock/cmsc482/proj1/magmoney.html Magic Money] - PGP-based Chaumian blinding (unlinkable cash)

[http://opencoin.org/ OpenCoin.org] - REST-based blinded tokens

[http://www.opentransact.org/ OpenTransact] - REST-based transaction protocol

[https://payswarm.com/ PaySwarm] - REST-based transaction protocol

[https://www.facebook.com/publickeytransaction PKTP] - Public-Key Transaction Processor

[http://wiki.dgcmagazine.com/index.php?title=Ricardo Ricardo] - Transaction system by Ian Grigg

[https://ripple.com/ Ripple] - Consensus-based debt ledger

[https://www.stellar.org/ Stellar] - Ripple-based

[http://truledger.com/ Truledger] - Destruction of account history

[http://www.voucher-safe.com/index.cfm Voucher-Safe] - Secure asset issuance with auditing

---------

Article: [http://pelagic.wavyhill.xsmail.com/Private_Digital_Economy.html Toward a Private Digital Economy]

</div>

<div style="clear: both; padding-top: 40px;">

== In More Detail... ==

The server itself is a [[Transactions|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 '''[[Sample Cash|unlinkable digital cash]]'''. The software uses Chaumian-style, blinded tokens courtesy of the [http://anoncvs.aldigital.co.uk/lucre/ 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 [http://pktp.co.cc/ 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 [[Sample Currency Contract|currency contract]] to the server. (This functionality is comparable to [http://www.systemics.com/docs/sox/overview.html Ricardo] by [http://financialcryptography.com/ Ian Grigg].)
* '''Users can open asset accounts of any type.''' You can have as many as you want, associated with each user account. (See [http://loom.cc/ Loom] by Patrick Chkoreff.)
* [[Triple-Signed Receipts|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 [http://truledger.com/ Truledger] for an [http://truledger.com/doc/plain-english.html 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: [http://szabo.best.vwh.net/contractlanguage.html 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: <pre>#!/usr/local/bin/ot --script</pre>
* 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 '''[[Sample Currency Contract | 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: [http://www.goldstandardinstitute.net/2010/06/what-is-a-real-bill/ 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 [[API]]s''' for '''Java, Ruby, Python, PHP, Perl, C, [http://www.digitalmars.com/d/2.0/overview.html 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 [http://zeromq.org/ 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.

</div>

Sample-Cheque

2015-07-13T15:04:07Z

FellowTraveler: fixed unlinkable

The inclusion of the transaction number onto the cheque was what made it possible to prevent double-spending of cheques (without having to use any other sort of "Cheque ID" or "spent cheque database".) But the user can request transaction numbers from the server ahead of time, and usually has a few of them sitting in his wallet. That way, he can write a cheque anytime he wants, offline and without any server contact, and the recipient can present it to the bank for payment at his leisure. Later if the recipient tries to present the cheque again, the bank sees that the same transaction number is no longer available on the payer's account (it got used the last time the cheque was presented), so it refuses the cheque.

I find cheques very interesting because you get a built-in receipt, and the money doesn't leave your account unless and until it is actually deposited or cashed. Cheques can even bounce, just like real cheques. Also: If the recipient never cashes your cheque, and it expires, then the money stays in your account. Whereas with [[Sample Cash|cash]], you have to remove it from your account before you can send it anywhere. And though cash is untraceable, the money is also lost if the recipient never deposits it. (Expired cash tokens revert to the server--the user is anonymous!) '''But with a cheque, you would keep that money...'''

All of the financial instruments have different properties... I invite you to check out the chart on the [[Instruments]] page and see for yourself.

SAMPLE CHEQUE:

<pre>
-----BEGIN SIGNED CHEQUE-----
Hash: SAMY

<?xml version="1.0"?>

<cheque
version="1.0"
amount="72"
assetTypeID="XUHBvdsWAEmErZMzHaRKaNPaAVsUvKwL4uLY4nOY2s4"
transactionNum="343"
serverID="44FmyPAgrmGu671RywGnhrt8aR6tzmNFn9WKQ92BXn"
senderAcctID="PhmhKernutijMa2XXxH1dZnTluIDQUVn1tifSOq9H4x"
senderUserID="Bg2QrSTomOEU5ICfvhfYfBYxQZPktDSnaVPpMLYxUnz"
hasRecipient="true"
recipientUserID="Bg2QrSTomOEU5ICfvhfYfBYxQZPktDSnaVPpMLYxUnz"
validFrom="1281783321"
validTo="1281783921" >

<memo>
eJzzSC1KVShPVUjPV0hMT8zMU2QAADncBbg=
</memo>

</cheque>
-----BEGIN CHEQUE SIGNATURE-----
DYPJjCc9LIpz/9B8aBPDrVsJBtvjt+737rWiMDDVYAhcnvb+PAuI4K3sM49W/WYJ
DKVKA9bawxd4w7KWlmibYM5X8nYr40s+H+6dyvD5C1mXAg1jjlm+XWl/JtvVxP2w
/DCmXPXgukYppTSkgHIrYn7E/Ong3nh62fGDwU+Aqfw=
-----END CHEQUE SIGNATURE-----
</pre>

<br>'''INVOICES''' An invoice is actually just a cheque with a negative amount. When a creditor hands you an invoice, it's your choice whether to present it at the bank and run it through one of your accounts. (To pay it.) If you do, then the funds are transferred and a receipt is dropped into your inbox.
<br>
<br>
-----

<br>'''VOUCHERS''' A voucher is also a cheque, but it's drawn on a server account instead of a personal account. It's like a cashier's cheque. You withdraw funds from your account, but instead of giving you cash, the money is transferred to one of the bank's accounts, and then you are issued a cheque drawn against that account.

Vouchers have slightly different properties than cheques. They are more trusted, because they never bounce. (Often, if you bounce a cheque, a creditor will demand a cashier's cheque to settle payments in the future. Why? Because they are more trusted...) A voucher allows you to "pay by cheque" while at the same time, pulling the money out of your account immediately into a trusted form. Vouchers have the same receipt properties as any other cheque. See the chart on the [[Instruments]] page for more details.

SAMPLE VOUCHER:

<pre>
-----BEGIN SIGNED VOUCHER-----
Hash: SAMY

<?xml version="1.0"?>

<cheque
version="1.0"
amount="73"
assetTypeID="XUHBvdsWAEmErZMzHaRKaNPaAVsUvKwL4uLY4nOY2s4"
transactionNum="417"
serverID="44FmyPAgrmGu671RywGnhrt8aR6tzmNFn9WKQ92BXn"
senderAcctID="khlj2LLL9EYxPimNR4yAYDDzO5QzSg7LSxxsGc1RpsP"
senderUserID="LG4bi40PAw6vlkU5TXiphXqmEELf3k1gjMsKQVjw7SE"
hasRecipient="false"
recipientUserID=""
validFrom="1281868590"
validTo="1297420590" >

<memo>
eJwLzyzJSClKLFcIyy9NzkgtslJQ4HIqrczMS1dIVCiDiOkoFGfkl+akKJTnF2Ur
MgAA18ERtQ==
</memo>

</cheque>
-----BEGIN VOUCHER SIGNATURE-----
HNufQ742X0pMwu5rQwtHQVXeQ0rJ9fu2ZirZ0rdTy9RXhSTWQY4YNR6F8YWScIfZ
/dv+mW8LNg5eUCBmSiDEN0jLLImEnVY2wpVtqAxMGGbXxHxU9yI7RbsvSBxQHKTd
tok7Sqn2syMlnAufszo+ScRXuvPWC8K51KgPxXTvBJI=
-----END VOUCHER SIGNATURE-----
</pre>

Main Page

2015-07-09T17:44:29Z

FellowTraveler: added link

==Open-Transactions==

'''[http://www.opentransactions.org/open-transactions.pdf Click here for white paper.]'''

The Open-Transactions project is a collaborative effort to develop a robust, commercial-grade, fully-featured, '''free-software toolkit''' implementing the [[OTX|OTX protocol]] as well as a full-strength '''financial cryptography''' [[List_of_Classes|library]], API, GUI, command-line interface, and prototype notary server. The project is managed by a worldwide community of volunteers that use the Internet to communicate, plan, and develop the Open-Transactions toolkit and its related documentation.

===Financial Cryptography===

Financial cryptography means using using strong cryptographic techniques to create secure financial instruments, such as digital signing to create non-repudiable contracts, and encryption to create untraceable digital cash. In OT, transactions are unforgeable, receipts are destructible, and balances cannot be falsified or changed without user consent. OT is able to prove all balances, as well as which instruments are valid, and which transactions have closed, without storing any history except the last signed receipt.

Open-Transactions implements financial instruments as Ricardian Contracts; contracts which can be understood both by humans and manipulated by software.

All contracts in Open-Transactions use the same basic structure: all parties involved sign an agreement which is notarized by an independent third party witness. This technique is known as [[Triple-Signed Receipts]]. Importantly, transactions are formed and signed on the client side first, before being notarized by any server. An OT client is thus ensured that an OT notary server cannot falsify his receipts against his will, since the server can't forge the client's signature.

This basic structure can be built upon to create many types of financial instruments.

===Financial Instruments===

Financial instruments are any representation of a financial agreement between two or more parties.

The simplest financial instrument is a deposit agreement. A custodian of some asset (legal tender, or maybe gold) stores it on behalf of a depositor and agrees to redeem it on demand when presented with proof of a valid claim on the asset.

Other types of financial instruments include securities, of which there can be many variations. A security is an instrument that entitles the bearer to a certain revenue stream, either because it represents a loan or perhaps because it represents equity in a business.

Financial instruments in Open-Transactions have an issuer, who creates the contracts and is responsible for fulfilling the terms, and one or more bearers. Financial instruments are liabilities of the issuer owed to the bearers.

===Working with Financial Instruments===

Open-Transactions is designed to provide the highest security possible for both the issuers and bearers of financial instruments. Servers in Open-Transactions act as notaries which can witness and confirm balances, but cannot change them. Every party associated in a financial instrument can prove their balance to any other party, and no party can alter the balance of any other party without their agreement. Even a malicious notary cannot do this.

Open-Transactions represents quantities of a given unit type as deposit agreements, which are signed by the bearer and a notary.

Portions of a balance may be transferred between users via several asset-independent transaction types, including:

; Transfers
: An atomic movement of funds from one account to a different account, like a bank account-to-account transfer.
; Cheques
: A payment which is not deducted from the sender's account until the recipient claims it.
; Vouchers
: A payment which is deducted from the senders account at the time of creation.
; Invoices
: A payment request which the recipient can opt to pay from any of his accounts.
; Cash
: Anonymous cryptographic tokens which can be securely redeemed by the recipient without revealing the sender.
; Market offers
: Open agreements to exchange a given quantity of one instrument type for a given quantity of another instrument type.
; Smart Contracts
: Customizable agreements between multiple parties, containing user-defined scripted clauses, hooks, and variables.

==Use Cases==

===Encouraged use cases===

Encouraged uses cases are officially supported by Open-Transactions.

====Deposit accounting====

Entities that hold assets on behalf of depositors can use Open-Transactions to issue promissory notes as negotiable instruments.

Examples of such depositories includes:

* Precious metals
* Central bank currencies
* Cryptocurrencies

====Payments====

Users of OT negotiable instruments can authorize recurring payments to pay for services which operate on a billing cycle.

====Bearer Securities====

The negotiable instruments created by Open-Transactions can be used as the basis for financial products such as loans.

===Discouraged use cases===

Discouraged use cases are not supported by Open-Transactions, either because they violate the security requirements, or because they conflict with the philosophical goals of the project.

In many cases, discouraged use cases may be achievable, but users are required to create and support their own smart contracts.

====Third party balance editing====

The only entity in Open-Transactions that can edit a balance is the holder of that balance receipt. Open-Transactions does not and will not include any functionality to bypass this design decision.

------------------

=== More Information ===

[http://opentransactions.org/wiki/index.php/About About Open-Transactions]

This product includes software developed by Ben Laurie for use in the [https://github.com/benlaurie/lucre Lucre] project.

Credit for the OT logo goes to: [http://www.michpalmer.com/ moltenmich]

=== Mailing list and IRC ===

Mailing list: ot-dev@opentransactions.org

[http://opentransactions.org/mailman/listinfo/ot-dev_opentransactions.org Subscribe to mailing list]

IRC channel: '''#opentransactions''' on irc.freenode.net

=== Sponsors and Contributors ===

The OT community gratefully acknowledges the support and contributions of the following individuals and businesses to OT development: Chris Odom, Cameron Garnham, Randy Waterhouse, [[Monetas]].

=== Install Programs ===

[http://nightowl.cc/Moneychanger.dmg Mac OSX install for Moneychanger GUI] Self-contained.
<br />Note: This Mac install of Moneychanger includes the notary server as well.<br />It can be found at: /Applications/moneychanger-qt.app/Contents/MacOS/opentxs-notary

[https://bitcointalk.org/index.php?topic=77301.msg859040#msg859040 (old) Windows binary installer ]

=== White Paper ===

[http://www.opentransactions.org/open-transactions.pdf Open-Transactions White Paper]

=== Source Code ===

[http://github.com/Open-Transactions/opentxs Open-Transactions source code on github] (core library, client API, and 'opentxs' command-line client)

[http://github.com/Open-Transactions/opentxs-notary Notary server source code on github] (Install OT core first)

[http://github.com/Open-Transactions/Moneychanger Moneychanger GUI source code on github] (Install OT core first, and then build Moneychanger with the latest version of Qt Creator)

Main Page

2015-07-09T05:02:36Z

FellowTraveler: /* Source Code */ wording

==Open-Transactions==

'''[http://www.opentransactions.org/open-transactions.pdf Click here for white paper.]'''

The Open-Transactions project is a collaborative effort to develop a robust, commercial-grade, fully-featured, '''free-software toolkit''' implementing the [[OTX|OTX protocol]] as well as a full-strength '''financial cryptography''' [[List_of_Classes|library]], API, GUI, command-line interface, and prototype notary server. The project is managed by a worldwide community of volunteers that use the Internet to communicate, plan, and develop the Open-Transactions toolkit and its related documentation.

===Financial Cryptography===

Financial cryptography means using using strong cryptographic techniques to create secure financial instruments, such as digital signing to create non-repudiable contracts, and encryption to create untraceable digital cash. In OT, transactions are unforgeable, receipts are destructible, and balances cannot be falsified or changed without user consent. OT is able to prove all balances, as well as which instruments are valid, and which transactions have closed, without storing any history except the last signed receipt.

Open-Transactions implements financial instruments as Ricardian Contracts; contracts which can be understood both by humans and manipulated by software.

All contracts in Open-Transactions use the same basic structure: all parties involved sign an agreement which is notarized by an independent third party witness. This technique is known as [[Triple-Signed Receipts]]. Importantly, transactions are formed and signed on the client side first, before being notarized by any server. An OT client is thus ensured that an OT notary server cannot falsify his receipts against his will, since the server can't forge the client's signature.

This basic structure can be built upon to create many types of financial instruments.

===Financial Instruments===

Financial instruments are any representation of a financial agreement between two or more parties.

The simplest financial instrument is a deposit agreement. A custodian of some asset (legal tender, or maybe gold) stores it on behalf of a depositor and agrees to redeem it on demand when presented with proof of a valid claim on the asset.

Other types of financial instruments include securities, of which there can be many variations. A security is an instrument that entitles the bearer to a certain revenue stream, either because it represents a loan or perhaps because it represents equity in a business.

Financial instruments in Open-Transactions have an issuer, who creates the contracts and is responsible for fulfilling the terms, and one or more bearers. Financial instruments are liabilities of the issuer owed to the bearers.

===Working with Financial Instruments===

Open-Transactions is designed to provide the highest security possible for both the issuers and bearers of financial instruments. Servers in Open-Transactions act as notaries which can witness and confirm balances, but cannot change them. Every party associated in a financial instrument can prove their balance to any other party, and no party can alter the balance of any other party without their agreement. Even a malicious notary cannot do this.

Open-Transactions represents quantities of a given unit type as deposit agreements, which are signed by the bearer and a notary.

Portions of a balance may be transferred between users via several asset-independent transaction types, including:

; Transfers
: An atomic movement of funds from one account to a different account, like a bank account-to-account transfer.
; Cheques
: A payment which is not deducted from the sender's account until the recipient claims it.
; Vouchers
: A payment which is deducted from the senders account at the time of creation.
; Invoices
: A payment request which the recipient can opt to pay from any of his accounts.
; Cash
: Anonymous cryptographic tokens which can be securely redeemed by the recipient without revealing the sender.
; Market offers
: Open agreements to exchange a given quantity of one instrument type for a given quantity of another instrument type.
; Smart Contracts
: Customizable agreements between multiple parties, containing user-defined scripted clauses, hooks, and variables.

==Use Cases==

===Encouraged use cases===

Encouraged uses cases are officially supported by Open-Transactions.

====Deposit accounting====

Entities that hold assets on behalf of depositors can use Open-Transactions to issue promissory notes as negotiable instruments.

Examples of such depositories includes:

* Precious metals
* Central bank currencies
* Cryptocurrencies

====Payments====

Users of OT negotiable instruments can authorize recurring payments to pay for services which operate on a billing cycle.

====Bearer Securities====

The negotiable instruments created by Open-Transactions can be used as the basis for financial products such as loans.

===Discouraged use cases===

Discouraged use cases are not supported by Open-Transactions, either because they violate the security requirements, or because they conflict with the philosophical goals of the project.

In many cases, discouraged use cases may be achievable, but users are required to create and support their own smart contracts.

====Third party balance editing====

The only entity in Open-Transactions that can edit a balance is the holder of that balance receipt. Open-Transactions does not and will not include any functionality to bypass this design decision.

------------------

This product includes software developed by Ben Laurie for use in the [https://github.com/benlaurie/lucre Lucre] project.

Credit for the OT logo goes to: [http://www.michpalmer.com/ moltenmich]

=== Mailing list and IRC ===

Mailing list: ot-dev@opentransactions.org

[http://opentransactions.org/mailman/listinfo/ot-dev_opentransactions.org Subscribe to mailing list]

IRC channel: '''#opentransactions''' on irc.freenode.net

=== Sponsors and Contributors ===

The OT community gratefully acknowledges the support and contributions of the following individuals and businesses to OT development: Chris Odom, Cameron Garnham, Randy Waterhouse, [[Monetas]].

=== Install Programs ===

[http://nightowl.cc/Moneychanger.dmg Mac OSX install for Moneychanger GUI] Self-contained.
<br />Note: This Mac install of Moneychanger includes the notary server as well.<br />It can be found at: /Applications/moneychanger-qt.app/Contents/MacOS/opentxs-notary

[https://bitcointalk.org/index.php?topic=77301.msg859040#msg859040 (old) Windows binary installer ]

=== White Paper ===

[http://www.opentransactions.org/open-transactions.pdf Open-Transactions White Paper]

=== Source Code ===

[http://github.com/Open-Transactions/opentxs Open-Transactions source code on github] (core library, client API, and 'opentxs' command-line client)

[http://github.com/Open-Transactions/opentxs-notary Notary server source code on github] (Install OT core first)

[http://github.com/Open-Transactions/Moneychanger Moneychanger GUI source code on github] (Install OT core first, and then build Moneychanger with the latest version of Qt Creator)

Main Page

2015-07-09T00:38:20Z

FellowTraveler: added line

==Open-Transactions==

'''[http://www.opentransactions.org/open-transactions.pdf Click here for white paper.]'''

The Open-Transactions project is a collaborative effort to develop a robust, commercial-grade, fully-featured, '''free-software toolkit''' implementing the [[OTX|OTX protocol]] as well as a full-strength '''financial cryptography''' [[List_of_Classes|library]], API, GUI, command-line interface, and prototype notary server. The project is managed by a worldwide community of volunteers that use the Internet to communicate, plan, and develop the Open-Transactions toolkit and its related documentation.

===Financial Cryptography===

Financial cryptography means using using strong cryptographic techniques to create secure financial instruments, such as digital signing to create non-repudiable contracts, and encryption to create untraceable digital cash. In OT, transactions are unforgeable, receipts are destructible, and balances cannot be falsified or changed without user consent. OT is able to prove all balances, as well as which instruments are valid, and which transactions have closed, without storing any history except the last signed receipt.

Open-Transactions implements financial instruments as Ricardian Contracts; contracts which can be understood both by humans and manipulated by software.

All contracts in Open-Transactions use the same basic structure: all parties involved sign an agreement which is notarized by an independent third party witness. This technique is known as [[Triple-Signed Receipts]]. Importantly, transactions are formed and signed on the client side first, before being notarized by any server. An OT client is thus ensured that an OT notary server cannot falsify his receipts against his will, since the server can't forge the client's signature.

This basic structure can be built upon to create many types of financial instruments.

===Financial Instruments===

Financial instruments are any representation of a financial agreement between two or more parties.

The simplest financial instrument is a deposit agreement. A custodian of some asset (legal tender, or maybe gold) stores it on behalf of a depositor and agrees to redeem it on demand when presented with proof of a valid claim on the asset.

Other types of financial instruments include securities, of which there can be many variations. A security is an instrument that entitles the bearer to a certain revenue stream, either because it represents a loan or perhaps because it represents equity in a business.

Financial instruments in Open-Transactions have an issuer, who creates the contracts and is responsible for fulfilling the terms, and one or more bearers. Financial instruments are liabilities of the issuer owed to the bearers.

===Working with Financial Instruments===

Open-Transactions is designed to provide the highest security possible for both the issuers and bearers of financial instruments. Servers in Open-Transactions act as notaries which can witness and confirm balances, but cannot change them. Every party associated in a financial instrument can prove their balance to any other party, and no party can alter the balance of any other party without their agreement. Even a malicious notary cannot do this.

Open-Transactions represents quantities of a given unit type as deposit agreements, which are signed by the bearer and a notary.

Portions of a balance may be transferred between users via several asset-independent transaction types, including:

; Transfers
: An atomic movement of funds from one account to a different account, like a bank account-to-account transfer.
; Cheques
: A payment which is not deducted from the sender's account until the recipient claims it.
; Vouchers
: A payment which is deducted from the senders account at the time of creation.
; Invoices
: A payment request which the recipient can opt to pay from any of his accounts.
; Cash
: Anonymous cryptographic tokens which can be securely redeemed by the recipient without revealing the sender.
; Market offers
: Open agreements to exchange a given quantity of one instrument type for a given quantity of another instrument type.
; Smart Contracts
: Customizable agreements between multiple parties, containing user-defined scripted clauses, hooks, and variables.

==Use Cases==

===Encouraged use cases===

Encouraged uses cases are officially supported by Open-Transactions.

====Deposit accounting====

Entities that hold assets on behalf of depositors can use Open-Transactions to issue promissory notes as negotiable instruments.

Examples of such depositories includes:

* Precious metals
* Central bank currencies
* Cryptocurrencies

====Payments====

Users of OT negotiable instruments can authorize recurring payments to pay for services which operate on a billing cycle.

====Bearer Securities====

The negotiable instruments created by Open-Transactions can be used as the basis for financial products such as loans.

===Discouraged use cases===

Discouraged use cases are not supported by Open-Transactions, either because they violate the security requirements, or because they conflict with the philosophical goals of the project.

In many cases, discouraged use cases may be achievable, but users are required to create and support their own smart contracts.

====Third party balance editing====

The only entity in Open-Transactions that can edit a balance is the holder of that balance receipt. Open-Transactions does not and will not include any functionality to bypass this design decision.

------------------

This product includes software developed by Ben Laurie for use in the [https://github.com/benlaurie/lucre Lucre] project.

Credit for the OT logo goes to: [http://www.michpalmer.com/ moltenmich]

=== Mailing list and IRC ===

Mailing list: ot-dev@opentransactions.org

[http://opentransactions.org/mailman/listinfo/ot-dev_opentransactions.org Subscribe to mailing list]

IRC channel: '''#opentransactions''' on irc.freenode.net

=== Sponsors and Contributors ===

The OT community gratefully acknowledges the support and contributions of the following individuals and businesses to OT development: Chris Odom, Cameron Garnham, Randy Waterhouse, [[Monetas]].

=== Install Programs ===

[http://nightowl.cc/Moneychanger.dmg Mac OSX install for Moneychanger GUI] Self-contained.
<br />Note: This Mac install of Moneychanger includes the notary server as well.<br />It can be found at: /Applications/moneychanger-qt.app/Contents/MacOS/opentxs-notary

[https://bitcointalk.org/index.php?topic=77301.msg859040#msg859040 (old) Windows binary installer ]

=== White Paper ===

[http://www.opentransactions.org/open-transactions.pdf Open-Transactions White Paper]

=== Source Code ===

[http://github.com/Open-Transactions/opentxs Open-Transactions source code on github] (core library, client API, and 'opentxs' command-line client)

[http://github.com/Open-Transactions/opentxs-notary The Open-Transactions notary server on github] (Install OT core first)

[http://github.com/Open-Transactions/Moneychanger Moneychanger GUI source code on github] (Install OT core first, and then build Moneychanger with the latest version of Qt Creator)

Main Page

2015-07-09T00:37:43Z

FellowTraveler: /* More Information */ removed old stuff

==Open-Transactions==

'''[http://www.opentransactions.org/open-transactions.pdf Click here for white paper.]'''

The Open-Transactions project is a collaborative effort to develop a robust, commercial-grade, fully-featured, '''free-software toolkit''' implementing the [[OTX|OTX protocol]] as well as a full-strength '''financial cryptography''' [[List_of_Classes|library]], API, GUI, command-line interface, and prototype notary server. The project is managed by a worldwide community of volunteers that use the Internet to communicate, plan, and develop the Open-Transactions toolkit and its related documentation.

===Financial Cryptography===

Financial cryptography means using using strong cryptographic techniques to create secure financial instruments, such as digital signing to create non-repudiable contracts, and encryption to create untraceable digital cash. In OT, transactions are unforgeable, receipts are destructible, and balances cannot be falsified or changed without user consent. OT is able to prove all balances, as well as which instruments are valid, and which transactions have closed, without storing any history except the last signed receipt.

Open-Transactions implements financial instruments as Ricardian Contracts; contracts which can be understood both by humans and manipulated by software.

All contracts in Open-Transactions use the same basic structure: all parties involved sign an agreement which is notarized by an independent third party witness. This technique is known as [[Triple-Signed Receipts]]. Importantly, transactions are formed and signed on the client side first, before being notarized by any server. An OT client is thus ensured that an OT notary server cannot falsify his receipts against his will, since the server can't forge the client's signature.

This basic structure can be built upon to create many types of financial instruments.

===Financial Instruments===

Financial instruments are any representation of a financial agreement between two or more parties.

The simplest financial instrument is a deposit agreement. A custodian of some asset (legal tender, or maybe gold) stores it on behalf of a depositor and agrees to redeem it on demand when presented with proof of a valid claim on the asset.

Other types of financial instruments include securities, of which there can be many variations. A security is an instrument that entitles the bearer to a certain revenue stream, either because it represents a loan or perhaps because it represents equity in a business.

Financial instruments in Open-Transactions have an issuer, who creates the contracts and is responsible for fulfilling the terms, and one or more bearers. Financial instruments are liabilities of the issuer owed to the bearers.

===Working with Financial Instruments===

Open-Transactions is designed to provide the highest security possible for both the issuers and bearers of financial instruments. Servers in Open-Transactions act as notaries which can witness and confirm balances, but cannot change them. Every party associated in a financial instrument can prove their balance to any other party, and no party can alter the balance of any other party without their agreement. Even a malicious notary cannot do this.

Open-Transactions represents quantities of a given unit type as deposit agreements, which are signed by the bearer and a notary.

Portions of a balance may be transferred between users via several asset-independent transaction types, including:

; Transfers
: An atomic movement of funds from one account to a different account, like a bank account-to-account transfer.
; Cheques
: A payment which is not deducted from the sender's account until the recipient claims it.
; Vouchers
: A payment which is deducted from the senders account at the time of creation.
; Invoices
: A payment request which the recipient can opt to pay from any of his accounts.
; Cash
: Anonymous cryptographic tokens which can be securely redeemed by the recipient without revealing the sender.
; Market offers
: Open agreements to exchange a given quantity of one instrument type for a given quantity of another instrument type.
; Smart Contracts
: Customizable agreements between multiple parties, containing user-defined scripted clauses, hooks, and variables.

==Use Cases==

===Encouraged use cases===

Encouraged uses cases are officially supported by Open-Transactions.

====Deposit accounting====

Entities that hold assets on behalf of depositors can use Open-Transactions to issue promissory notes as negotiable instruments.

Examples of such depositories includes:

* Precious metals
* Central bank currencies
* Cryptocurrencies

====Payments====

Users of OT negotiable instruments can authorize recurring payments to pay for services which operate on a billing cycle.

====Bearer Securities====

The negotiable instruments created by Open-Transactions can be used as the basis for financial products such as loans.

===Discouraged use cases===

Discouraged use cases are not supported by Open-Transactions, either because they violate the security requirements, or because they conflict with the philosophical goals of the project.

In many cases, discouraged use cases may be achievable, but users are required to create and support their own smart contracts.

====Third party balance editing====

The only entity in Open-Transactions that can edit a balance is the holder of that balance receipt. Open-Transactions does not and will not include any functionality to bypass this design decision.

This product includes software developed by Ben Laurie for use in the [https://github.com/benlaurie/lucre Lucre] project.

Credit for the OT logo goes to: [http://www.michpalmer.com/ moltenmich]

=== Mailing list and IRC ===

Mailing list: ot-dev@opentransactions.org

[http://opentransactions.org/mailman/listinfo/ot-dev_opentransactions.org Subscribe to mailing list]

IRC channel: '''#opentransactions''' on irc.freenode.net

=== Sponsors and Contributors ===

The OT community gratefully acknowledges the support and contributions of the following individuals and businesses to OT development: Chris Odom, Cameron Garnham, Randy Waterhouse, [[Monetas]].

=== Install Programs ===

[http://nightowl.cc/Moneychanger.dmg Mac OSX install for Moneychanger GUI] Self-contained.
<br />Note: This Mac install of Moneychanger includes the notary server as well.<br />It can be found at: /Applications/moneychanger-qt.app/Contents/MacOS/opentxs-notary

[https://bitcointalk.org/index.php?topic=77301.msg859040#msg859040 (old) Windows binary installer ]

=== White Paper ===

[http://www.opentransactions.org/open-transactions.pdf Open-Transactions White Paper]

=== Source Code ===

[http://github.com/Open-Transactions/opentxs Open-Transactions source code on github] (core library, client API, and 'opentxs' command-line client)

[http://github.com/Open-Transactions/opentxs-notary The Open-Transactions notary server on github] (Install OT core first)

[http://github.com/Open-Transactions/Moneychanger Moneychanger GUI source code on github] (Install OT core first, and then build Moneychanger with the latest version of Qt Creator)

About

2015-07-08T22:57:05Z

FellowTraveler: unlinkable

__NOTOC__
<div class="plainlinks">
{| id="mp-topbanner" style="width:100%; background:#f6f6f6; margin-top:1.2em; border:1px solid #ddd;"
| style="width:61%; color:#000;" |

{| style="width:100%; border:none; background:none;"
| style="text-align:center; white-space:nowrap; color:#000;" |
<div style="font-size:162%; border:none; margin:0; padding:.1em; color:#000;">About the Open-Transactions project.</div>
<div style="top:+0.2em; font-size:95%;">Financial cryptography software.</div>
<div id="articlecount" style="width:100%; text-align:center; font-size:85%;">[[Special:Statistics|{{NUMBEROFARTICLES}}]] [[Special:Allpages|articles]].</div>
|}
|}

<div style="float:left; max-width: 550px;">

<big>'''What is Open-Transactions?'''</big>

* Open-Transactions is an [[Use Cases|easy-to-use]], financial crypto, [[Sample Cash|digital cash]] and transaction [[List of Classes|library]].
* Open-Transactions is open-source.
* Open-Transactions includes a [[API|client API]], a working [[Otserver|server]], a cross-platform [https://github.com/Open-Transactions/Moneychanger GUI] and a [[opentxs|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, [http://iang.org/papers/ricardian_contract.html Ricardian contracts], Smart Contracts (scriptable clauses), and more.

<big>'''What does it do?'''</big>

* Open-Transactions allows users to issue and manipulate digital assets.
* Any issuer can sign and distribute new [[Sample Currency Contract|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"''' for maximum anonymity, using '''[[Sample Cash|untraceable digital cash]]'''.

<big>'''Financial Instruments'''</big>
* Users can transfer digital assets ''securely and provably'', with [[Triple-Signed Receipts|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 '''[[Instruments|financial instruments]]''' such as account transfer, '''[[Sample-Cheque|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.

<big>'''Markets, Basket Currencies, and Smart Contracts'''</big>
* Open-Transactions also implements higher-level, '''contract-based transactions''' such as '''payment plans''' and '''markets with trades'''.
* The [[Markets|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]]: <code>!/usr/bin/env ot</code> The entire (mostly) high and low level OT API is available within your scripts.

<big>'''Triple Signed Receipts'''</big>
* 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.

<big>'''Is Open-Transactions [[CENTRALIZED|centralized]]?'''</big>
* No—quite the opposite. Open-Transactions is highly '''decentralized'''.
* Typical centralized servers have power over their users, but in OT, '''no server has power over the clients it serves''', because:
# An OT server does not control user transactions—it merely notarizes them.
# Anyone can operate an OT server, and users can go to any OT server to notarize transactions. Thus OT servers compete with each other to attract users to use their notary services.
# Anyone can download an OT client, and use it to execute transactions on any OT server, or any group of OT servers.
# OT uses triple-signed receipts, so transaction parties have independent cryptographic proof of transactions and balances.
# OT servers do not store user assets. Rather, cryptocurrencies are stored in voting pools so the server can't steal them.

In every way, '''the user is in control, not the server'''—even when you're using servers you do not trust. These characteristics generate a '''federated''' network architecture—similar to the internet, and it has the same virtues as the internet—openness, decentralization, resilience, censorship-resistance, and user control.

The community behind OT is strongly committed to developing systems that give users full control over their own assets and information.

</div>

<div style="float:right; max-width: 300px; margin: -20px 10px 0 20px;">

== White Paper ==

[http://www.opentransactions.org/open-transactions.pdf OT White Paper]

== Diagrams ==

[[Voting_Pool_Deposit_Process|Voting Pools]]

[http://i.imgur.com/HTyAJjg.png Architecture Overview (new)]

[http://billstclair.com/ot/ot-diagram.jpg Architecture Overview (old)]

[http://billstclair.com/ot/OT-Pseudonym-Instruments.jpg Financial Instruments]

== Radio Interviews ==

[https://www.youtube.com/watch?v=teNzIFu5L70 "Trust No One" Miami Speech]

[http://agoristradio.com/?p=234 AgoristRadio Interview, Part 1]

[http://agoristradio.com/?p=246 AgoristRadio Interview, Part 2]

[https://www.youtube.com/watch?v=vtJcUM5-TeA Interview with "Let's Talk Bitcoin"]

[http://www.youtube.com/watch?v=HSgpStCTw2g Interview with FutureMoneyTrends.com]

== Video Walkthrough ==

[https://www.youtube.com/watch?v=5qtTayW-RyM Android demo video (Monetas)]

[http://goo.gl/Ea6rzq Desktop video 1 - Introduction]

[http://goo.gl/i0J3AF Desktop video 2 - Advanced]

[http://goo.gl/8Dxak1 iPhone video 1 - Introduction]

[http://goo.gl/u6xqHc iPhone video 2 - Advanced]

[http://vimeo.com/28141679 java testclient video 1]

[http://vimeo.com/28142096 java testclient video 2]

[http://open-transactions.github.io/tv/ Official video archive (more videos)]

-----

[[Components and GNU Licensing]]

[[Vulnerabilities|Potential vulnerabilities]] of Open-Transactions

== Related Systems ==

[[Monetas]] - Enterprise platform based on OT.

---------

[http://bitcoin.org/ Bitcoin] - A censorship-resistant global ledger

[https://loom.cc/help Loom] - Asset issuance and transactions

[http://www.csee.umbc.edu/~woodcock/cmsc482/proj1/magmoney.html Magic Money] - PGP-based Chaumian blinding (unlinkable cash)

[http://opencoin.org/ OpenCoin.org] - REST-based blinded tokens

[http://www.opentransact.org/ OpenTransact] - REST-based transaction protocol

[https://payswarm.com/ PaySwarm] - REST-based transaction protocol

[https://www.facebook.com/publickeytransaction PKTP] - Public-Key Transaction Processor

[http://wiki.dgcmagazine.com/index.php?title=Ricardo Ricardo] - Transaction system by Ian Grigg

[https://ripple.com/ Ripple] - Consensus-based debt ledger

[https://www.stellar.org/ Stellar] - Ripple-based

[http://truledger.com/ Truledger] - Destruction of account history

[http://www.voucher-safe.com/index.cfm Voucher-Safe] - Secure asset issuance with auditing

---------

Article: [http://pelagic.wavyhill.xsmail.com/Private_Digital_Economy.html Toward a Private Digital Economy]

</div>

<div style="clear: both; padding-top: 40px;">

== In More Detail... ==

The server itself is a [[Transactions|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 '''[[Sample Cash|unlinkable digital cash]]'''. The software uses Chaumian-style, blinded tokens courtesy of the [http://anoncvs.aldigital.co.uk/lucre/ 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 [http://pktp.co.cc/ 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 [[Sample Currency Contract|currency contract]] to the server. (This functionality is comparable to [http://www.systemics.com/docs/sox/overview.html Ricardo] by [http://financialcryptography.com/ Ian Grigg].)
* '''Users can open asset accounts of any type.''' You can have as many as you want, associated with each user account. (See [http://loom.cc/ Loom] by Patrick Chkoreff.)
* [[Triple-Signed Receipts|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 [http://truledger.com/ Truledger] for an [http://truledger.com/doc/plain-english.html 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: [http://szabo.best.vwh.net/contractlanguage.html 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: <pre>#!/usr/local/bin/ot --script</pre>
* 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 '''[[Sample Currency Contract | 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: [http://www.goldstandardinstitute.net/2010/06/what-is-a-real-bill/ 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 [[API]]s''' for '''Java, Ruby, Python, PHP, Perl, C, [http://www.digitalmars.com/d/2.0/overview.html 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 [http://zeromq.org/ 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.

</div>

About

2015-07-08T22:56:45Z

FellowTraveler: updated wording

__NOTOC__
<div class="plainlinks">
{| id="mp-topbanner" style="width:100%; background:#f6f6f6; margin-top:1.2em; border:1px solid #ddd;"
| style="width:61%; color:#000;" |

{| style="width:100%; border:none; background:none;"
| style="text-align:center; white-space:nowrap; color:#000;" |
<div style="font-size:162%; border:none; margin:0; padding:.1em; color:#000;">About the Open-Transactions project.</div>
<div style="top:+0.2em; font-size:95%;">Financial cryptography software.</div>
<div id="articlecount" style="width:100%; text-align:center; font-size:85%;">[[Special:Statistics|{{NUMBEROFARTICLES}}]] [[Special:Allpages|articles]].</div>
|}
|}

<div style="float:left; max-width: 550px;">

<big>'''What is Open-Transactions?'''</big>

* Open-Transactions is an [[Use Cases|easy-to-use]], financial crypto, [[Sample Cash|digital cash]] and transaction [[List of Classes|library]].
* Open-Transactions is open-source.
* Open-Transactions includes a [[API|client API]], a working [[Otserver|server]], a cross-platform [https://github.com/Open-Transactions/Moneychanger GUI] and a [[opentxs|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, [http://iang.org/papers/ricardian_contract.html Ricardian contracts], Smart Contracts (scriptable clauses), and more.

<big>'''What does it do?'''</big>

* Open-Transactions allows users to issue and manipulate digital assets.
* Any issuer can sign and distribute new [[Sample Currency Contract|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"''' for maximum anonymity, using '''[[Sample Cash|unlinkable digital cash]]'''.

<big>'''Financial Instruments'''</big>
* Users can transfer digital assets ''securely and provably'', with [[Triple-Signed Receipts|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 '''[[Instruments|financial instruments]]''' such as account transfer, '''[[Sample-Cheque|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.

<big>'''Markets, Basket Currencies, and Smart Contracts'''</big>
* Open-Transactions also implements higher-level, '''contract-based transactions''' such as '''payment plans''' and '''markets with trades'''.
* The [[Markets|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]]: <code>!/usr/bin/env ot</code> The entire (mostly) high and low level OT API is available within your scripts.

<big>'''Triple Signed Receipts'''</big>
* 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.

<big>'''Is Open-Transactions [[CENTRALIZED|centralized]]?'''</big>
* No—quite the opposite. Open-Transactions is highly '''decentralized'''.
* Typical centralized servers have power over their users, but in OT, '''no server has power over the clients it serves''', because:
# An OT server does not control user transactions—it merely notarizes them.
# Anyone can operate an OT server, and users can go to any OT server to notarize transactions. Thus OT servers compete with each other to attract users to use their notary services.
# Anyone can download an OT client, and use it to execute transactions on any OT server, or any group of OT servers.
# OT uses triple-signed receipts, so transaction parties have independent cryptographic proof of transactions and balances.
# OT servers do not store user assets. Rather, cryptocurrencies are stored in voting pools so the server can't steal them.

In every way, '''the user is in control, not the server'''—even when you're using servers you do not trust. These characteristics generate a '''federated''' network architecture—similar to the internet, and it has the same virtues as the internet—openness, decentralization, resilience, censorship-resistance, and user control.

The community behind OT is strongly committed to developing systems that give users full control over their own assets and information.

</div>

<div style="float:right; max-width: 300px; margin: -20px 10px 0 20px;">

== White Paper ==

[http://www.opentransactions.org/open-transactions.pdf OT White Paper]

== Diagrams ==

[[Voting_Pool_Deposit_Process|Voting Pools]]

[http://i.imgur.com/HTyAJjg.png Architecture Overview (new)]

[http://billstclair.com/ot/ot-diagram.jpg Architecture Overview (old)]

[http://billstclair.com/ot/OT-Pseudonym-Instruments.jpg Financial Instruments]

== Radio Interviews ==

[https://www.youtube.com/watch?v=teNzIFu5L70 "Trust No One" Miami Speech]

[http://agoristradio.com/?p=234 AgoristRadio Interview, Part 1]

[http://agoristradio.com/?p=246 AgoristRadio Interview, Part 2]

[https://www.youtube.com/watch?v=vtJcUM5-TeA Interview with "Let's Talk Bitcoin"]

[http://www.youtube.com/watch?v=HSgpStCTw2g Interview with FutureMoneyTrends.com]

== Video Walkthrough ==

[https://www.youtube.com/watch?v=5qtTayW-RyM Android demo video (Monetas)]

[http://goo.gl/Ea6rzq Desktop video 1 - Introduction]

[http://goo.gl/i0J3AF Desktop video 2 - Advanced]

[http://goo.gl/8Dxak1 iPhone video 1 - Introduction]

[http://goo.gl/u6xqHc iPhone video 2 - Advanced]

[http://vimeo.com/28141679 java testclient video 1]

[http://vimeo.com/28142096 java testclient video 2]

[http://open-transactions.github.io/tv/ Official video archive (more videos)]

-----

[[Components and GNU Licensing]]

[[Vulnerabilities|Potential vulnerabilities]] of Open-Transactions

== Related Systems ==

[[Monetas]] - Enterprise platform based on OT.

---------

[http://bitcoin.org/ Bitcoin] - A censorship-resistant global ledger

[https://loom.cc/help Loom] - Asset issuance and transactions

[http://www.csee.umbc.edu/~woodcock/cmsc482/proj1/magmoney.html Magic Money] - PGP-based Chaumian blinding (unlinkable cash)

[http://opencoin.org/ OpenCoin.org] - REST-based blinded tokens

[http://www.opentransact.org/ OpenTransact] - REST-based transaction protocol

[https://payswarm.com/ PaySwarm] - REST-based transaction protocol

[https://www.facebook.com/publickeytransaction PKTP] - Public-Key Transaction Processor

[http://wiki.dgcmagazine.com/index.php?title=Ricardo Ricardo] - Transaction system by Ian Grigg

[https://ripple.com/ Ripple] - Consensus-based debt ledger

[https://www.stellar.org/ Stellar] - Ripple-based

[http://truledger.com/ Truledger] - Destruction of account history

[http://www.voucher-safe.com/index.cfm Voucher-Safe] - Secure asset issuance with auditing

---------

Article: [http://pelagic.wavyhill.xsmail.com/Private_Digital_Economy.html Toward a Private Digital Economy]

</div>

<div style="clear: both; padding-top: 40px;">

== In More Detail... ==

The server itself is a [[Transactions|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 '''[[Sample Cash|unlinkable digital cash]]'''. The software uses Chaumian-style, blinded tokens courtesy of the [http://anoncvs.aldigital.co.uk/lucre/ 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 [http://pktp.co.cc/ 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 [[Sample Currency Contract|currency contract]] to the server. (This functionality is comparable to [http://www.systemics.com/docs/sox/overview.html Ricardo] by [http://financialcryptography.com/ Ian Grigg].)
* '''Users can open asset accounts of any type.''' You can have as many as you want, associated with each user account. (See [http://loom.cc/ Loom] by Patrick Chkoreff.)
* [[Triple-Signed Receipts|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 [http://truledger.com/ Truledger] for an [http://truledger.com/doc/plain-english.html 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: [http://szabo.best.vwh.net/contractlanguage.html 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: <pre>#!/usr/local/bin/ot --script</pre>
* 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 '''[[Sample Currency Contract | 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: [http://www.goldstandardinstitute.net/2010/06/what-is-a-real-bill/ 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 [[API]]s''' for '''Java, Ruby, Python, PHP, Perl, C, [http://www.digitalmars.com/d/2.0/overview.html 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 [http://zeromq.org/ 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.

</div>

About

2015-07-08T22:55:24Z

FellowTraveler: wording

__NOTOC__
<div class="plainlinks">
{| id="mp-topbanner" style="width:100%; background:#f6f6f6; margin-top:1.2em; border:1px solid #ddd;"
| style="width:61%; color:#000;" |

{| style="width:100%; border:none; background:none;"
| style="text-align:center; white-space:nowrap; color:#000;" |
<div style="font-size:162%; border:none; margin:0; padding:.1em; color:#000;">About the Open-Transactions project.</div>
<div style="top:+0.2em; font-size:95%;">Financial cryptography software.</div>
<div id="articlecount" style="width:100%; text-align:center; font-size:85%;">[[Special:Statistics|{{NUMBEROFARTICLES}}]] [[Special:Allpages|articles]].</div>
|}
|}

<div style="float:left; max-width: 550px;">

<big>'''What is Open-Transactions?'''</big>

* Open-Transactions is an [[Use Cases|easy-to-use]], financial crypto, [[Sample Cash|digital cash]] and transaction [[List of Classes|library]].
* Open-Transactions is open-source.
* Open-Transactions includes a [[API|client API]], a working [[Otserver|server]], a cross-platform [https://github.com/Open-Transactions/Moneychanger GUI] and a [[opentxs|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, [http://iang.org/papers/ricardian_contract.html Ricardian contracts], Smart Contracts (scriptable clauses), and more.

<big>'''What does it do?'''</big>

* Open-Transactions allows users to issue and manipulate digital assets.
* Any issuer can sign and distribute new [[Sample Currency Contract|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 '''[[Sample Cash|unlinkable digital cash]]'''.

<big>'''Financial Instruments'''</big>
* Users can transfer digital assets ''securely and provably'', with [[Triple-Signed Receipts|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 '''[[Instruments|financial instruments]]''' such as account transfer, '''[[Sample-Cheque|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.

<big>'''Markets, Basket Currencies, and Smart Contracts'''</big>
* Open-Transactions also implements higher-level, '''contract-based transactions''' such as '''payment plans''' and '''markets with trades'''.
* The [[Markets|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]]: <code>!/usr/bin/env ot</code> The entire (mostly) high and low level OT API is available within your scripts.

<big>'''Triple Signed Receipts'''</big>
* 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.

<big>'''Is Open-Transactions [[CENTRALIZED|centralized]]?'''</big>
* No—quite the opposite. Open-Transactions is highly '''decentralized'''.
* Typical centralized servers have power over their users, but in OT, '''no server has power over the clients it serves''', because:
# An OT server does not control user transactions—it merely notarizes them.
# Anyone can operate an OT server, and users can go to any OT server to notarize transactions. Thus OT servers compete with each other to attract users to use their notary services.
# Anyone can download an OT client, and use it to execute transactions on any OT server, or any group of OT servers.
# OT uses triple-signed receipts, so transaction parties have independent cryptographic proof of transactions and balances.
# OT servers do not store user assets. Rather, cryptocurrencies are stored in voting pools so the server can't steal them.

In every way, '''the user is in control, not the server'''—even when you're using servers you do not trust. These characteristics generate a '''federated''' network architecture—similar to the internet, and it has the same virtues as the internet—openness, decentralization, resilience, censorship-resistance, and user control.

The community behind OT is strongly committed to developing systems that give users full control over their own assets and information.

</div>

<div style="float:right; max-width: 300px; margin: -20px 10px 0 20px;">

== White Paper ==

[http://www.opentransactions.org/open-transactions.pdf OT White Paper]

== Diagrams ==

[[Voting_Pool_Deposit_Process|Voting Pools]]

[http://i.imgur.com/HTyAJjg.png Architecture Overview (new)]

[http://billstclair.com/ot/ot-diagram.jpg Architecture Overview (old)]

[http://billstclair.com/ot/OT-Pseudonym-Instruments.jpg Financial Instruments]

== Radio Interviews ==

[https://www.youtube.com/watch?v=teNzIFu5L70 "Trust No One" Miami Speech]

[http://agoristradio.com/?p=234 AgoristRadio Interview, Part 1]

[http://agoristradio.com/?p=246 AgoristRadio Interview, Part 2]

[https://www.youtube.com/watch?v=vtJcUM5-TeA Interview with "Let's Talk Bitcoin"]

[http://www.youtube.com/watch?v=HSgpStCTw2g Interview with FutureMoneyTrends.com]

== Video Walkthrough ==

[https://www.youtube.com/watch?v=5qtTayW-RyM Android demo video (Monetas)]

[http://goo.gl/Ea6rzq Desktop video 1 - Introduction]

[http://goo.gl/i0J3AF Desktop video 2 - Advanced]

[http://goo.gl/8Dxak1 iPhone video 1 - Introduction]

[http://goo.gl/u6xqHc iPhone video 2 - Advanced]

[http://vimeo.com/28141679 java testclient video 1]

[http://vimeo.com/28142096 java testclient video 2]

[http://open-transactions.github.io/tv/ Official video archive (more videos)]

-----

[[Components and GNU Licensing]]

[[Vulnerabilities|Potential vulnerabilities]] of Open-Transactions

== Related Systems ==

[[Monetas]] - Enterprise platform based on OT.

---------

[http://bitcoin.org/ Bitcoin] - A censorship-resistant global ledger

[https://loom.cc/help Loom] - Asset issuance and transactions

[http://www.csee.umbc.edu/~woodcock/cmsc482/proj1/magmoney.html Magic Money] - PGP-based Chaumian blinding (unlinkable cash)

[http://opencoin.org/ OpenCoin.org] - REST-based blinded tokens

[http://www.opentransact.org/ OpenTransact] - REST-based transaction protocol

[https://payswarm.com/ PaySwarm] - REST-based transaction protocol

[https://www.facebook.com/publickeytransaction PKTP] - Public-Key Transaction Processor

[http://wiki.dgcmagazine.com/index.php?title=Ricardo Ricardo] - Transaction system by Ian Grigg

[https://ripple.com/ Ripple] - Consensus-based debt ledger

[https://www.stellar.org/ Stellar] - Ripple-based

[http://truledger.com/ Truledger] - Destruction of account history

[http://www.voucher-safe.com/index.cfm Voucher-Safe] - Secure asset issuance with auditing

---------

Article: [http://pelagic.wavyhill.xsmail.com/Private_Digital_Economy.html Toward a Private Digital Economy]

</div>

<div style="clear: both; padding-top: 40px;">

== In More Detail... ==

The server itself is a [[Transactions|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 '''[[Sample Cash|unlinkable digital cash]]'''. The software uses Chaumian-style, blinded tokens courtesy of the [http://anoncvs.aldigital.co.uk/lucre/ 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 [http://pktp.co.cc/ 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 [[Sample Currency Contract|currency contract]] to the server. (This functionality is comparable to [http://www.systemics.com/docs/sox/overview.html Ricardo] by [http://financialcryptography.com/ Ian Grigg].)
* '''Users can open asset accounts of any type.''' You can have as many as you want, associated with each user account. (See [http://loom.cc/ Loom] by Patrick Chkoreff.)
* [[Triple-Signed Receipts|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 [http://truledger.com/ Truledger] for an [http://truledger.com/doc/plain-english.html 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: [http://szabo.best.vwh.net/contractlanguage.html 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: <pre>#!/usr/local/bin/ot --script</pre>
* 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 '''[[Sample Currency Contract | 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: [http://www.goldstandardinstitute.net/2010/06/what-is-a-real-bill/ 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 [[API]]s''' for '''Java, Ruby, Python, PHP, Perl, C, [http://www.digitalmars.com/d/2.0/overview.html 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 [http://zeromq.org/ 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.

</div>

About

2015-07-08T22:55:00Z

FellowTraveler: updated GUI link

__NOTOC__
<div class="plainlinks">
{| id="mp-topbanner" style="width:100%; background:#f6f6f6; margin-top:1.2em; border:1px solid #ddd;"
| style="width:61%; color:#000;" |

{| style="width:100%; border:none; background:none;"
| style="text-align:center; white-space:nowrap; color:#000;" |
<div style="font-size:162%; border:none; margin:0; padding:.1em; color:#000;">About the Open-Transactions project.</div>
<div style="top:+0.2em; font-size:95%;">Financial cryptography software.</div>
<div id="articlecount" style="width:100%; text-align:center; font-size:85%;">[[Special:Statistics|{{NUMBEROFARTICLES}}]] [[Special:Allpages|articles]].</div>
|}
|}

<div style="float:left; max-width: 550px;">

<big>'''What is Open-Transactions?'''</big>

* Open-Transactions is an [[Use Cases|easy-to-use]], financial crypto, [[Sample Cash|digital cash]] and transaction [[List of Classes|library]].
* Open-Transactions is open-source.
* Open-Transactions includes a [[API|client API]], a working [[Otserver|server]], a cross-platform [https://github.com/Open-Transactions/Moneychanger desktop GUI] and a [[opentxs|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, [http://iang.org/papers/ricardian_contract.html Ricardian contracts], Smart Contracts (scriptable clauses), and more.

<big>'''What does it do?'''</big>

* Open-Transactions allows users to issue and manipulate digital assets.
* Any issuer can sign and distribute new [[Sample Currency Contract|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 '''[[Sample Cash|unlinkable digital cash]]'''.

<big>'''Financial Instruments'''</big>
* Users can transfer digital assets ''securely and provably'', with [[Triple-Signed Receipts|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 '''[[Instruments|financial instruments]]''' such as account transfer, '''[[Sample-Cheque|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.

<big>'''Markets, Basket Currencies, and Smart Contracts'''</big>
* Open-Transactions also implements higher-level, '''contract-based transactions''' such as '''payment plans''' and '''markets with trades'''.
* The [[Markets|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]]: <code>!/usr/bin/env ot</code> The entire (mostly) high and low level OT API is available within your scripts.

<big>'''Triple Signed Receipts'''</big>
* 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.

<big>'''Is Open-Transactions [[CENTRALIZED|centralized]]?'''</big>
* No—quite the opposite. Open-Transactions is highly '''decentralized'''.
* Typical centralized servers have power over their users, but in OT, '''no server has power over the clients it serves''', because:
# An OT server does not control user transactions—it merely notarizes them.
# Anyone can operate an OT server, and users can go to any OT server to notarize transactions. Thus OT servers compete with each other to attract users to use their notary services.
# Anyone can download an OT client, and use it to execute transactions on any OT server, or any group of OT servers.
# OT uses triple-signed receipts, so transaction parties have independent cryptographic proof of transactions and balances.
# OT servers do not store user assets. Rather, cryptocurrencies are stored in voting pools so the server can't steal them.

In every way, '''the user is in control, not the server'''—even when you're using servers you do not trust. These characteristics generate a '''federated''' network architecture—similar to the internet, and it has the same virtues as the internet—openness, decentralization, resilience, censorship-resistance, and user control.

The community behind OT is strongly committed to developing systems that give users full control over their own assets and information.

</div>

<div style="float:right; max-width: 300px; margin: -20px 10px 0 20px;">

== White Paper ==

[http://www.opentransactions.org/open-transactions.pdf OT White Paper]

== Diagrams ==

[[Voting_Pool_Deposit_Process|Voting Pools]]

[http://i.imgur.com/HTyAJjg.png Architecture Overview (new)]

[http://billstclair.com/ot/ot-diagram.jpg Architecture Overview (old)]

[http://billstclair.com/ot/OT-Pseudonym-Instruments.jpg Financial Instruments]

== Radio Interviews ==

[https://www.youtube.com/watch?v=teNzIFu5L70 "Trust No One" Miami Speech]

[http://agoristradio.com/?p=234 AgoristRadio Interview, Part 1]

[http://agoristradio.com/?p=246 AgoristRadio Interview, Part 2]

[https://www.youtube.com/watch?v=vtJcUM5-TeA Interview with "Let's Talk Bitcoin"]

[http://www.youtube.com/watch?v=HSgpStCTw2g Interview with FutureMoneyTrends.com]

== Video Walkthrough ==

[https://www.youtube.com/watch?v=5qtTayW-RyM Android demo video (Monetas)]

[http://goo.gl/Ea6rzq Desktop video 1 - Introduction]

[http://goo.gl/i0J3AF Desktop video 2 - Advanced]

[http://goo.gl/8Dxak1 iPhone video 1 - Introduction]

[http://goo.gl/u6xqHc iPhone video 2 - Advanced]

[http://vimeo.com/28141679 java testclient video 1]

[http://vimeo.com/28142096 java testclient video 2]

[http://open-transactions.github.io/tv/ Official video archive (more videos)]

-----

[[Components and GNU Licensing]]

[[Vulnerabilities|Potential vulnerabilities]] of Open-Transactions

== Related Systems ==

[[Monetas]] - Enterprise platform based on OT.

---------

[http://bitcoin.org/ Bitcoin] - A censorship-resistant global ledger

[https://loom.cc/help Loom] - Asset issuance and transactions

[http://www.csee.umbc.edu/~woodcock/cmsc482/proj1/magmoney.html Magic Money] - PGP-based Chaumian blinding (unlinkable cash)

[http://opencoin.org/ OpenCoin.org] - REST-based blinded tokens

[http://www.opentransact.org/ OpenTransact] - REST-based transaction protocol

[https://payswarm.com/ PaySwarm] - REST-based transaction protocol

[https://www.facebook.com/publickeytransaction PKTP] - Public-Key Transaction Processor

[http://wiki.dgcmagazine.com/index.php?title=Ricardo Ricardo] - Transaction system by Ian Grigg

[https://ripple.com/ Ripple] - Consensus-based debt ledger

[https://www.stellar.org/ Stellar] - Ripple-based

[http://truledger.com/ Truledger] - Destruction of account history

[http://www.voucher-safe.com/index.cfm Voucher-Safe] - Secure asset issuance with auditing

---------

Article: [http://pelagic.wavyhill.xsmail.com/Private_Digital_Economy.html Toward a Private Digital Economy]

</div>

<div style="clear: both; padding-top: 40px;">

== In More Detail... ==

The server itself is a [[Transactions|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 '''[[Sample Cash|unlinkable digital cash]]'''. The software uses Chaumian-style, blinded tokens courtesy of the [http://anoncvs.aldigital.co.uk/lucre/ 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 [http://pktp.co.cc/ 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 [[Sample Currency Contract|currency contract]] to the server. (This functionality is comparable to [http://www.systemics.com/docs/sox/overview.html Ricardo] by [http://financialcryptography.com/ Ian Grigg].)
* '''Users can open asset accounts of any type.''' You can have as many as you want, associated with each user account. (See [http://loom.cc/ Loom] by Patrick Chkoreff.)
* [[Triple-Signed Receipts|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 [http://truledger.com/ Truledger] for an [http://truledger.com/doc/plain-english.html 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: [http://szabo.best.vwh.net/contractlanguage.html 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: <pre>#!/usr/local/bin/ot --script</pre>
* 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 '''[[Sample Currency Contract | 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: [http://www.goldstandardinstitute.net/2010/06/what-is-a-real-bill/ 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 [[API]]s''' for '''Java, Ruby, Python, PHP, Perl, C, [http://www.digitalmars.com/d/2.0/overview.html 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 [http://zeromq.org/ 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.

</div>

API

2015-07-08T22:53:49Z

FellowTraveler: slight re-arrangement

=== API Docs ===
* [https://github.com/Open-Transactions/opentxs/blob/develop/include/opentxs/client/OT_ME.hpp#L116 High-level API (C++)]

* [https://github.com/Open-Transactions/opentxs/blob/develop/include/opentxs/client/OTAPI.hpp#L71 Low-level API (C++)]

The above two APIs are wrapped with SWIG, and thus available in [https://github.com/Open-Transactions/opentxs/tree/develop/wrappers many other languages.]

The general rule of thumb is: When coding, always prefer the high-level API. Only use the low-level API for functions where no high-level API version is available. If you are writing software that uses OT, and you need to copy some sample code, just get it from [https://github.com/Open-Transactions/Moneychanger the Moneychanger GUI.]

----------------------

NOTE: This page is old, but preserved in case of any usefulness.

=== Introduction ===
* See the [https://github.com/FellowTraveler/Open-Transactions/blob/master/include/otapi/OTMadeEasy.h#L159 OTMadeEasy] class, as well as the sample scripts provided in [https://github.com/FellowTraveler/Open-Transactions/blob/master/scripts/demo/php/php_ot_test.php PHP] [https://github.com/FellowTraveler/Open-Transactions/blob/master/scripts/demo/python/python_ot_test.py Python] and [https://github.com/FellowTraveler/Open-Transactions/blob/master/scripts/demo/csharp/Main.cs C-Sharp].

* OT's high-level API is also available in OT [https://github.com/FellowTraveler/Open-Transactions/wiki/Client-side-scripting client-side scripts]

* The '''opentxs list''' and [https://github.com/FellowTraveler/Open-Transactions/wiki/opentxs opentxs help] commands display a complete list of all the OT API functions available on the command line. The actual code for those commands, written using the OT high-level API, [https://github.com/FellowTraveler/Open-Transactions/blob/master/scripts/ot/ot_commands.ot#L1288 is available here for your perusal]. This way, you can test the complete OT functionality at the command line, and then flip through the actual code for each command, and see how the OT API calls are used. '''You might be surprised how simple they really are.'''

* With that as your guide, a general rule of thumb is this: Anytime you need to do something, use the [https://github.com/FellowTraveler/Open-Transactions/blob/master/include/otapi/OTMadeEasy.h#L159 high-level API] to do it. Only if you can't find the function you are looking for, should you next resort to the [https://github.com/FellowTraveler/Open-Transactions/blob/master/include/otapi/OTAPI_Basic.h#L170 low-level API]. And remember, you can always the copy the code you need from the [https://github.com/FellowTraveler/Open-Transactions/blob/master/scripts/ot/ot_commands.ot#L1288 opentxs] tool, or from the test GUI, [http://github.com/FellowTraveler/otapij otapiJ].

What does this mean for you? It means you no longer have to worry about synchronizing request numbers, or harvesting transaction numbers, or comparing inbox hashes, or downloading your nymbox, or dropped messages, or timeouts, or retries, etc! Instead, you use simple functions like '''send_transfer''' or '''withdraw_cash'''. The high-level API manages everything else behind the scenes.

The OT high-level API (OTMadeEasy) is now available in these languages: [http://www.chaiscript.com/ ChaiScript] ( [https://github.com/FellowTraveler/Open-Transactions/blob/master/include/otapi/OTMadeEasy.h#L159 ot script] ) and Java, CSharp, PHP, Python, D, Perl, and TCL. The [https://github.com/FellowTraveler/Open-Transactions/blob/master/include/otapi/OTAPI_Basic.h#L170 low-level API] is available in D, Python, PHP, Perl, Java, etc. (Via [http://www.swig.org/ SWIG] wrappers.)

=== USE CASES for the OT API ===

* '''(Client software starts up.)''' Initialize the library and load the wallet.
* Display for user: '''Server Contracts, Nyms, Accounts, and Asset Types.'''
* Change the wallet's ''display label'' for any server, asset type, account, or nym.
* Import a server contract (or asset contract) to the wallet.
* Create a new '''Pseudonym''' (public/private key pair).
* Register a public key (a ''"Nym"'') at an OT server.
* '''Issue a new digital Asset Type'''. (Uploading an asset contract.)
* Retrieve Currency Contract (by ID).
* '''Create a new Asset Account'''.
* '''Write a cheque''' (or invoice)
* '''Send a Message''' to another user (via the server, encrypted to the recipient's public key.)
* '''Deposit a cheque'''
* '''Withdraw cash''' . . . . <==== CHAUMIAN DIGITAL CASH!!
* '''Deposit cash'''
* Withdraw Voucher
* '''Account-to-Account Transfer'''
* Create a new '''Basket Currency'''
* '''Exchange''' Digital Assets '''in and out of Baskets''' (from your Asset Accounts)
* '''Process your Inbox''' (Receipts and pending transfers)
* Set up a '''Payment Plan'''
* Issue a '''Market Offer'''

-------

'''Initialize the library and Load your Wallet'''

(The user starts up the wallet software.)

Call '''OT_API_Init()'''

Then call '''OT_API_LoadWallet()'''

(NOTE: these above 2 steps are not necessary in OT-script, only Java and other languages.)

'''Display the current list of server contracts on the screen'''

Call '''OT_API_GetServerCount()''', which returns the number of server contracts in your wallet.

For each one, call '''OT_API_GetServer_ID()''' to get the Server ID (which is a hash of the contract.)

Also for each, call '''OT_API_GetServer_Name()''' to get the Display Name from the contract.

In your GUI, display the name on the screen, but use the ID behind the scenes (for your messages to the server.)

'''Do the same thing for Nyms, Accounts, and Asset Types.'''

You can read about them on the [[API]] page, but here are the basic functions:

OT_API_GetNymCount(void);

OT_API_GetServerCount(void);

OT_API_GetAssetTypeCount(void);

OT_API_GetAccountCount(void);

OT_API_GetNym_ID() and OT_API_GetNym_Name()

OT_API_GetServer_ID() and OT_API_GetServer_Name()

OT_API_GetAssetType_ID() and OT_API_GetAssetType_Name()

OT_API_GetAccountWallet_ID() and OT_API_GetAccountWallet_Name()

Also:

OT_API_GetAccountWallet_Balance()

OT_API_GetAccountWallet_Type()

OT_API_GetAccountWallet_AssetTypeID()

'''Add a new server contract (or asset contract) to the wallet'''

Call '''OT_API_AddServerContract()'''

or '''OT_API_AddAssetContract()'''.

'''Create a new Pseudonym'''

(Each user's wallet may contain many pseudonyms. Each Nym consists of a public and a private key, aka a "key pair".)

Call '''OT_API_CreateNym()'''

This creates a new key pair _("Nym")_ in your wallet, which you can use for communications with an OT server.

(That is, for opening asset accounts and performing various other transactions. A Nym is a "user account".)

(You can create as many of these pseudonyms as you want.)

(You can register the same nyms at multiple servers.)

(The same Nym will have the same Nym ID and public key on every server.)

Example

<pre>
def details_create_nym(nKeybits, strName)
{
var madeEasy = OT_ME()
var strNymID = madeEasy.create_pseudonym(nKeybits, "", "") // returns new Nym ID

if (!VerifyStringVal(strNymID))
{
OT_API_Output(0, "details_create_nym: Failed in OT_ME::create_pseudonym(keybits == " + nKeybits.to_string() + ")\n")
return (0)
}
OT_API_Output(0, "Success creating! " + nKeybits.to_string() + " keybits, new ID: ") // stderr
print(strNymID) // stdout
OT_API_Output(0, "\n") //stderr
// -------------------
var bSetName = OT_API_SetNym_Name(strNymID, // subject
strNymID, // signer
strName)
if (!bSetName)
{
OT_API_Output(0, "Failed in OT_API_SetNym_Name(name == " + strName + ")\n")
return (0)
}
// -------------------
OT_API_Output(0, "Success setting name to: " + strName + "\n\n") // stderr
return 1
}
</pre>

'''Register a public key (aka "Nym") at an OT server'''

<pre>
var madeEasy = OT_ME()
if (VerifyExists("Server") && VerifyExists("MyNym"))
{
var strResponse = madeEasy.register_nym(Server, MyNym)
var nSuccess = VerifyMessageSuccess(strResponse)
switch(nSuccess)
{
case (1)
{
OT_API_Output(0, "\n\n SUCCESS in register_nym! Server response:\n\n");
print(strResponse) // stdout
break
}
default
{
OT_API_Output(0, "\n\n Failure or Error in register_nym!\n")

if (VerifyStringVal(strResponse))
{
OT_API_Output(0, "Server response:\n\n");
print(strResponse) // stdout
}
break
}
}
</pre>

'''Change the wallet's label for any server/asset type/account/nym'''

(This is only a client-side label, for display purposes only.)

'''OT_API_SetNym_Name()'''

'''OT_API_SetAccountWallet_Name()'''

'''OT_API_SetAssetType_Name()'''

'''OT_API_SetServer_Name()'''

----------------------------

'''Issue a new digital Asset Type'''

User uploads a new currency contract to the server, so users can create asset accounts based on that asset type.

Server replies with a new issuer account ID (The new Issuer account appears inside your wallet's account list, so go ahead and iterate the list again, in order to display the updated list of accounts on the screen.)

High-level API version (in OT script):

<pre>
var madeEasy = OT_ME()
OT_API_Output(0, "Please paste a currency contract, followed by an EOF or a ~ by itself on a blank line:\n\n")
var strContract = OT_CLI_ReadUntilEOF()
var strResponse = madeEasy.issue_asset_type(Server, MyNym, strContract)
var nStatus = VerifyMessageSuccess(strResponse)

switch(nStatus)
{
case (1)
{
OT_API_Output(0, "\n\n SUCCESS in issue_asset! Server response:\n\n");
print(strResponse) // stdout
break
}
default
{
OT_API_Output(0, "\n\n Failure or error in issue_asset. nStatus: "+nStatus.to_string()+"\n")
if (VerifyStringVal(strResponse))
{
OT_API_Output(0, "Server response:\n\n");
print(strResponse) // stdout
}
break
}
}
</pre>

'''Retrieve Currency Contract (by ID)'''

User wants to download a currency contract from the server (for a given asset type ID.)

(The asset type ID is a hash of the contract, so OT will know if you get the wrong one, since this is verified whenever a contract is loaded up.)

High-level API version (in OT script):

<pre>
var madeEasy = OT_ME()
var strRetrieved = madeEasy.retrieve_contract(Server, MyNym, strContractID)
var nRetrieved = VerifyMessageSuccess(strRetrieved)
var strSuccess = "ERROR"
if (1 == nRetrieved)
{ strSuccess = "SUCCESS" }
else if (0 == nRetrieved)
{ strSuccess = "FAILED" }
OT_API_Output(0, "\n\n " + strSuccess + " retrieving contract: "+strContractID+"\n\n")
</pre>

'''Create a new Asset Account'''

Example in OT Script, from the "sample scripts":https://github.com/FellowTraveler/Open-Transactions/tree/master/scripts/samples folder:

<pre>
def OT_ME::create_asset_acct(SERVER_ID, NYM_ID, ASSET_TYPE_ID)
{
var ot_Msg := OTAPI_Func()
// -------------------------
var theRequest := OTAPI_Func(ot_Msg.CREATE_ASSET_ACCT, SERVER_ID, NYM_ID, ASSET_TYPE_ID)
var strResponse = theRequest.SendRequest(theRequest, "CREATE_ASSET_ACCT")

return strResponse
}
</pre>

If it was a SUCCESS, then refresh the list of accounts in your display (from the OT API) since your new asset account should now be there.

(You can also use the "decode" command in the test wallet anytime you want to base64-decode something.)

--------------------------

'''TRANSACTIONS'''

FYI: Balance agreement, combined with transaction numbers, is what makes it possible for the server and all other parties to _eliminate account history, instead storing only the last signed receipt._ (Of course they have the ''choice'' to keep their own records--but they are no longer ''forced'' to do so.)

In order to do any transaction, the wallet's _balance agreement_ process requires that you have the latest copy of your account, inbox, and outbox files. You don't have to worry about this too much, since the high-level API will usually handle it for you.

'''You might ask: ''"But what if I download my account, or my outbox, and the server has maliciously inserted data into them?"'' '''
''No problem'' -- Open Transactions stores the last signed receipt from the server, and is able to verify the new intermediary files against that last receipt. You can see this happening when you run the command-line test client, and receipts can be verified programmatically using '''OT_API_VerifyAccountReceipt()'''.

The [[Triple-Signed Receipts]] on Open Transactions ensure that this sort of protection is available to all parties, '''while simultaneously not having to store any transaction history!'''

------------------

'''Write a Cheque'''

Alice writes a cheque (offline): Call '''OT_API_WriteCheque()'''

Alice then gives cheque to Bob (offline), _or_ online if she prefers via '''OT_API_sendUserMessage()''' function.

If Alice has Bob's UserID but not his public key, her wallet first uses '''OT_API_checkUser()''' to retrieve his public key from the server, and then encrypts the cheque before sending it.

NOTE: a quality wallet software will keep track of ALL instruments! Even when Alice gives a cheque to Bob, her wallet should still store a copy of that cheque. Until when? Until at least after he has cashed it... when he does that, a chequeReceipt will appear in her inbox. Only when she accepts that receipt, signing a new balance agreement, is she finally free of the transaction number that was on that cheque. (It was still signed-out to her, all the way up until that time.)

WHAT IF Bob had never cashed it? WHAT IF he lost it? Is Alice supposed to just keep signing for that number forever? (The chequeReceipt will never appear in her inbox. She is doomed to continue signing for this number on all of her receipts on into the future, ad infinitum, with no hope of ever closing it out!)

Fear not, there is a solution: '''OT_API_DiscardCheque()'''. (Lucky you saved a copy of that cheque in your wallet, eh?) This function will retrieve Alice's transaction # back from the cheque, so that her wallet is free to use it on her next valid transaction, and then close it out normally.

'''Deposit a cheque'''

(A voucher is also a cheque, so you may deposit a voucher here the same as any other cheque.)

Bob sends message to server requesting deposit:

'''(High level API version, in Java.)'''

<pre>
public boolean depositCheque(String serverID, String nymID, String accountID, String cheque) {

System.out.println("In depositCheque serverID:" + serverID + " nymID:" + nymID + " acount ID:" + accountID);

// ---------------------------------------------------
OTAPI_Func theRequest = new OTAPI_Func(OTAPI_Func.FT.DEPOSIT_CHEQUE, serverID, nymID, accountID, cheque);
String strResponse = OTAPI_Func.SendTransaction(theRequest, "DEPOSIT_CHEQUE"); // <========================

if (null == strResponse) {
System.out.println("OTAPI_Func.SendTransaction() failed, in depositCheque.");
return false;
}
// --------------------------------------------------------------------------------------

return true;
}
</pre>

'''Withdraw cash'''

Alice's wallet first makes sure she has the latest public mint file, by calling '''OT_API_getMint()'''.

(Note: if the mint she already has is within its valid date range, there's no need to do this.)

(Note: If she does call getMint, Alice needs to check the server reply and make sure it was successful before continuing with the withdrawal. The public mint keys are necessary for cash withdrawal.)

Alice then withdraws from her asset account, by messaging server: '''OT_API_notarizeWithdrawal()'''

Server replies with chaumian cash, which is stored in the purse folder in local storage.

Here is the full Java implementation of Withdraw Cash:

<pre>
public boolean withdrawCash(String serverID, String nymID, String accountID, String amount)
{
String serverResponseMessage = null;
System.out.println("In withdrawCash serverID:" + serverID + " nymID:" + nymID + " acount ID:" + accountID);
String assetID = otapi.OT_API_GetAccountWallet_AssetTypeID(accountID);

// ----------------------------------------
// Make sure we have the proper asset contract for the withdrawal.
//
String assetContract = otapi.OT_API_LoadAssetContract(assetID);
if (assetContract == null) {
OTAPI_Func theRequest = new OTAPI_Func(OTAPI_Func.FT.GET_CONTRACT, serverID, nymID, assetID);
String strResponse = OTAPI_Func.SendRequest(theRequest, "GET_CONTRACT");

if (null == strResponse) {
System.out.println("IN withdrawCash: OTAPI_Func.SendRequest(GET_CONTRACT) failed. (I give up.) (Unable to find asset contract.)");
return false;
}
// ----------------------------------------
assetContract = otapi.OT_API_LoadAssetContract(assetID);
if (assetContract == null) {
System.out.println("OT_API_LoadAssetContract returned null even after OT_API_getContract (Unable to find asset contract.)");
return false;
}
}
// ---------------------------------------------------------
// Download the public mintfile if it's not there, or if it's expired.
// Also load it up into memory as a string (just to make sure it works.)
// Then we can actually send the withdrawal transaction request. (Until
// then, why bother?)
//
String mintFile;

// expired or missing.
if (1 != otapi.OT_API_Mint_IsStillGood(serverID, assetID))
{
// ----------------------------------------
OTAPI_Func theRequest = new OTAPI_Func(OTAPI_Func.FT.GET_MINT, serverID, nymID, assetID);
String strResponse = OTAPI_Func.SendRequest(theRequest, "GET_MINT");

if (null == strResponse) {
System.out.println("IN withdrawCash: OTAPI_Func.SendRequest(GET_MINT) failed. (I give up.) (Unable to get mint.)");
return false;
}
// ----------------------------------------
mintFile = otapi.OT_API_LoadMint(serverID, assetID);
if (mintFile == null) {
System.out.println("OT_API_LoadMint returned null even after OT_API_getMint (I give up.) (Unable to find mint.)");
return false;
}
}
else // current mint IS available already on local storage (and not expired.)
{
mintFile = otapi.OT_API_LoadMint(serverID, assetID);
if (mintFile == null) {
System.out.println("OT_API_LoadMint returned null even after successful OT_API_Mint_IsStillGood (I give up.) (Unable to find mint.)");
return false;
}
}
// ---------------------------------------------------
// By this point, the mintfile is DEFINITELY good (available, not null,
// not expired, and loaded up.) Now we know for a fact that when the API
// call is made to withdraw cash, that it will find the mint properly.
//
OTAPI_Func theRequest = new OTAPI_Func(OTAPI_Func.FT.WITHDRAW_CASH, serverID, nymID, accountID, amount);
String strResponse = OTAPI_Func.SendTransaction(theRequest, "WITHDRAW_CASH"); // <========================

if (null == strResponse) {
System.out.println("OTAPI_Func.SendTransaction() failed, in withdrawCash.");
return false;
}
// --------------------------------------------------------------------------------------

return true;
}
</pre>

'''Deposit cash'''

Here is the complete Java implementation for Deposit Cash:

<pre>
public boolean depositCash(String serverID, String nymID, String accountID, String purse, boolean isToken) {

System.out.println("In depositCash serverID:" + serverID + " nymID:" + nymID + " acount ID:" + accountID + " isToken:" + isToken);
Utility.setOtDepositCash(null);
String oldPurse = purse;
if (isToken) {
purse = getNewPurse(purse, serverID, nymID, accountID);
System.out.println("purse after getting from push purse:" + purse);
if (purse == null) {
Utility.setOtDepositCash(oldPurse);
return false;
}
}
// ----------------------------------------
OTAPI_Func theRequest = new OTAPI_Func(OTAPI_Func.FT.DEPOSIT_CASH, serverID, nymID, accountID, purse);
String strResponse = OTAPI_Func.SendTransaction(theRequest, "DEPOSIT_CASH"); // <========================

if (null == strResponse) {
System.out.println("IN depositCash: OTAPI_Func.SendTransaction(() failed. (I give up.) ");

if (isToken) {
System.out.println("IN depositCash, failed action for single token");
String assetID = otapi.OT_API_GetAccountWallet_AssetTypeID(accountID);
boolean importStatus = otapi.OT_API_Wallet_ImportPurse(serverID, assetID, nymID, purse) == 1 ? true : false;
System.out.println("Since failure of depositCashPurse, OT_API_Wallet_ImportPurse called, status of import:" + importStatus);
if (!importStatus) {
Utility.setOtDepositCash(purse);
}
}

return false;
}
// ----------------------------------------
return true;
}
</pre>

--------------------------------------

Note about local storage: Usually whenever something important is downloaded from the server, the OT API will save it automatically to the default storage context, and you can then load it up using another API call. This is usually the most convenient way to do things.

--------------------------------------

'''Account-to-Account Transfer'''

A _pending transfer_ will go into your outbox, and the recipient's inbox, pending acceptance by the recipient.

FYI, every asset account has its own inbox and outbox for handling pending transactions, as well as receipts.

FYI, every Nym similarly has its own Nymbox, used for receiving messages from other users, and for receiving new transaction numbers from the server.

Here is the OT Script implementation of Send Transfer, from the "sample scripts":https://github.com/FellowTraveler/Open-Transactions/tree/master/scripts/samples folder:

<pre>
def OT_ME::send_transfer(SERVER_ID, NYM_ID, ACCT_FROM, ACCT_TO, AMOUNT, NOTE)
{
var ot_Msg := OTAPI_Func()
// -------------------------
var theRequest := OTAPI_Func(ot_Msg.SEND_TRANSFER, SERVER_ID, NYM_ID, ACCT_FROM, ACCT_TO, AMOUNT, NOTE)
var strResponse = theRequest.SendTransaction(theRequest, "SEND_TRANSFER")

return strResponse
}
</pre>

'''Withdraw Voucher'''

A voucher is like a "money order" or "cashier's cheque". It's a cheque, but drawn on a server account, instead of your own account.

Withdrawing in voucher form is similar to withdrawing in cash: the server debits your asset account, and then gives you an official cheque.

But with cash, it's automatically saved to your purse, whereas with a voucher, you have to read the voucher out of the server reply, and display it on the screen!

Here is the complete Java code to perform Withdraw Voucher:

<pre>
public String withdrawVoucher(String serverID, String nymID, String accountID, String amount, String chequeMemo, String recepientNymID) {

System.out.println("In withdrawVoucher serverID:" + serverID + " nymID:" + nymID + " acount ID:" + accountID);

// ---------------------------------------------------
OTAPI_Func theRequest = new OTAPI_Func(OTAPI_Func.FT.WITHDRAW_VOUCHER, serverID, nymID, accountID, recepientNymID, chequeMemo, amount);
String strResponse = OTAPI_Func.SendTransaction(theRequest, "WITHDRAW_VOUCHER"); // <========================

if (null == strResponse) {
System.out.println("OTAPI_Func.SendTransaction() failed, in withdrawVoucher.");
return null;
}
// ---------------------------------------------------------
String ledger = otapi.OT_API_Message_GetLedger(strResponse);
if (ledger == null) {
System.out.println(" ledger is null, returned by OT_API_Message_GetLedger, serverResponseMessage passed as argument");
return null;
}
String transaction = otapi.OT_API_Ledger_GetTransactionByIndex(serverID, nymID, accountID, ledger, 0);
if (transaction == null) {
System.out.println("withdrawVoucher: transaction is null, returned by OT_API_Ledger_GetTransactionByIndex, argument passed, index 0 and ledger :" + ledger);
return null;
}
// ---------------------------------------------------------
String output = otapi.OT_API_Transaction_GetVoucher(serverID, nymID, accountID, transaction);
System.out.println("output returned by OT_API_Transaction_GetVoucher:" + output);

return output;
}
</pre>

---------------

'''BASKET CURRENCIES'''

'''Create a new Basket Currency'''

First, invent the basket in your head. Give it name: _"Clams."_

Next, give it a ratio in terms of other existing currencies: _"10 Clams equals a basket of 5 dollars, 3 Euro, and 20 Bitcoin"_

Call '''OT_API_GenerateBasketCreation()''' to begin creating the basket. The _"10 Clams"_ from above is set here.

Next, call '''OT_API_AddBasketCreationItem()''' for EACH currency in the basket. In the above example, I would call this function 3 times, in order to set the _"5 dollars"_ the _"3 Euro"_ and the _"20 Bitcoin"_ from above.

Now that the basket has been defined, call '''OT_API_issueBasket()''' to actually create the basket currency on the server.

(Now you have created a new asset type--a basket--which the server will control. Any user may now create accounts using this type! And from there, they can write cheques, withdraw cash, trade on markets, etc. the same as with any other asset type.)

'''Exchange Digital Assets in/out of a Basket Currency (from your Asset Accounts)'''

First, call '''OT_API_GenerateBasketExchange()''' to setup the exchange. You'll need to know the basket's asset type, and you'll need to have an existing asset account of that type. You will also set the "transfer multiple" in that call.

What's the transfer multiple? Remember the ratio above: "10 Clams equals a basket of 5 dollars, 3 Euro, and 20 Bitcoin"

Here are examples of the transfer multiple:

"10 Clams == 5 USD, 3 EUR, 20 BIT" (Transfer multiple: 1)

"20 Clams == 10 USD, 6 EUR, 40 BIT" (Transfer multiple: 2)

"30 Clams == 15 USD, 9 EUR, 60 BIT" (Transfer multiple: 3)

"40 Clams == 20 USD, 12 EUR, 80 BIT" (Transfer multiple: 4)

"50 Clams == 25 USD, 15 EUR, 100 BIT" (Transfer multiple: 5)

Next, call '''OT_API_AddBasketExchangeItem()''' for each currency type in the basket. You will need to to pass the asset account ID for an existing asset account, for each currency type (since you are converting in or out, from your basket account, to your asset accounts.)

Therefore you will call this function once for USD, once for EUR, and once for BIT, in that example, passing in your USD asset acct ID, your EUR asset acct ID, and your Bitcoin asset account ID.

Now that it's all set up, call '''OT_API_exchangeBasket()''' to actually message the server and perform the exchange.

'''Interesting''': ''basket currencies themselves require no more additional system resources than normal currencies!'' The magic happens during the exchange process. The server simply stores internal asset accounts for the dollars, euros, and bitcoins (say), and it manages the issuer account for the basket, and it also manages the exchanging in and out, by moving digital assets in or out of the internal backing accounts. After that point, a basket is just another Asset Type ID, and requires no additional resources. You can even have baskets made up of other baskets, nested 10 times, and it won't affect the speed of operation of the server!

------------------------

'''PROCESSING YOUR INBOX'''

'''Process the Receipts and Pending Transfers in your Inbox'''

If you wish, call '''OT_API_getInbox()''' to grab the latest inbox from the server.

In the high-level API, this is often just automated for you, but nevertheless, check out the dl_acct_files.ot script. See also show_inbox.ot, etc.

During this time, your user has the opportunity to peruse the inbox, and to decide which transactions therein he wishes to accept or reject. Usually the inbox is display on the screen, then the user selects various items to accept or reject, and then the user clicks "Process Inbox" and then you do this:

Then call '''OT_API_Ledger_CreateResponse()''' in order to create a 'response' ledger for that inbox, which will be sent to the server to signal your responses to the various inbox transactions.

Then call '''OT_API_Ledger_GetCount()''' (pass it the inbox) to find out how many transactions are inside of it. Use that count to LOOP through them...

Use '''OT_API_Ledger_GetTransactionByIndex()''' to grab each transaction as you iterate through the inbox. (There are various introspection functions you can use in the API here if you wish to display the inbox items on the screen for the user...)

Next call '''OT_API_Transaction_CreateResponse()''' for each transaction in the inbox, to create a response to it, accepting or rejecting it. This function creates the response and adds it to the response ledger.

Next, call '''OT_API_Ledger_FinalizeResponse()''' which will create a _Balance Agreement_ for the ledger.

Finally, call '''OT_API_processInbox()''' to send your message to the server and process the various items.

(See the accept_inbox.ot script.)

If the message was successful, then use '''OT_API_Message_GetBalanceAgreementSuccess()''' and '''OT_API_Message_GetTransactionSuccess()''' to see just _how_ successful.

---------------------------------

'''MARKETS and PAYMENT PLANS'''

'''Setup a Payment Plan'''

The Merchant draws up the Payment Plan using '''OT_API_ProposePaymentPlan'''

Then he sends it to the Customer, who calls '''OT_API_ConfirmPaymentPlan'''

The Customer's wallet activates the payment plan by sending it to the server using this function: '''OT_API_depositPaymentPlan()'''

(Receipts will process into the respective parties' inboxes.)

Use OT_API_cancelCronItem() to cancel any payment plan (or market offer.)

If the message was successful, then use '''OT_API_Message_GetBalanceAgreementSuccess()''' and '''OT_API_Message_GetTransactionSuccess()''' as described above in the _deposit cash_ instructions.

'''Issue a [[Markets|Market]] Offer'''

Call this function: '''OT_API_issueMarketOffer()'''

(That's the low-level one. See create_offer.ot script for the high-level version.)

Call '''OT_API_Message_GetSuccess''' to find out if the message was a SUCCESS or FAILURE.

If the message was successful, then use '''OT_API_Message_GetBalanceAgreementSuccess()''' and '''OT_API_Message_GetTransactionSuccess()''' as described above in the _deposit cash_ instructions.
See the OTScript and Java versions of these calls.

Once an offer goes onto the market, multiple trades may occur between it and the other offers on the market.

(According to the rules in the offers.) Receipts will process into the respective parties' inboxes after each trade.

'''Cancel a Market Offer'''

Use '''OT_API_cancelNymMarketOffer''' to remove an offer from a market.

If the message was successful, then use '''OT_API_Message_GetBalanceAgreementSuccess()''' and '''OT_API_Message_GetTransactionSuccess()'''

'''Retrieving Market Data from OT Server:'''

'''OT_API_getMarketList''' retrieves a list of all the markets available on a specific server, and details for each market. If the server call is a success, the data will be retrieved from the OT server, and written to local storage using the OT Storage API, at this path or key (inside your data_folder location): '''markets/SERVER_ID/market_data.bin'''

If you want to verify whether the data is now available in local storage (after a successful call to getMarketList), your code would look like this:

'''if (otapi.Exists("markets", serverID, "market_data.bin")) bFoundFile = true;'''

Here is some Java code that reads the market list object from local storage, assuming bFoundFile is true:

<pre>
MarketList marketList = null;
Storable storable = null;

if (otapi.Exists("markets", serverID, "market_data.bin"))
{
storable =
otapi.QueryObject(StoredObjectType.STORED_OBJ_MARKET_LIST,
"markets", serverID, "market_data.bin");
if (storable==null)
return null;
marketList = MarketList.ot_dynamic_cast(storable);
}
</pre>

Once you have the market list, here is some sample Java code to read the details of an individual market from that list:

<pre>
public static Object getMarketDetails(String marketID)
{
MarketList marketList = Utility.getMarketList();

if (marketList == null)
{
return null;
}

for (int i=0; i < marketList.GetMarketDataCount(); i++)
{
MarketData marketData = marketList.GetMarketData(i);

if (marketData == null)
continue;

String [] row = new String[2];

if (marketID.equals(marketData.getMarket_id()))
{
String[] data = new String[2];
marketData.getLast_sale_price();
marketData.getCurrent_ask();

// Etc!! This is where you get the market details.
}
}

// return custom object here (row/data or whatever), or null if failure..
return null;
}
</pre>

'''OT_API_getMarketOffers''' retrieves publicly-available info for all offers on a specific market, up until maximum depth, and saves the data here: '''markets/SERVER_ID/offers/MARKET_ID.bin'''

(See testwallet/OTAPI.i for ALL DATA OBJECTS that are used in local storage, including market offers, recent trades, etc. See the code above for a sample on how those data objects are used.)

'''OT_API_getMarketRecentTrades''': Retrieves all recent trades on a market (up until maximum depth), and stores them here: '''markets/SERVER_ID/recent/MARKET_ID.bin'''

To retrieve the offers that a specific Nym has out on the market, use: '''OT_API_getNym_MarketOffers'''

This _getNym_MarketOffers_ data is _private_ and thus a lot more detailed than what's retrieved via '''OT_API_Market_GetOffers''', which is more meant for public use.

After a successful retrieval, you can load the data from this location: '''nyms/SERVER_ID/offers/NYM_ID.bin'''

If you want to see the Nym's private list of his ''completed trades'', the path to load it from is here:

'''nyms/trades/SERVER_ID/NYM_ID'''

There is no need to send a server message in this last case--just read the data from local storage directly. (When market trading receipts are accepted and cleared out of your inbox, this is where they will go. So there's no need to download them, since they were already downloaded through your inbox previously.)

As before, the appropriate data object can be found in testwallet/OTAPI.i along with all the others.

----------------------

I will be very responsive to developer needs and questions regarding the OT API, so I encourage you to play with the software and contact me anytime.

See also:

[[Opentxs | opentxs command-line tool]]

[[List of Classes | The OT C++ class library]]

[[OTX | The OTX protocol]]

API

2015-07-08T22:50:54Z

FellowTraveler: /* API Docs */ updated links

NOTE: This page is old, but preserved in case of any usefulness. [http://github.com/Open-Transactions/Moneychanger Moneychanger] is the reference implementation and it shows how to use the OT client API. If you ever need to write code that uses OT, just copy the sample code you need out of Moneychanger itself. It's that easy!

=== API Docs ===
* [https://github.com/Open-Transactions/opentxs/blob/develop/include/opentxs/client/OT_ME.hpp#L116 High-level API (C++)]

* [https://github.com/Open-Transactions/opentxs/blob/develop/include/opentxs/client/OTAPI.hpp#L71 Low-level API (C++)]

The above two APIs are wrapped with SWIG, and thus available in many other languages.

The general rule of thumb is: When coding, always prefer the high-level API. Only use the low-level API for functions where no high-level API version is available.

=== Introduction ===
* See the [https://github.com/FellowTraveler/Open-Transactions/blob/master/include/otapi/OTMadeEasy.h#L159 OTMadeEasy] class, as well as the sample scripts provided in [https://github.com/FellowTraveler/Open-Transactions/blob/master/scripts/demo/php/php_ot_test.php PHP] [https://github.com/FellowTraveler/Open-Transactions/blob/master/scripts/demo/python/python_ot_test.py Python] and [https://github.com/FellowTraveler/Open-Transactions/blob/master/scripts/demo/csharp/Main.cs C-Sharp].

* OT's high-level API is also available in OT [https://github.com/FellowTraveler/Open-Transactions/wiki/Client-side-scripting client-side scripts]

* The '''opentxs list''' and [https://github.com/FellowTraveler/Open-Transactions/wiki/opentxs opentxs help] commands display a complete list of all the OT API functions available on the command line. The actual code for those commands, written using the OT high-level API, [https://github.com/FellowTraveler/Open-Transactions/blob/master/scripts/ot/ot_commands.ot#L1288 is available here for your perusal]. This way, you can test the complete OT functionality at the command line, and then flip through the actual code for each command, and see how the OT API calls are used. '''You might be surprised how simple they really are.'''

* With that as your guide, a general rule of thumb is this: Anytime you need to do something, use the [https://github.com/FellowTraveler/Open-Transactions/blob/master/include/otapi/OTMadeEasy.h#L159 high-level API] to do it. Only if you can't find the function you are looking for, should you next resort to the [https://github.com/FellowTraveler/Open-Transactions/blob/master/include/otapi/OTAPI_Basic.h#L170 low-level API]. And remember, you can always the copy the code you need from the [https://github.com/FellowTraveler/Open-Transactions/blob/master/scripts/ot/ot_commands.ot#L1288 opentxs] tool, or from the test GUI, [http://github.com/FellowTraveler/otapij otapiJ].

What does this mean for you? It means you no longer have to worry about synchronizing request numbers, or harvesting transaction numbers, or comparing inbox hashes, or downloading your nymbox, or dropped messages, or timeouts, or retries, etc! Instead, you use simple functions like '''send_transfer''' or '''withdraw_cash'''. The high-level API manages everything else behind the scenes.

The OT high-level API (OTMadeEasy) is now available in these languages: [http://www.chaiscript.com/ ChaiScript] ( [https://github.com/FellowTraveler/Open-Transactions/blob/master/include/otapi/OTMadeEasy.h#L159 ot script] ) and Java, CSharp, PHP, Python, D, Perl, and TCL. The [https://github.com/FellowTraveler/Open-Transactions/blob/master/include/otapi/OTAPI_Basic.h#L170 low-level API] is available in D, Python, PHP, Perl, Java, etc. (Via [http://www.swig.org/ SWIG] wrappers.)

=== USE CASES for the OT API ===

* '''(Client software starts up.)''' Initialize the library and load the wallet.
* Display for user: '''Server Contracts, Nyms, Accounts, and Asset Types.'''
* Change the wallet's ''display label'' for any server, asset type, account, or nym.
* Import a server contract (or asset contract) to the wallet.
* Create a new '''Pseudonym''' (public/private key pair).
* Register a public key (a ''"Nym"'') at an OT server.
* '''Issue a new digital Asset Type'''. (Uploading an asset contract.)
* Retrieve Currency Contract (by ID).
* '''Create a new Asset Account'''.
* '''Write a cheque''' (or invoice)
* '''Send a Message''' to another user (via the server, encrypted to the recipient's public key.)
* '''Deposit a cheque'''
* '''Withdraw cash''' . . . . <==== CHAUMIAN DIGITAL CASH!!
* '''Deposit cash'''
* Withdraw Voucher
* '''Account-to-Account Transfer'''
* Create a new '''Basket Currency'''
* '''Exchange''' Digital Assets '''in and out of Baskets''' (from your Asset Accounts)
* '''Process your Inbox''' (Receipts and pending transfers)
* Set up a '''Payment Plan'''
* Issue a '''Market Offer'''

-------

'''Initialize the library and Load your Wallet'''

(The user starts up the wallet software.)

Call '''OT_API_Init()'''

Then call '''OT_API_LoadWallet()'''

(NOTE: these above 2 steps are not necessary in OT-script, only Java and other languages.)

'''Display the current list of server contracts on the screen'''

Call '''OT_API_GetServerCount()''', which returns the number of server contracts in your wallet.

For each one, call '''OT_API_GetServer_ID()''' to get the Server ID (which is a hash of the contract.)

Also for each, call '''OT_API_GetServer_Name()''' to get the Display Name from the contract.

In your GUI, display the name on the screen, but use the ID behind the scenes (for your messages to the server.)

'''Do the same thing for Nyms, Accounts, and Asset Types.'''

You can read about them on the [[API]] page, but here are the basic functions:

OT_API_GetNymCount(void);

OT_API_GetServerCount(void);

OT_API_GetAssetTypeCount(void);

OT_API_GetAccountCount(void);

OT_API_GetNym_ID() and OT_API_GetNym_Name()

OT_API_GetServer_ID() and OT_API_GetServer_Name()

OT_API_GetAssetType_ID() and OT_API_GetAssetType_Name()

OT_API_GetAccountWallet_ID() and OT_API_GetAccountWallet_Name()

Also:

OT_API_GetAccountWallet_Balance()

OT_API_GetAccountWallet_Type()

OT_API_GetAccountWallet_AssetTypeID()

'''Add a new server contract (or asset contract) to the wallet'''

Call '''OT_API_AddServerContract()'''

or '''OT_API_AddAssetContract()'''.

'''Create a new Pseudonym'''

(Each user's wallet may contain many pseudonyms. Each Nym consists of a public and a private key, aka a "key pair".)

Call '''OT_API_CreateNym()'''

This creates a new key pair _("Nym")_ in your wallet, which you can use for communications with an OT server.

(That is, for opening asset accounts and performing various other transactions. A Nym is a "user account".)

(You can create as many of these pseudonyms as you want.)

(You can register the same nyms at multiple servers.)

(The same Nym will have the same Nym ID and public key on every server.)

Example

<pre>
def details_create_nym(nKeybits, strName)
{
var madeEasy = OT_ME()
var strNymID = madeEasy.create_pseudonym(nKeybits, "", "") // returns new Nym ID

if (!VerifyStringVal(strNymID))
{
OT_API_Output(0, "details_create_nym: Failed in OT_ME::create_pseudonym(keybits == " + nKeybits.to_string() + ")\n")
return (0)
}
OT_API_Output(0, "Success creating! " + nKeybits.to_string() + " keybits, new ID: ") // stderr
print(strNymID) // stdout
OT_API_Output(0, "\n") //stderr
// -------------------
var bSetName = OT_API_SetNym_Name(strNymID, // subject
strNymID, // signer
strName)
if (!bSetName)
{
OT_API_Output(0, "Failed in OT_API_SetNym_Name(name == " + strName + ")\n")
return (0)
}
// -------------------
OT_API_Output(0, "Success setting name to: " + strName + "\n\n") // stderr
return 1
}
</pre>

'''Register a public key (aka "Nym") at an OT server'''

<pre>
var madeEasy = OT_ME()
if (VerifyExists("Server") && VerifyExists("MyNym"))
{
var strResponse = madeEasy.register_nym(Server, MyNym)
var nSuccess = VerifyMessageSuccess(strResponse)
switch(nSuccess)
{
case (1)
{
OT_API_Output(0, "\n\n SUCCESS in register_nym! Server response:\n\n");
print(strResponse) // stdout
break
}
default
{
OT_API_Output(0, "\n\n Failure or Error in register_nym!\n")

if (VerifyStringVal(strResponse))
{
OT_API_Output(0, "Server response:\n\n");
print(strResponse) // stdout
}
break
}
}
</pre>

'''Change the wallet's label for any server/asset type/account/nym'''

(This is only a client-side label, for display purposes only.)

'''OT_API_SetNym_Name()'''

'''OT_API_SetAccountWallet_Name()'''

'''OT_API_SetAssetType_Name()'''

'''OT_API_SetServer_Name()'''

----------------------------

'''Issue a new digital Asset Type'''

User uploads a new currency contract to the server, so users can create asset accounts based on that asset type.

Server replies with a new issuer account ID (The new Issuer account appears inside your wallet's account list, so go ahead and iterate the list again, in order to display the updated list of accounts on the screen.)

High-level API version (in OT script):

<pre>
var madeEasy = OT_ME()
OT_API_Output(0, "Please paste a currency contract, followed by an EOF or a ~ by itself on a blank line:\n\n")
var strContract = OT_CLI_ReadUntilEOF()
var strResponse = madeEasy.issue_asset_type(Server, MyNym, strContract)
var nStatus = VerifyMessageSuccess(strResponse)

switch(nStatus)
{
case (1)
{
OT_API_Output(0, "\n\n SUCCESS in issue_asset! Server response:\n\n");
print(strResponse) // stdout
break
}
default
{
OT_API_Output(0, "\n\n Failure or error in issue_asset. nStatus: "+nStatus.to_string()+"\n")
if (VerifyStringVal(strResponse))
{
OT_API_Output(0, "Server response:\n\n");
print(strResponse) // stdout
}
break
}
}
</pre>

'''Retrieve Currency Contract (by ID)'''

User wants to download a currency contract from the server (for a given asset type ID.)

(The asset type ID is a hash of the contract, so OT will know if you get the wrong one, since this is verified whenever a contract is loaded up.)

High-level API version (in OT script):

<pre>
var madeEasy = OT_ME()
var strRetrieved = madeEasy.retrieve_contract(Server, MyNym, strContractID)
var nRetrieved = VerifyMessageSuccess(strRetrieved)
var strSuccess = "ERROR"
if (1 == nRetrieved)
{ strSuccess = "SUCCESS" }
else if (0 == nRetrieved)
{ strSuccess = "FAILED" }
OT_API_Output(0, "\n\n " + strSuccess + " retrieving contract: "+strContractID+"\n\n")
</pre>

'''Create a new Asset Account'''

Example in OT Script, from the "sample scripts":https://github.com/FellowTraveler/Open-Transactions/tree/master/scripts/samples folder:

<pre>
def OT_ME::create_asset_acct(SERVER_ID, NYM_ID, ASSET_TYPE_ID)
{
var ot_Msg := OTAPI_Func()
// -------------------------
var theRequest := OTAPI_Func(ot_Msg.CREATE_ASSET_ACCT, SERVER_ID, NYM_ID, ASSET_TYPE_ID)
var strResponse = theRequest.SendRequest(theRequest, "CREATE_ASSET_ACCT")

return strResponse
}
</pre>

If it was a SUCCESS, then refresh the list of accounts in your display (from the OT API) since your new asset account should now be there.

(You can also use the "decode" command in the test wallet anytime you want to base64-decode something.)

--------------------------

'''TRANSACTIONS'''

FYI: Balance agreement, combined with transaction numbers, is what makes it possible for the server and all other parties to _eliminate account history, instead storing only the last signed receipt._ (Of course they have the ''choice'' to keep their own records--but they are no longer ''forced'' to do so.)

In order to do any transaction, the wallet's _balance agreement_ process requires that you have the latest copy of your account, inbox, and outbox files. You don't have to worry about this too much, since the high-level API will usually handle it for you.

'''You might ask: ''"But what if I download my account, or my outbox, and the server has maliciously inserted data into them?"'' '''
''No problem'' -- Open Transactions stores the last signed receipt from the server, and is able to verify the new intermediary files against that last receipt. You can see this happening when you run the command-line test client, and receipts can be verified programmatically using '''OT_API_VerifyAccountReceipt()'''.

The [[Triple-Signed Receipts]] on Open Transactions ensure that this sort of protection is available to all parties, '''while simultaneously not having to store any transaction history!'''

------------------

'''Write a Cheque'''

Alice writes a cheque (offline): Call '''OT_API_WriteCheque()'''

Alice then gives cheque to Bob (offline), _or_ online if she prefers via '''OT_API_sendUserMessage()''' function.

If Alice has Bob's UserID but not his public key, her wallet first uses '''OT_API_checkUser()''' to retrieve his public key from the server, and then encrypts the cheque before sending it.

NOTE: a quality wallet software will keep track of ALL instruments! Even when Alice gives a cheque to Bob, her wallet should still store a copy of that cheque. Until when? Until at least after he has cashed it... when he does that, a chequeReceipt will appear in her inbox. Only when she accepts that receipt, signing a new balance agreement, is she finally free of the transaction number that was on that cheque. (It was still signed-out to her, all the way up until that time.)

WHAT IF Bob had never cashed it? WHAT IF he lost it? Is Alice supposed to just keep signing for that number forever? (The chequeReceipt will never appear in her inbox. She is doomed to continue signing for this number on all of her receipts on into the future, ad infinitum, with no hope of ever closing it out!)

Fear not, there is a solution: '''OT_API_DiscardCheque()'''. (Lucky you saved a copy of that cheque in your wallet, eh?) This function will retrieve Alice's transaction # back from the cheque, so that her wallet is free to use it on her next valid transaction, and then close it out normally.

'''Deposit a cheque'''

(A voucher is also a cheque, so you may deposit a voucher here the same as any other cheque.)

Bob sends message to server requesting deposit:

'''(High level API version, in Java.)'''

<pre>
public boolean depositCheque(String serverID, String nymID, String accountID, String cheque) {

System.out.println("In depositCheque serverID:" + serverID + " nymID:" + nymID + " acount ID:" + accountID);

// ---------------------------------------------------
OTAPI_Func theRequest = new OTAPI_Func(OTAPI_Func.FT.DEPOSIT_CHEQUE, serverID, nymID, accountID, cheque);
String strResponse = OTAPI_Func.SendTransaction(theRequest, "DEPOSIT_CHEQUE"); // <========================

if (null == strResponse) {
System.out.println("OTAPI_Func.SendTransaction() failed, in depositCheque.");
return false;
}
// --------------------------------------------------------------------------------------

return true;
}
</pre>

'''Withdraw cash'''

Alice's wallet first makes sure she has the latest public mint file, by calling '''OT_API_getMint()'''.

(Note: if the mint she already has is within its valid date range, there's no need to do this.)

(Note: If she does call getMint, Alice needs to check the server reply and make sure it was successful before continuing with the withdrawal. The public mint keys are necessary for cash withdrawal.)

Alice then withdraws from her asset account, by messaging server: '''OT_API_notarizeWithdrawal()'''

Server replies with chaumian cash, which is stored in the purse folder in local storage.

Here is the full Java implementation of Withdraw Cash:

<pre>
public boolean withdrawCash(String serverID, String nymID, String accountID, String amount)
{
String serverResponseMessage = null;
System.out.println("In withdrawCash serverID:" + serverID + " nymID:" + nymID + " acount ID:" + accountID);
String assetID = otapi.OT_API_GetAccountWallet_AssetTypeID(accountID);

// ----------------------------------------
// Make sure we have the proper asset contract for the withdrawal.
//
String assetContract = otapi.OT_API_LoadAssetContract(assetID);
if (assetContract == null) {
OTAPI_Func theRequest = new OTAPI_Func(OTAPI_Func.FT.GET_CONTRACT, serverID, nymID, assetID);
String strResponse = OTAPI_Func.SendRequest(theRequest, "GET_CONTRACT");

if (null == strResponse) {
System.out.println("IN withdrawCash: OTAPI_Func.SendRequest(GET_CONTRACT) failed. (I give up.) (Unable to find asset contract.)");
return false;
}
// ----------------------------------------
assetContract = otapi.OT_API_LoadAssetContract(assetID);
if (assetContract == null) {
System.out.println("OT_API_LoadAssetContract returned null even after OT_API_getContract (Unable to find asset contract.)");
return false;
}
}
// ---------------------------------------------------------
// Download the public mintfile if it's not there, or if it's expired.
// Also load it up into memory as a string (just to make sure it works.)
// Then we can actually send the withdrawal transaction request. (Until
// then, why bother?)
//
String mintFile;

// expired or missing.
if (1 != otapi.OT_API_Mint_IsStillGood(serverID, assetID))
{
// ----------------------------------------
OTAPI_Func theRequest = new OTAPI_Func(OTAPI_Func.FT.GET_MINT, serverID, nymID, assetID);
String strResponse = OTAPI_Func.SendRequest(theRequest, "GET_MINT");

if (null == strResponse) {
System.out.println("IN withdrawCash: OTAPI_Func.SendRequest(GET_MINT) failed. (I give up.) (Unable to get mint.)");
return false;
}
// ----------------------------------------
mintFile = otapi.OT_API_LoadMint(serverID, assetID);
if (mintFile == null) {
System.out.println("OT_API_LoadMint returned null even after OT_API_getMint (I give up.) (Unable to find mint.)");
return false;
}
}
else // current mint IS available already on local storage (and not expired.)
{
mintFile = otapi.OT_API_LoadMint(serverID, assetID);
if (mintFile == null) {
System.out.println("OT_API_LoadMint returned null even after successful OT_API_Mint_IsStillGood (I give up.) (Unable to find mint.)");
return false;
}
}
// ---------------------------------------------------
// By this point, the mintfile is DEFINITELY good (available, not null,
// not expired, and loaded up.) Now we know for a fact that when the API
// call is made to withdraw cash, that it will find the mint properly.
//
OTAPI_Func theRequest = new OTAPI_Func(OTAPI_Func.FT.WITHDRAW_CASH, serverID, nymID, accountID, amount);
String strResponse = OTAPI_Func.SendTransaction(theRequest, "WITHDRAW_CASH"); // <========================

if (null == strResponse) {
System.out.println("OTAPI_Func.SendTransaction() failed, in withdrawCash.");
return false;
}
// --------------------------------------------------------------------------------------

return true;
}
</pre>

'''Deposit cash'''

Here is the complete Java implementation for Deposit Cash:

<pre>
public boolean depositCash(String serverID, String nymID, String accountID, String purse, boolean isToken) {

System.out.println("In depositCash serverID:" + serverID + " nymID:" + nymID + " acount ID:" + accountID + " isToken:" + isToken);
Utility.setOtDepositCash(null);
String oldPurse = purse;
if (isToken) {
purse = getNewPurse(purse, serverID, nymID, accountID);
System.out.println("purse after getting from push purse:" + purse);
if (purse == null) {
Utility.setOtDepositCash(oldPurse);
return false;
}
}
// ----------------------------------------
OTAPI_Func theRequest = new OTAPI_Func(OTAPI_Func.FT.DEPOSIT_CASH, serverID, nymID, accountID, purse);
String strResponse = OTAPI_Func.SendTransaction(theRequest, "DEPOSIT_CASH"); // <========================

if (null == strResponse) {
System.out.println("IN depositCash: OTAPI_Func.SendTransaction(() failed. (I give up.) ");

if (isToken) {
System.out.println("IN depositCash, failed action for single token");
String assetID = otapi.OT_API_GetAccountWallet_AssetTypeID(accountID);
boolean importStatus = otapi.OT_API_Wallet_ImportPurse(serverID, assetID, nymID, purse) == 1 ? true : false;
System.out.println("Since failure of depositCashPurse, OT_API_Wallet_ImportPurse called, status of import:" + importStatus);
if (!importStatus) {
Utility.setOtDepositCash(purse);
}
}

return false;
}
// ----------------------------------------
return true;
}
</pre>

--------------------------------------

Note about local storage: Usually whenever something important is downloaded from the server, the OT API will save it automatically to the default storage context, and you can then load it up using another API call. This is usually the most convenient way to do things.

--------------------------------------

'''Account-to-Account Transfer'''

A _pending transfer_ will go into your outbox, and the recipient's inbox, pending acceptance by the recipient.

FYI, every asset account has its own inbox and outbox for handling pending transactions, as well as receipts.

FYI, every Nym similarly has its own Nymbox, used for receiving messages from other users, and for receiving new transaction numbers from the server.

Here is the OT Script implementation of Send Transfer, from the "sample scripts":https://github.com/FellowTraveler/Open-Transactions/tree/master/scripts/samples folder:

<pre>
def OT_ME::send_transfer(SERVER_ID, NYM_ID, ACCT_FROM, ACCT_TO, AMOUNT, NOTE)
{
var ot_Msg := OTAPI_Func()
// -------------------------
var theRequest := OTAPI_Func(ot_Msg.SEND_TRANSFER, SERVER_ID, NYM_ID, ACCT_FROM, ACCT_TO, AMOUNT, NOTE)
var strResponse = theRequest.SendTransaction(theRequest, "SEND_TRANSFER")

return strResponse
}
</pre>

'''Withdraw Voucher'''

A voucher is like a "money order" or "cashier's cheque". It's a cheque, but drawn on a server account, instead of your own account.

Withdrawing in voucher form is similar to withdrawing in cash: the server debits your asset account, and then gives you an official cheque.

But with cash, it's automatically saved to your purse, whereas with a voucher, you have to read the voucher out of the server reply, and display it on the screen!

Here is the complete Java code to perform Withdraw Voucher:

<pre>
public String withdrawVoucher(String serverID, String nymID, String accountID, String amount, String chequeMemo, String recepientNymID) {

System.out.println("In withdrawVoucher serverID:" + serverID + " nymID:" + nymID + " acount ID:" + accountID);

// ---------------------------------------------------
OTAPI_Func theRequest = new OTAPI_Func(OTAPI_Func.FT.WITHDRAW_VOUCHER, serverID, nymID, accountID, recepientNymID, chequeMemo, amount);
String strResponse = OTAPI_Func.SendTransaction(theRequest, "WITHDRAW_VOUCHER"); // <========================

if (null == strResponse) {
System.out.println("OTAPI_Func.SendTransaction() failed, in withdrawVoucher.");
return null;
}
// ---------------------------------------------------------
String ledger = otapi.OT_API_Message_GetLedger(strResponse);
if (ledger == null) {
System.out.println(" ledger is null, returned by OT_API_Message_GetLedger, serverResponseMessage passed as argument");
return null;
}
String transaction = otapi.OT_API_Ledger_GetTransactionByIndex(serverID, nymID, accountID, ledger, 0);
if (transaction == null) {
System.out.println("withdrawVoucher: transaction is null, returned by OT_API_Ledger_GetTransactionByIndex, argument passed, index 0 and ledger :" + ledger);
return null;
}
// ---------------------------------------------------------
String output = otapi.OT_API_Transaction_GetVoucher(serverID, nymID, accountID, transaction);
System.out.println("output returned by OT_API_Transaction_GetVoucher:" + output);

return output;
}
</pre>

---------------

'''BASKET CURRENCIES'''

'''Create a new Basket Currency'''

First, invent the basket in your head. Give it name: _"Clams."_

Next, give it a ratio in terms of other existing currencies: _"10 Clams equals a basket of 5 dollars, 3 Euro, and 20 Bitcoin"_

Call '''OT_API_GenerateBasketCreation()''' to begin creating the basket. The _"10 Clams"_ from above is set here.

Next, call '''OT_API_AddBasketCreationItem()''' for EACH currency in the basket. In the above example, I would call this function 3 times, in order to set the _"5 dollars"_ the _"3 Euro"_ and the _"20 Bitcoin"_ from above.

Now that the basket has been defined, call '''OT_API_issueBasket()''' to actually create the basket currency on the server.

(Now you have created a new asset type--a basket--which the server will control. Any user may now create accounts using this type! And from there, they can write cheques, withdraw cash, trade on markets, etc. the same as with any other asset type.)

'''Exchange Digital Assets in/out of a Basket Currency (from your Asset Accounts)'''

First, call '''OT_API_GenerateBasketExchange()''' to setup the exchange. You'll need to know the basket's asset type, and you'll need to have an existing asset account of that type. You will also set the "transfer multiple" in that call.

What's the transfer multiple? Remember the ratio above: "10 Clams equals a basket of 5 dollars, 3 Euro, and 20 Bitcoin"

Here are examples of the transfer multiple:

"10 Clams == 5 USD, 3 EUR, 20 BIT" (Transfer multiple: 1)

"20 Clams == 10 USD, 6 EUR, 40 BIT" (Transfer multiple: 2)

"30 Clams == 15 USD, 9 EUR, 60 BIT" (Transfer multiple: 3)

"40 Clams == 20 USD, 12 EUR, 80 BIT" (Transfer multiple: 4)

"50 Clams == 25 USD, 15 EUR, 100 BIT" (Transfer multiple: 5)

Next, call '''OT_API_AddBasketExchangeItem()''' for each currency type in the basket. You will need to to pass the asset account ID for an existing asset account, for each currency type (since you are converting in or out, from your basket account, to your asset accounts.)

Therefore you will call this function once for USD, once for EUR, and once for BIT, in that example, passing in your USD asset acct ID, your EUR asset acct ID, and your Bitcoin asset account ID.

Now that it's all set up, call '''OT_API_exchangeBasket()''' to actually message the server and perform the exchange.

'''Interesting''': ''basket currencies themselves require no more additional system resources than normal currencies!'' The magic happens during the exchange process. The server simply stores internal asset accounts for the dollars, euros, and bitcoins (say), and it manages the issuer account for the basket, and it also manages the exchanging in and out, by moving digital assets in or out of the internal backing accounts. After that point, a basket is just another Asset Type ID, and requires no additional resources. You can even have baskets made up of other baskets, nested 10 times, and it won't affect the speed of operation of the server!

------------------------

'''PROCESSING YOUR INBOX'''

'''Process the Receipts and Pending Transfers in your Inbox'''

If you wish, call '''OT_API_getInbox()''' to grab the latest inbox from the server.

In the high-level API, this is often just automated for you, but nevertheless, check out the dl_acct_files.ot script. See also show_inbox.ot, etc.

During this time, your user has the opportunity to peruse the inbox, and to decide which transactions therein he wishes to accept or reject. Usually the inbox is display on the screen, then the user selects various items to accept or reject, and then the user clicks "Process Inbox" and then you do this:

Then call '''OT_API_Ledger_CreateResponse()''' in order to create a 'response' ledger for that inbox, which will be sent to the server to signal your responses to the various inbox transactions.

Then call '''OT_API_Ledger_GetCount()''' (pass it the inbox) to find out how many transactions are inside of it. Use that count to LOOP through them...

Use '''OT_API_Ledger_GetTransactionByIndex()''' to grab each transaction as you iterate through the inbox. (There are various introspection functions you can use in the API here if you wish to display the inbox items on the screen for the user...)

Next call '''OT_API_Transaction_CreateResponse()''' for each transaction in the inbox, to create a response to it, accepting or rejecting it. This function creates the response and adds it to the response ledger.

Next, call '''OT_API_Ledger_FinalizeResponse()''' which will create a _Balance Agreement_ for the ledger.

Finally, call '''OT_API_processInbox()''' to send your message to the server and process the various items.

(See the accept_inbox.ot script.)

If the message was successful, then use '''OT_API_Message_GetBalanceAgreementSuccess()''' and '''OT_API_Message_GetTransactionSuccess()''' to see just _how_ successful.

---------------------------------

'''MARKETS and PAYMENT PLANS'''

'''Setup a Payment Plan'''

The Merchant draws up the Payment Plan using '''OT_API_ProposePaymentPlan'''

Then he sends it to the Customer, who calls '''OT_API_ConfirmPaymentPlan'''

The Customer's wallet activates the payment plan by sending it to the server using this function: '''OT_API_depositPaymentPlan()'''

(Receipts will process into the respective parties' inboxes.)

Use OT_API_cancelCronItem() to cancel any payment plan (or market offer.)

If the message was successful, then use '''OT_API_Message_GetBalanceAgreementSuccess()''' and '''OT_API_Message_GetTransactionSuccess()''' as described above in the _deposit cash_ instructions.

'''Issue a [[Markets|Market]] Offer'''

Call this function: '''OT_API_issueMarketOffer()'''

(That's the low-level one. See create_offer.ot script for the high-level version.)

Call '''OT_API_Message_GetSuccess''' to find out if the message was a SUCCESS or FAILURE.

If the message was successful, then use '''OT_API_Message_GetBalanceAgreementSuccess()''' and '''OT_API_Message_GetTransactionSuccess()''' as described above in the _deposit cash_ instructions.
See the OTScript and Java versions of these calls.

Once an offer goes onto the market, multiple trades may occur between it and the other offers on the market.

(According to the rules in the offers.) Receipts will process into the respective parties' inboxes after each trade.

'''Cancel a Market Offer'''

Use '''OT_API_cancelNymMarketOffer''' to remove an offer from a market.

If the message was successful, then use '''OT_API_Message_GetBalanceAgreementSuccess()''' and '''OT_API_Message_GetTransactionSuccess()'''

'''Retrieving Market Data from OT Server:'''

'''OT_API_getMarketList''' retrieves a list of all the markets available on a specific server, and details for each market. If the server call is a success, the data will be retrieved from the OT server, and written to local storage using the OT Storage API, at this path or key (inside your data_folder location): '''markets/SERVER_ID/market_data.bin'''

If you want to verify whether the data is now available in local storage (after a successful call to getMarketList), your code would look like this:

'''if (otapi.Exists("markets", serverID, "market_data.bin")) bFoundFile = true;'''

Here is some Java code that reads the market list object from local storage, assuming bFoundFile is true:

<pre>
MarketList marketList = null;
Storable storable = null;

if (otapi.Exists("markets", serverID, "market_data.bin"))
{
storable =
otapi.QueryObject(StoredObjectType.STORED_OBJ_MARKET_LIST,
"markets", serverID, "market_data.bin");
if (storable==null)
return null;
marketList = MarketList.ot_dynamic_cast(storable);
}
</pre>

Once you have the market list, here is some sample Java code to read the details of an individual market from that list:

<pre>
public static Object getMarketDetails(String marketID)
{
MarketList marketList = Utility.getMarketList();

if (marketList == null)
{
return null;
}

for (int i=0; i < marketList.GetMarketDataCount(); i++)
{
MarketData marketData = marketList.GetMarketData(i);

if (marketData == null)
continue;

String [] row = new String[2];

if (marketID.equals(marketData.getMarket_id()))
{
String[] data = new String[2];
marketData.getLast_sale_price();
marketData.getCurrent_ask();

// Etc!! This is where you get the market details.
}
}

// return custom object here (row/data or whatever), or null if failure..
return null;
}
</pre>

'''OT_API_getMarketOffers''' retrieves publicly-available info for all offers on a specific market, up until maximum depth, and saves the data here: '''markets/SERVER_ID/offers/MARKET_ID.bin'''

(See testwallet/OTAPI.i for ALL DATA OBJECTS that are used in local storage, including market offers, recent trades, etc. See the code above for a sample on how those data objects are used.)

'''OT_API_getMarketRecentTrades''': Retrieves all recent trades on a market (up until maximum depth), and stores them here: '''markets/SERVER_ID/recent/MARKET_ID.bin'''

To retrieve the offers that a specific Nym has out on the market, use: '''OT_API_getNym_MarketOffers'''

This _getNym_MarketOffers_ data is _private_ and thus a lot more detailed than what's retrieved via '''OT_API_Market_GetOffers''', which is more meant for public use.

After a successful retrieval, you can load the data from this location: '''nyms/SERVER_ID/offers/NYM_ID.bin'''

If you want to see the Nym's private list of his ''completed trades'', the path to load it from is here:

'''nyms/trades/SERVER_ID/NYM_ID'''

There is no need to send a server message in this last case--just read the data from local storage directly. (When market trading receipts are accepted and cleared out of your inbox, this is where they will go. So there's no need to download them, since they were already downloaded through your inbox previously.)

As before, the appropriate data object can be found in testwallet/OTAPI.i along with all the others.

----------------------

I will be very responsive to developer needs and questions regarding the OT API, so I encourage you to play with the software and contact me anytime.

See also:

[[Opentxs | opentxs command-line tool]]

[[List of Classes | The OT C++ class library]]

[[OTX | The OTX protocol]]

Use Cases

2015-07-08T22:47:03Z

FellowTraveler: removed bold

Anytime you need to do something, use the high-level API to do it (OT_ME.) Only if you can't find the function you are looking for, should you next resort to the low-level API (OTAPI.) And remember, you can always the copy the code you need from the test GUI, [http://github.com/Open-Transactions/Moneychanger Moneychanger].

What does this mean for you? It means you no longer have to worry about synchronizing request numbers, or harvesting transaction numbers, or comparing inbox hashes, or downloading your nymbox, or dropped messages, or timeouts, or retries, etc! Instead, you use simple functions like '''send_transfer''' or '''withdraw_cash.''' The high-level API manages everything else behind the scenes. And any sample code you need can be copied right out of Moneychanger's code.

-----

NOTE: The below notes are old, but preserved for usefulness.

-----

'''USE CASES for the OT API, described on this page:'''

* '''(Client software starts up.)''' Initialize the library and load the wallet.
* Display for user: '''Server Contracts, Nyms, Accounts, and Asset Types.'''
* Change the wallet's ''display label'' for any server, asset type, account, or nym.
* Import a server contract (or asset contract) to the wallet.
* Create a new '''Pseudonym''' (public/private key pair).
* Register a public key (a ''"Nym"'') at an OT server.
* '''Issue a new digital Asset Type'''. (Uploading an asset contract.)
* Retrieve Currency Contract (by ID).
* '''Create a new Asset Account'''.
* '''Write a cheque''' (or invoice)
* '''Send a Message''' to another user (via the server, encrypted to the recipient's public key.)
* '''Deposit a cheque'''
* '''Withdraw cash''' . . . . <==== CHAUMIAN DIGITAL CASH!!
* '''Deposit cash'''
* Withdraw Voucher
* '''Account-to-Account Transfer'''
* Create a new '''Basket Currency'''
* '''Exchange''' Digital Assets '''in and out of Baskets''' (from your Asset Accounts)
* '''Process your Inbox''' (Receipts and pending transfers)
* Set up a '''Payment Plan'''
* Issue a '''Market Offer'''

-----

'''USE CASES for the OT API'''

'''Initialize the library and Load your Wallet'''
(The user starts up the wallet software.)
Call <code>OT_API_Init()</code> Then call <code>OT_API_LoadWallet()</code>

(NOTE: these above 2 steps are not necessary in OT-script, only Java and other languages.)

'''Display the current list of server contracts on the screen''' Call <code>OT_API_GetServerCount()</code>, which returns the number of server contracts in your wallet. For each one, call <code>OT_API_GetServer_ID()</code> to get the Server ID (which is a hash of the contract.) Also for each, call <code>OT_API_GetServer_Name()</code> to get the Display Name from the contract. In your GUI, display the name on the screen, but use the ID behind the scenes (for your messages to the server.)

'''Do the same thing for Nyms, Accounts, and Asset Types.''' You can read about them on the [[API]] page, but here are the basic functions:

OT_API_GetNymCount(void);
OT_API_GetServerCount(void);
OT_API_GetAssetTypeCount(void);
OT_API_GetAccountCount(void);

OT_API_GetNym_ID() and OT_API_GetNym_Name()
OT_API_GetServer_ID() and OT_API_GetServer_Name()
OT_API_GetAssetType_ID() and OT_API_GetAssetType_Name()
OT_API_GetAccountWallet_ID() and OT_API_GetAccountWallet_Name()
Also:
OT_API_GetAccountWallet_Balance()
OT_API_GetAccountWallet_Type()
OT_API_GetAccountWallet_AssetTypeID()

'''Add a new server contract (or asset contract) to the wallet''' Call <code>OT_API_AddServerContract()</code>
or <code>OT_API_AddAssetContract()</code>.

'''Create a new Pseudonym''' (Each user's wallet may contain many pseudonyms. Each Nym consists of a public and a private key, aka a "key pair".) Call <code>OT_API_CreateNym()</code> This creates a new key pair ''("Nym")'' in your wallet, which you can use for communications with an OT server. (That is, for opening asset accounts and performing various other transactions. A Nym is a "user account".) (You can create as many of these pseudonyms as you want.) (You can register the same nyms at multiple servers.) (The same Nym will have the same Nym ID and public key on every server.)

Example

<pre>def details_create_nym(nKeybits, strName)
{
var madeEasy = OT_ME()
var strNymID = madeEasy.create_pseudonym(nKeybits, "", "") // returns new Nym ID

if (!VerifyStringVal(strNymID))
{
OT_API_Output(0, "details_create_nym: Failed in OT_ME::create_pseudonym(keybits == " + nKeybits.to_string() + ")\n")
return (0)
}
OT_API_Output(0, "Success creating! " + nKeybits.to_string() + " keybits, new ID: ") // stderr
print(strNymID) // stdout
OT_API_Output(0, "\n") //stderr
// -------------------
var bSetName = OT_API_SetNym_Name(strNymID, // subject
strNymID, // signer
strName)
if (!bSetName)
{
OT_API_Output(0, "Failed in OT_API_SetNym_Name(name == " + strName + ")\n")
return (0)
}
// -------------------
OT_API_Output(0, "Success setting name to: " + strName + "\n\n") // stderr
return 1
}</pre>
'''Register a public key (aka "Nym") at an OT server'''

<pre> var madeEasy = OT_ME()
if (VerifyExists("Server") && VerifyExists("MyNym"))
{
var strResponse = madeEasy.register_nym(Server, MyNym)
var nSuccess = VerifyMessageSuccess(strResponse)
switch(nSuccess)
{
case (1)
{
OT_API_Output(0, "\n\n SUCCESS in register_nym! Server response:\n\n");
print(strResponse) // stdout
break
}
default
{
OT_API_Output(0, "\n\n Failure or Error in register_nym!\n")

if (VerifyStringVal(strResponse))
{
OT_API_Output(0, "Server response:\n\n");
print(strResponse) // stdout
}
break
}
}</pre>
'''Change the wallet's label for any server/asset type/account/nym'''<br>
(This is only a client-side label, for display purposes only.)<br>
<code>OT_API_SetNym_Name()</code><br>
<code>OT_API_SetAccountWallet_Name()</code> <br>
<code>OT_API_SetAssetType_Name()</code> <br>
<code>OT_API_SetServer_Name()</code><br>

-----

'''Issue a new digital Asset Type''' User uploads a new currency contract to the server, so users can create asset accounts based on that asset type. Server replies with a new issuer account ID (The new Issuer account appears inside your wallet's account list, so go ahead and iterate the list again, in order to display the updated list of accounts on the screen.)

High-level API version (in OT script):

<pre>
var madeEasy = OT_ME()
OT_API_Output(0, "Please paste a currency contract, followed by an EOF or a ~ by itself on a blank line:\n\n")
var strContract = OT_CLI_ReadUntilEOF()
var strResponse = madeEasy.issue_asset_type(Server, MyNym, strContract)
var nStatus = VerifyMessageSuccess(strResponse)

switch(nStatus)
{
case (1)
{
OT_API_Output(0, "\n\n SUCCESS in issue_asset! Server response:\n\n");
print(strResponse) // stdout
break
}
default
{
OT_API_Output(0, "\n\n Failure or error in issue_asset. nStatus: "+nStatus.to_string()+"\n")
if (VerifyStringVal(strResponse))
{
OT_API_Output(0, "Server response:\n\n");
print(strResponse) // stdout
}
break
}
}</pre>
'''Retrieve Currency Contract (by ID)''' User wants to download a currency contract from the server (for a given asset type ID.) (The asset type ID is a hash of the contract, so OT will know if you get the wrong one, since this is verified whenever a contract is loaded up.)

High-level API version (in OT script):

<pre> var madeEasy = OT_ME()
var strRetrieved = madeEasy.retrieve_contract(Server, MyNym, strContractID)
var nRetrieved = VerifyMessageSuccess(strRetrieved)
var strSuccess = "ERROR"
if (1 == nRetrieved)
{ strSuccess = "SUCCESS" }
else if (0 == nRetrieved)
{ strSuccess = "FAILED" }
OT_API_Output(0, "\n\n " + strSuccess + " retrieving contract: "+strContractID+"\n\n")</pre>

'''Create a new Asset Account''' Example in OT Script, from the [https://github.com/FellowTraveler/Open-Transactions/tree/master/scripts/samples sample scripts] folder:

<pre>
def OT_ME::create_asset_acct(SERVER_ID, NYM_ID, ASSET_TYPE_ID)
{
var ot_Msg := OTAPI_Func()
// -------------------------
var theRequest := OTAPI_Func(ot_Msg.CREATE_ASSET_ACCT, SERVER_ID, NYM_ID, ASSET_TYPE_ID)
var strResponse = theRequest.SendRequest(theRequest, "CREATE_ASSET_ACCT")

return strResponse
}
</pre>

If it was a SUCCESS, then refresh the list of accounts in your display (from the OT API) since your new asset account should now be there.

(You can also use the "decode" command in the test wallet anytime you want to base64-decode something.)

-----

'''TRANSACTIONS'''

FYI: Balance agreement, combined with transaction numbers, is what makes it possible for the server and all other parties to ''eliminate account history, instead storing only the last signed receipt.'' (Of course they have the ''choice'' to keep their own records--but they are no longer ''forced'' to do so.)

In order to do any transaction, the wallet's ''balance agreement'' process requires that you have the latest copy of your account, inbox, and outbox files. You don't have to worry about this too much, since the high-level API will usually handle it for you.

'''You might ask: "But what if I download my account, or my outbox, and the server has maliciously inserted data into them?"''' ''No problem'' -- Open Transactions stores the last signed receipt from the server, and is able to verify the new intermediary files against that last receipt. You can see this happening when you run the command-line test client, and receipts can be verified programmatically using <code>OT_API_VerifyAccountReceipt()</code>.

The [[Triple Signed Receipts]] on Open Transactions ensure that this sort of protection is available to all parties, '''while simultaneously not having to store any transaction history!'''

-----

'''Write a Cheque''' Alice writes a cheque (offline): Call <code>OT_API_WriteCheque()</code> Alice then gives cheque to Bob (offline), ''or'' online if she prefers via <code>OT_API_sendUserMessage()</code> function. If Alice has Bob's UserID but not his public key, her wallet first uses <code>OT_API_checkUser()</code> to retrieve his public key from the server, and then encrypts the cheque before sending it.

NOTE: a quality wallet software will keep track of ALL instruments! Even when Alice gives a cheque to Bob, her wallet should still store a copy of that cheque. Until when? Until at least after he has cashed it... when he does that, a chequeReceipt will appear in her inbox. Only when she accepts that receipt, signing a new balance agreement, is she finally free of the transaction number that was on that cheque. (It was still signed-out to her, all the way up until that time.)

WHAT IF Bob had never cashed it? WHAT IF he lost it? Is Alice supposed to just keep signing for that number forever? (The chequeReceipt will never appear in her inbox. She is doomed to continue signing for this number on all of her receipts on into the future, ad infinitum, with no hope of ever closing it out!)

Fear not, there is a solution: <code>OT_API_DiscardCheque()</code>. (Lucky you saved a copy of that cheque in your wallet, eh?) This function will retrieve Alice's transaction # back from the cheque, so that her wallet is free to use it on her next valid transaction, and then close it out normally.

'''Deposit a cheque''' (A voucher is also a cheque, so you may deposit a voucher here the same as any other cheque.) Bob sends message to server requesting deposit:

'''(High level API version, in Java.)'''

<pre>
public boolean depositCheque(String serverID, String nymID, String accountID, String cheque) {

System.out.println("In depositCheque serverID:" + serverID + " nymID:" + nymID + " acount ID:" + accountID);

// ---------------------------------------------------
OTAPI_Func theRequest = new OTAPI_Func(OTAPI_Func.FT.DEPOSIT_CHEQUE, serverID, nymID, accountID, cheque);
String strResponse = OTAPI_Func.SendTransaction(theRequest, "DEPOSIT_CHEQUE"); // <========================

if (null == strResponse) {
System.out.println("OTAPI_Func.SendTransaction() failed, in depositCheque.");
return false;
}
// --------------------------------------------------------------------------------------

return true;
}
</pre>

'''Withdraw cash''' Alice's wallet first makes sure she has the latest public mint file, by calling <code>OT_API_getMint()</code>. (Note: if the mint she already has is within its valid date range, there's no need to do this.) (Note: If she does call getMint, Alice needs to check the server reply and make sure it was successful before continuing with the withdrawal. The public mint keys are necessary for cash withdrawal.) Alice then withdraws from her asset account, by messaging server: <code>OT_API_notarizeWithdrawal()</code> Server replies with chaumian cash, which is stored in the purse folder in local storage.

Here is the full Java implementation of Withdraw Cash:

<pre>
public boolean withdrawCash(String serverID, String nymID, String accountID, String amount)
{
String serverResponseMessage = null;
System.out.println("In withdrawCash serverID:" + serverID + " nymID:" + nymID + " acount ID:" + accountID);
String assetID = otapi.OT_API_GetAccountWallet_AssetTypeID(accountID);

// ----------------------------------------
// Make sure we have the proper asset contract for the withdrawal.
//
String assetContract = otapi.OT_API_LoadAssetContract(assetID);
if (assetContract == null) {
OTAPI_Func theRequest = new OTAPI_Func(OTAPI_Func.FT.GET_CONTRACT, serverID, nymID, assetID);
String strResponse = OTAPI_Func.SendRequest(theRequest, "GET_CONTRACT");

if (null == strResponse) {
System.out.println("IN withdrawCash: OTAPI_Func.SendRequest(GET_CONTRACT) failed. (I give up.) (Unable to find asset contract.)");
return false;
}
// ----------------------------------------
assetContract = otapi.OT_API_LoadAssetContract(assetID);
if (assetContract == null) {
System.out.println("OT_API_LoadAssetContract returned null even after OT_API_getContract (Unable to find asset contract.)");
return false;
}
}
// ---------------------------------------------------------
// Download the public mintfile if it's not there, or if it's expired.
// Also load it up into memory as a string (just to make sure it works.)
// Then we can actually send the withdrawal transaction request. (Until
// then, why bother?)
//
String mintFile;

// expired or missing.
if (1 != otapi.OT_API_Mint_IsStillGood(serverID, assetID))
{
// ----------------------------------------
OTAPI_Func theRequest = new OTAPI_Func(OTAPI_Func.FT.GET_MINT, serverID, nymID, assetID);
String strResponse = OTAPI_Func.SendRequest(theRequest, "GET_MINT");

if (null == strResponse) {
System.out.println("IN withdrawCash: OTAPI_Func.SendRequest(GET_MINT) failed. (I give up.) (Unable to get mint.)");
return false;
}
// ----------------------------------------
mintFile = otapi.OT_API_LoadMint(serverID, assetID);
if (mintFile == null) {
System.out.println("OT_API_LoadMint returned null even after OT_API_getMint (I give up.) (Unable to find mint.)");
return false;
}
}
else // current mint IS available already on local storage (and not expired.)
{
mintFile = otapi.OT_API_LoadMint(serverID, assetID);
if (mintFile == null) {
System.out.println("OT_API_LoadMint returned null even after successful OT_API_Mint_IsStillGood (I give up.) (Unable to find mint.)");
return false;
}
}
// ---------------------------------------------------
// By this point, the mintfile is DEFINITELY good (available, not null,
// not expired, and loaded up.) Now we know for a fact that when the API
// call is made to withdraw cash, that it will find the mint properly.
//
OTAPI_Func theRequest = new OTAPI_Func(OTAPI_Func.FT.WITHDRAW_CASH, serverID, nymID, accountID, amount);
String strResponse = OTAPI_Func.SendTransaction(theRequest, "WITHDRAW_CASH"); // <========================

if (null == strResponse) {
System.out.println("OTAPI_Func.SendTransaction() failed, in withdrawCash.");
return false;
}
// --------------------------------------------------------------------------------------

return true;
}
</pre>

'''Deposit cash''' Here is the complete Java implementation for Deposit Cash:

<pre>
public boolean depositCash(String serverID, String nymID, String accountID, String purse, boolean isToken) {

System.out.println("In depositCash serverID:" + serverID + " nymID:" + nymID + " acount ID:" + accountID + " isToken:" + isToken);
Utility.setOtDepositCash(null);
String oldPurse = purse;
if (isToken) {
purse = getNewPurse(purse, serverID, nymID, accountID);
System.out.println("purse after getting from push purse:" + purse);
if (purse == null) {
Utility.setOtDepositCash(oldPurse);
return false;
}
}
// ----------------------------------------
OTAPI_Func theRequest = new OTAPI_Func(OTAPI_Func.FT.DEPOSIT_CASH, serverID, nymID, accountID, purse);
String strResponse = OTAPI_Func.SendTransaction(theRequest, "DEPOSIT_CASH"); // <========================

if (null == strResponse) {
System.out.println("IN depositCash: OTAPI_Func.SendTransaction(() failed. (I give up.) ");

if (isToken) {
System.out.println("IN depositCash, failed action for single token");
String assetID = otapi.OT_API_GetAccountWallet_AssetTypeID(accountID);
boolean importStatus = otapi.OT_API_Wallet_ImportPurse(serverID, assetID, nymID, purse) == 1 ? true : false;
System.out.println("Since failure of depositCashPurse, OT_API_Wallet_ImportPurse called, status of import:" + importStatus);
if (!importStatus) {
Utility.setOtDepositCash(purse);
}
}

return false;
}
// ----------------------------------------
return true;
}
</pre>

-----

Note about local storage: Usually whenever something important is downloaded from the server, the OT API will save it automatically to the default storage context, and you can then load it up using another API call. This is usually the most convenient way to do things.

-----

'''Account-to-Account Transfer''' A ''pending transfer'' will go into your outbox, and the recipient's inbox, pending acceptance by the recipient. FYI, every asset account has its own inbox and outbox for handling pending transactions, as well as receipts. FYI, every Nym similarly has its own Nymbox, used for receiving messages from other users, and for receiving new transaction numbers from the server.

Here is the OT Script implementation of Send Transfer, from the [https://github.com/FellowTraveler/Open-Transactions/tree/master/scripts/samples sample scripts] folder:

<pre>
def OT_ME::send_transfer(SERVER_ID, NYM_ID, ACCT_FROM, ACCT_TO, AMOUNT, NOTE)
{
var ot_Msg := OTAPI_Func()
// -------------------------
var theRequest := OTAPI_Func(ot_Msg.SEND_TRANSFER, SERVER_ID, NYM_ID, ACCT_FROM, ACCT_TO, AMOUNT, NOTE)
var strResponse = theRequest.SendTransaction(theRequest, "SEND_TRANSFER")

return strResponse
}
</pre>

'''Withdraw Voucher''' A voucher is like a "money order" or "cashier's cheque". It's a cheque, but drawn on a server account, instead of your own account. Withdrawing in voucher form is similar to withdrawing in cash: the server debits your asset account, and then gives you an official cheque.

But with cash, it's automatically saved to your purse, whereas with a voucher, you have to read the voucher out of the server reply, and display it on the screen!

Here is the complete Java code to perform Withdraw Voucher:

<pre>
public String withdrawVoucher(String serverID, String nymID, String accountID, String amount, String chequeMemo, String recepientNymID) {

System.out.println("In withdrawVoucher serverID:" + serverID + " nymID:" + nymID + " acount ID:" + accountID);

// ---------------------------------------------------
OTAPI_Func theRequest = new OTAPI_Func(OTAPI_Func.FT.WITHDRAW_VOUCHER, serverID, nymID, accountID, recepientNymID, chequeMemo, amount);
String strResponse = OTAPI_Func.SendTransaction(theRequest, "WITHDRAW_VOUCHER"); // <========================

if (null == strResponse) {
System.out.println("OTAPI_Func.SendTransaction() failed, in withdrawVoucher.");
return null;
}
// ---------------------------------------------------------
String ledger = otapi.OT_API_Message_GetLedger(strResponse);
if (ledger == null) {
System.out.println(" ledger is null, returned by OT_API_Message_GetLedger, serverResponseMessage passed as argument");
return null;
}
String transaction = otapi.OT_API_Ledger_GetTransactionByIndex(serverID, nymID, accountID, ledger, 0);
if (transaction == null) {
System.out.println("withdrawVoucher: transaction is null, returned by OT_API_Ledger_GetTransactionByIndex, argument passed, index 0 and ledger :" + ledger);
return null;
}
// ---------------------------------------------------------
String output = otapi.OT_API_Transaction_GetVoucher(serverID, nymID, accountID, transaction);
System.out.println("output returned by OT_API_Transaction_GetVoucher:" + output);

return output;
}
</pre>

-----

'''BASKET CURRENCIES'''

'''Create a new Basket Currency''' First, invent the basket in your head. Give it name: ''"Clams."''
Next, give it a ratio in terms of other existing currencies: ''"10 Clams equals a basket of 5 dollars, 3 Euro, and 20 Bitcoin".'' Call <code>OT_API_GenerateBasketCreation()</code> to begin creating the basket. The ''"10 Clams"'' from above is set here. Next, call <code>OT_API_AddBasketCreationItem()</code> for EACH currency in the basket. In the above example, I would call this function 3 times, in order to set the ''"5 dollars"'' the ''"3 Euro"'' and the ''"20 Bitcoin"'' from above. Now that the basket has been defined, call <code>OT_API_issueBasket()</code> to actually create the basket currency on the server. (Now you have created a new asset type--a basket--which the server will control. Any user may now create accounts using this type! And from there, they can write cheques, withdraw cash, trade on markets, etc. the same as with any other asset type.)

'''Exchange Digital Assets in/out of a Basket Currency (from your Asset Accounts)''' First, call <code>OT_API_GenerateBasketExchange()</code> to setup the exchange. You'll need to know the basket's asset type, and you'll need to have an existing asset account of that type. You will also set the "transfer multiple" in that call. What's the transfer multiple? Remember the ratio above: "10 Clams equals a basket of 5 dollars, 3 Euro, and 20 Bitcoin"

Here are examples of the transfer multiple: <br>
"10 Clams == 5 USD, 3 EUR, 20 BIT" (Transfer multiple: 1) <br>
"20 Clams == 10 USD, 6 EUR, 40 BIT" (Transfer multiple: 2) <br>
"30 Clams == 15 USD, 9 EUR, 60 BIT" (Transfer multiple: 3) <br>
"40 Clams == 20 USD, 12 EUR, 80 BIT" (Transfer multiple: 4) <br>
"50 Clams == 25 USD, 15 EUR, 100 BIT" (Transfer multiple: 5)<br>

Next, call <code>OT_API_AddBasketExchangeItem()</code> for each currency type in the basket. You will need to to pass the asset account ID for an existing asset account, for each currency type (since you are converting in or out, from your basket account, to your asset accounts.) Therefore you will call this function once for USD, once for EUR, and once for BIT, in that example, passing in your USD asset acct ID, your EUR asset acct ID, and your Bitcoin asset account ID.

Now that it's all set up, call <code>OT_API_exchangeBasket()</code> to actually message the server and perform the exchange.

'''Interesting: basket currencies themselves require no more additional system resources than normal currencies!''' The magic happens during the exchange process. The server simply stores internal asset accounts for the dollars, euros, and bitcoins (say), and it manages the issuer account for the basket, and it also manages the exchanging in and out, by moving digital assets in or out of the internal backing accounts. After that point, a basket is just another Asset Type ID, and requires no additional resources. You can even have baskets made up of other baskets, nested 10 times, and it won't affect the speed of operation of the server!

-----

'''PROCESSING YOUR INBOX'''

'''Process the Receipts and Pending Transfers in your Inbox''' <br>
If you wish, call <code>OT_API_getInbox()</code> to grab the latest inbox from the server. In the high-level API, this is often just automated for you, but nevertheless, check out the dl_acct_files.ot script. See also show_inbox.ot, etc.

During this time, your user has the opportunity to peruse the inbox, and to decide which transactions therein he wishes to accept or reject. Usually the inbox is display on the screen, then the user selects various items to accept or reject, and then the user clicks "Process Inbox" and then you do this:

Then call <code>OT_API_Ledger_CreateResponse()</code> in order to create a 'response' ledger for that inbox, which will be sent to the server to signal your responses to the various inbox transactions. <br>Then call <code>OT_API_Ledger_GetCount()</code> (pass it the inbox) to find out how many transactions are inside of it. Use that count to LOOP through them...
<br>Use <code>OT_API_Ledger_GetTransactionByIndex()</code> to grab each transaction as you iterate through the inbox. (There are various introspection functions you can use in the API here if you wish to display the inbox items on the screen for the user...)
<br>Next call <code>OT_API_Transaction_CreateResponse()</code> for each transaction in the inbox, to create a response to it, accepting or rejecting it. This function creates the response and adds it to the response ledger.
<br>Next, call <code>OT_API_Ledger_FinalizeResponse()</code> which will create a ''Balance Agreement'' for the ledger.
<br>Finally, call <code>OT_API_processInbox()</code> to send your message to the server and process the various items. (See the accept_inbox.ot script.)

If the message was successful, then use <code>OT_API_Message_GetBalanceAgreementSuccess()</code> and <code>OT_API_Message_GetTransactionSuccess()</code> to see just ''how'' successful.

-----

'''MARKETS and PAYMENT PLANS'''

'''Setup a Payment Plan''' The Merchant draws up the Payment Plan using <code>OT_API_ProposePaymentPlan</code> Then he sends it to the Customer, who calls <code>OT_API_ConfirmPaymentPlan</code> The Customer's wallet activates the payment plan by sending it to the server using this function: <code>OT_API_depositPaymentPlan()</code> (Receipts will process into the respective parties' inboxes.) Use OT_API_cancelCronItem() to cancel any payment plan (or market offer.)

If the message was successful, then use <code>OT_API_Message_GetBalanceAgreementSuccess()</code> and <code>OT_API_Message_GetTransactionSuccess()</code> as described above in the ''deposit cash'' instructions.

'''Issue a [[Markets|Market]] Offer'''

Call this function: <code>OT_API_issueMarketOffer()</code><br>
(That's the low-level one. See create_offer.ot script for the high-level version.)<br>
Call <code>OT_API_Message_GetSuccess</code> to find out if the message was a SUCCESS or FAILURE.<br>
If the message was successful, then use <code>OT_API_Message_GetBalanceAgreementSuccess()</code> and <code>OT_API_Message_GetTransactionSuccess()</code> as described above in the ''deposit cash'' instructions.<br>
See the OTScript and Java versions of these calls.

Once an offer goes onto the market, multiple trades may occur between it and the other offers on the market. (According to the rules in the offers.) Receipts will process into the respective parties' inboxes after each trade.

'''Cancel a Market Offer''' Use <code>OT_API_cancelNymMarketOffer</code> to remove an offer from a market. If the message was successful, then use <code>OT_API_Message_GetBalanceAgreementSuccess()</code> and <code>OT_API_Message_GetTransactionSuccess()</code>

'''Retrieving Market Data from OT Server:''' <code>OT_API_getMarketList</code> retrieves a list of all the markets available on a specific server, and details for each market. If the server call is a success, the data will be retrieved from the OT server, and written to local storage using the OT Storage API, at this path or key (inside your data_folder location): <code>markets/SERVER_ID/market_data.bin</code> <br>
If you want to verify whether the data is now available in local storage (after a successful call to getMarketList), your code would look like this: <br>
<code>if (otapi.Exists("markets", serverID, "market_data.bin")) bFoundFile = true;</code>

Here is some Java code that reads the market list object from local storage, assuming bFoundFile is true:

<pre class="Java"> MarketList marketList = null;
Storable storable = null;

if (otapi.Exists("markets", serverID, "market_data.bin"))
{
storable =
otapi.QueryObject(StoredObjectType.STORED_OBJ_MARKET_LIST,
"markets", serverID, "market_data.bin");
if (storable==null)
return null;
marketList = MarketList.ot_dynamic_cast(storable);
}</pre>
Once you have the market list, here is some sample Java code to read the details of an individual market from that list:

<pre class="Java">public static Object getMarketDetails(String marketID)
{
MarketList marketList = Utility.getMarketList();

if (marketList == null)
{
return null;
}

for (int i=0; i < marketList.GetMarketDataCount(); i++)
{
MarketData marketData = marketList.GetMarketData(i);

if (marketData == null)
continue;

String [] row = new String[2];

if (marketID.equals(marketData.getMarket_id()))
{
String[] data = new String[2];
marketData.getLast_sale_price();
marketData.getCurrent_ask();

// Etc!! This is where you get the market details.
}
}

// return custom object here (row/data or whatever), or null if failure..
return null;
}
</pre>
<code>OT_API_getMarketOffers</code> retrieves publicly-available info for all offers on a specific market, up until maximum depth, and saves the data here: <code>markets/SERVER_ID/offers/MARKET_ID.bin</code>

(See testwallet/OTAPI.i for ALL DATA OBJECTS that are used in local storage, including market offers, recent trades, etc. See the code above for a sample on how those data objects are used.)

<code>OT_API_getMarketRecentTrades</code>: Retrieves all recent trades on a market (up until maximum depth), and stores them here: <code>markets/SERVER_ID/recent/MARKET_ID.bin</code>

To retrieve the offers that a specific Nym has out on the market, use: <code>OT_API_getNym_MarketOffers</code> This ''getNym''MarketOffers_ data is ''private'' and thus a lot more detailed than what's retrieved via <code>OT_API_Market_GetOffers</code>, which is more meant for public use. After a successful retrieval, you can load the data from this location: <code>nyms/SERVER_ID/offers/NYM_ID.bin</code>

If you want to see the Nym's private list of his '''completed trades''', the path to load it from is here: <code>nyms/trades/SERVER_ID/NYM_ID</code> There is no need to send a server message in this last case--just read the data from local storage directly. (When market trading receipts are accepted and cleared out of your inbox, this is where they will go. So there's no need to download them, since they were already downloaded through your inbox previously.) As before, the appropriate data object can be found in testwallet/OTAPI.i along with all the others.

-----

I will be very responsive to developer needs and questions regarding the OT API, so I encourage you to play with the software and contact me anytime.

See also:<br>
[[API|The OT low-level API]]<br>
[[Install|Installation]] <br>
[https://github.com/FellowTraveler/Open-Transactions/wiki/opentxs opentxs command-line tool]

[[List of Classes|The OT C++ class library]]

''Diagrams:'' '''[http://billstclair.com/ot/ot-diagram.jpg Architecture Overview]''', '''[http://billstclair.com/ot/OT-Anon-CashOnly.jpg Fully-Anonymous]''' (cash only), and '''[http://billstclair.com/ot/OT-Pseudonym-Instruments.jpg Pseudo-Anonymous]''' (using accounts).

Use Cases

2015-07-08T22:46:33Z

FellowTraveler: typo

Anytime you need to do something, use the high-level API to do it (OT_ME.) Only if you can't find the function you are looking for, should you next resort to the low-level API (OTAPI.) And remember, you can always the copy the code you need from the test GUI, [http://github.com/Open-Transactions/Moneychanger Moneychanger].

'''What does this mean for you? It means you no longer have to worry about synchronizing request numbers, or harvesting transaction numbers, or comparing inbox hashes, or downloading your nymbox, or dropped messages, or timeouts, or retries, etc!''' Instead, you use simple functions like '''send_transfer''' or '''withdraw_cash.''' The high-level API manages everything else behind the scenes. And any sample code you need can be copied right out of Moneychanger's code.

-----

NOTE: The below notes are old, but preserved for usefulness.

-----

'''USE CASES for the OT API, described on this page:'''

* '''(Client software starts up.)''' Initialize the library and load the wallet.
* Display for user: '''Server Contracts, Nyms, Accounts, and Asset Types.'''
* Change the wallet's ''display label'' for any server, asset type, account, or nym.
* Import a server contract (or asset contract) to the wallet.
* Create a new '''Pseudonym''' (public/private key pair).
* Register a public key (a ''"Nym"'') at an OT server.
* '''Issue a new digital Asset Type'''. (Uploading an asset contract.)
* Retrieve Currency Contract (by ID).
* '''Create a new Asset Account'''.
* '''Write a cheque''' (or invoice)
* '''Send a Message''' to another user (via the server, encrypted to the recipient's public key.)
* '''Deposit a cheque'''
* '''Withdraw cash''' . . . . <==== CHAUMIAN DIGITAL CASH!!
* '''Deposit cash'''
* Withdraw Voucher
* '''Account-to-Account Transfer'''
* Create a new '''Basket Currency'''
* '''Exchange''' Digital Assets '''in and out of Baskets''' (from your Asset Accounts)
* '''Process your Inbox''' (Receipts and pending transfers)
* Set up a '''Payment Plan'''
* Issue a '''Market Offer'''

-----

'''USE CASES for the OT API'''

'''Initialize the library and Load your Wallet'''
(The user starts up the wallet software.)
Call <code>OT_API_Init()</code> Then call <code>OT_API_LoadWallet()</code>

(NOTE: these above 2 steps are not necessary in OT-script, only Java and other languages.)

'''Display the current list of server contracts on the screen''' Call <code>OT_API_GetServerCount()</code>, which returns the number of server contracts in your wallet. For each one, call <code>OT_API_GetServer_ID()</code> to get the Server ID (which is a hash of the contract.) Also for each, call <code>OT_API_GetServer_Name()</code> to get the Display Name from the contract. In your GUI, display the name on the screen, but use the ID behind the scenes (for your messages to the server.)

'''Do the same thing for Nyms, Accounts, and Asset Types.''' You can read about them on the [[API]] page, but here are the basic functions:

OT_API_GetNymCount(void);
OT_API_GetServerCount(void);
OT_API_GetAssetTypeCount(void);
OT_API_GetAccountCount(void);

OT_API_GetNym_ID() and OT_API_GetNym_Name()
OT_API_GetServer_ID() and OT_API_GetServer_Name()
OT_API_GetAssetType_ID() and OT_API_GetAssetType_Name()
OT_API_GetAccountWallet_ID() and OT_API_GetAccountWallet_Name()
Also:
OT_API_GetAccountWallet_Balance()
OT_API_GetAccountWallet_Type()
OT_API_GetAccountWallet_AssetTypeID()

'''Add a new server contract (or asset contract) to the wallet''' Call <code>OT_API_AddServerContract()</code>
or <code>OT_API_AddAssetContract()</code>.

'''Create a new Pseudonym''' (Each user's wallet may contain many pseudonyms. Each Nym consists of a public and a private key, aka a "key pair".) Call <code>OT_API_CreateNym()</code> This creates a new key pair ''("Nym")'' in your wallet, which you can use for communications with an OT server. (That is, for opening asset accounts and performing various other transactions. A Nym is a "user account".) (You can create as many of these pseudonyms as you want.) (You can register the same nyms at multiple servers.) (The same Nym will have the same Nym ID and public key on every server.)

Example

<pre>def details_create_nym(nKeybits, strName)
{
var madeEasy = OT_ME()
var strNymID = madeEasy.create_pseudonym(nKeybits, "", "") // returns new Nym ID

if (!VerifyStringVal(strNymID))
{
OT_API_Output(0, "details_create_nym: Failed in OT_ME::create_pseudonym(keybits == " + nKeybits.to_string() + ")\n")
return (0)
}
OT_API_Output(0, "Success creating! " + nKeybits.to_string() + " keybits, new ID: ") // stderr
print(strNymID) // stdout
OT_API_Output(0, "\n") //stderr
// -------------------
var bSetName = OT_API_SetNym_Name(strNymID, // subject
strNymID, // signer
strName)
if (!bSetName)
{
OT_API_Output(0, "Failed in OT_API_SetNym_Name(name == " + strName + ")\n")
return (0)
}
// -------------------
OT_API_Output(0, "Success setting name to: " + strName + "\n\n") // stderr
return 1
}</pre>
'''Register a public key (aka "Nym") at an OT server'''

<pre> var madeEasy = OT_ME()
if (VerifyExists("Server") && VerifyExists("MyNym"))
{
var strResponse = madeEasy.register_nym(Server, MyNym)
var nSuccess = VerifyMessageSuccess(strResponse)
switch(nSuccess)
{
case (1)
{
OT_API_Output(0, "\n\n SUCCESS in register_nym! Server response:\n\n");
print(strResponse) // stdout
break
}
default
{
OT_API_Output(0, "\n\n Failure or Error in register_nym!\n")

if (VerifyStringVal(strResponse))
{
OT_API_Output(0, "Server response:\n\n");
print(strResponse) // stdout
}
break
}
}</pre>
'''Change the wallet's label for any server/asset type/account/nym'''<br>
(This is only a client-side label, for display purposes only.)<br>
<code>OT_API_SetNym_Name()</code><br>
<code>OT_API_SetAccountWallet_Name()</code> <br>
<code>OT_API_SetAssetType_Name()</code> <br>
<code>OT_API_SetServer_Name()</code><br>

-----

'''Issue a new digital Asset Type''' User uploads a new currency contract to the server, so users can create asset accounts based on that asset type. Server replies with a new issuer account ID (The new Issuer account appears inside your wallet's account list, so go ahead and iterate the list again, in order to display the updated list of accounts on the screen.)

High-level API version (in OT script):

<pre>
var madeEasy = OT_ME()
OT_API_Output(0, "Please paste a currency contract, followed by an EOF or a ~ by itself on a blank line:\n\n")
var strContract = OT_CLI_ReadUntilEOF()
var strResponse = madeEasy.issue_asset_type(Server, MyNym, strContract)
var nStatus = VerifyMessageSuccess(strResponse)

switch(nStatus)
{
case (1)
{
OT_API_Output(0, "\n\n SUCCESS in issue_asset! Server response:\n\n");
print(strResponse) // stdout
break
}
default
{
OT_API_Output(0, "\n\n Failure or error in issue_asset. nStatus: "+nStatus.to_string()+"\n")
if (VerifyStringVal(strResponse))
{
OT_API_Output(0, "Server response:\n\n");
print(strResponse) // stdout
}
break
}
}</pre>
'''Retrieve Currency Contract (by ID)''' User wants to download a currency contract from the server (for a given asset type ID.) (The asset type ID is a hash of the contract, so OT will know if you get the wrong one, since this is verified whenever a contract is loaded up.)

High-level API version (in OT script):

<pre> var madeEasy = OT_ME()
var strRetrieved = madeEasy.retrieve_contract(Server, MyNym, strContractID)
var nRetrieved = VerifyMessageSuccess(strRetrieved)
var strSuccess = "ERROR"
if (1 == nRetrieved)
{ strSuccess = "SUCCESS" }
else if (0 == nRetrieved)
{ strSuccess = "FAILED" }
OT_API_Output(0, "\n\n " + strSuccess + " retrieving contract: "+strContractID+"\n\n")</pre>

'''Create a new Asset Account''' Example in OT Script, from the [https://github.com/FellowTraveler/Open-Transactions/tree/master/scripts/samples sample scripts] folder:

<pre>
def OT_ME::create_asset_acct(SERVER_ID, NYM_ID, ASSET_TYPE_ID)
{
var ot_Msg := OTAPI_Func()
// -------------------------
var theRequest := OTAPI_Func(ot_Msg.CREATE_ASSET_ACCT, SERVER_ID, NYM_ID, ASSET_TYPE_ID)
var strResponse = theRequest.SendRequest(theRequest, "CREATE_ASSET_ACCT")

return strResponse
}
</pre>

If it was a SUCCESS, then refresh the list of accounts in your display (from the OT API) since your new asset account should now be there.

(You can also use the "decode" command in the test wallet anytime you want to base64-decode something.)

-----

'''TRANSACTIONS'''

FYI: Balance agreement, combined with transaction numbers, is what makes it possible for the server and all other parties to ''eliminate account history, instead storing only the last signed receipt.'' (Of course they have the ''choice'' to keep their own records--but they are no longer ''forced'' to do so.)

In order to do any transaction, the wallet's ''balance agreement'' process requires that you have the latest copy of your account, inbox, and outbox files. You don't have to worry about this too much, since the high-level API will usually handle it for you.

'''You might ask: "But what if I download my account, or my outbox, and the server has maliciously inserted data into them?"''' ''No problem'' -- Open Transactions stores the last signed receipt from the server, and is able to verify the new intermediary files against that last receipt. You can see this happening when you run the command-line test client, and receipts can be verified programmatically using <code>OT_API_VerifyAccountReceipt()</code>.

The [[Triple Signed Receipts]] on Open Transactions ensure that this sort of protection is available to all parties, '''while simultaneously not having to store any transaction history!'''

-----

'''Write a Cheque''' Alice writes a cheque (offline): Call <code>OT_API_WriteCheque()</code> Alice then gives cheque to Bob (offline), ''or'' online if she prefers via <code>OT_API_sendUserMessage()</code> function. If Alice has Bob's UserID but not his public key, her wallet first uses <code>OT_API_checkUser()</code> to retrieve his public key from the server, and then encrypts the cheque before sending it.

NOTE: a quality wallet software will keep track of ALL instruments! Even when Alice gives a cheque to Bob, her wallet should still store a copy of that cheque. Until when? Until at least after he has cashed it... when he does that, a chequeReceipt will appear in her inbox. Only when she accepts that receipt, signing a new balance agreement, is she finally free of the transaction number that was on that cheque. (It was still signed-out to her, all the way up until that time.)

WHAT IF Bob had never cashed it? WHAT IF he lost it? Is Alice supposed to just keep signing for that number forever? (The chequeReceipt will never appear in her inbox. She is doomed to continue signing for this number on all of her receipts on into the future, ad infinitum, with no hope of ever closing it out!)

Fear not, there is a solution: <code>OT_API_DiscardCheque()</code>. (Lucky you saved a copy of that cheque in your wallet, eh?) This function will retrieve Alice's transaction # back from the cheque, so that her wallet is free to use it on her next valid transaction, and then close it out normally.

'''Deposit a cheque''' (A voucher is also a cheque, so you may deposit a voucher here the same as any other cheque.) Bob sends message to server requesting deposit:

'''(High level API version, in Java.)'''

<pre>
public boolean depositCheque(String serverID, String nymID, String accountID, String cheque) {

System.out.println("In depositCheque serverID:" + serverID + " nymID:" + nymID + " acount ID:" + accountID);

// ---------------------------------------------------
OTAPI_Func theRequest = new OTAPI_Func(OTAPI_Func.FT.DEPOSIT_CHEQUE, serverID, nymID, accountID, cheque);
String strResponse = OTAPI_Func.SendTransaction(theRequest, "DEPOSIT_CHEQUE"); // <========================

if (null == strResponse) {
System.out.println("OTAPI_Func.SendTransaction() failed, in depositCheque.");
return false;
}
// --------------------------------------------------------------------------------------

return true;
}
</pre>

'''Withdraw cash''' Alice's wallet first makes sure she has the latest public mint file, by calling <code>OT_API_getMint()</code>. (Note: if the mint she already has is within its valid date range, there's no need to do this.) (Note: If she does call getMint, Alice needs to check the server reply and make sure it was successful before continuing with the withdrawal. The public mint keys are necessary for cash withdrawal.) Alice then withdraws from her asset account, by messaging server: <code>OT_API_notarizeWithdrawal()</code> Server replies with chaumian cash, which is stored in the purse folder in local storage.

Here is the full Java implementation of Withdraw Cash:

<pre>
public boolean withdrawCash(String serverID, String nymID, String accountID, String amount)
{
String serverResponseMessage = null;
System.out.println("In withdrawCash serverID:" + serverID + " nymID:" + nymID + " acount ID:" + accountID);
String assetID = otapi.OT_API_GetAccountWallet_AssetTypeID(accountID);

// ----------------------------------------
// Make sure we have the proper asset contract for the withdrawal.
//
String assetContract = otapi.OT_API_LoadAssetContract(assetID);
if (assetContract == null) {
OTAPI_Func theRequest = new OTAPI_Func(OTAPI_Func.FT.GET_CONTRACT, serverID, nymID, assetID);
String strResponse = OTAPI_Func.SendRequest(theRequest, "GET_CONTRACT");

if (null == strResponse) {
System.out.println("IN withdrawCash: OTAPI_Func.SendRequest(GET_CONTRACT) failed. (I give up.) (Unable to find asset contract.)");
return false;
}
// ----------------------------------------
assetContract = otapi.OT_API_LoadAssetContract(assetID);
if (assetContract == null) {
System.out.println("OT_API_LoadAssetContract returned null even after OT_API_getContract (Unable to find asset contract.)");
return false;
}
}
// ---------------------------------------------------------
// Download the public mintfile if it's not there, or if it's expired.
// Also load it up into memory as a string (just to make sure it works.)
// Then we can actually send the withdrawal transaction request. (Until
// then, why bother?)
//
String mintFile;

// expired or missing.
if (1 != otapi.OT_API_Mint_IsStillGood(serverID, assetID))
{
// ----------------------------------------
OTAPI_Func theRequest = new OTAPI_Func(OTAPI_Func.FT.GET_MINT, serverID, nymID, assetID);
String strResponse = OTAPI_Func.SendRequest(theRequest, "GET_MINT");

if (null == strResponse) {
System.out.println("IN withdrawCash: OTAPI_Func.SendRequest(GET_MINT) failed. (I give up.) (Unable to get mint.)");
return false;
}
// ----------------------------------------
mintFile = otapi.OT_API_LoadMint(serverID, assetID);
if (mintFile == null) {
System.out.println("OT_API_LoadMint returned null even after OT_API_getMint (I give up.) (Unable to find mint.)");
return false;
}
}
else // current mint IS available already on local storage (and not expired.)
{
mintFile = otapi.OT_API_LoadMint(serverID, assetID);
if (mintFile == null) {
System.out.println("OT_API_LoadMint returned null even after successful OT_API_Mint_IsStillGood (I give up.) (Unable to find mint.)");
return false;
}
}
// ---------------------------------------------------
// By this point, the mintfile is DEFINITELY good (available, not null,
// not expired, and loaded up.) Now we know for a fact that when the API
// call is made to withdraw cash, that it will find the mint properly.
//
OTAPI_Func theRequest = new OTAPI_Func(OTAPI_Func.FT.WITHDRAW_CASH, serverID, nymID, accountID, amount);
String strResponse = OTAPI_Func.SendTransaction(theRequest, "WITHDRAW_CASH"); // <========================

if (null == strResponse) {
System.out.println("OTAPI_Func.SendTransaction() failed, in withdrawCash.");
return false;
}
// --------------------------------------------------------------------------------------

return true;
}
</pre>

'''Deposit cash''' Here is the complete Java implementation for Deposit Cash:

<pre>
public boolean depositCash(String serverID, String nymID, String accountID, String purse, boolean isToken) {

System.out.println("In depositCash serverID:" + serverID + " nymID:" + nymID + " acount ID:" + accountID + " isToken:" + isToken);
Utility.setOtDepositCash(null);
String oldPurse = purse;
if (isToken) {
purse = getNewPurse(purse, serverID, nymID, accountID);
System.out.println("purse after getting from push purse:" + purse);
if (purse == null) {
Utility.setOtDepositCash(oldPurse);
return false;
}
}
// ----------------------------------------
OTAPI_Func theRequest = new OTAPI_Func(OTAPI_Func.FT.DEPOSIT_CASH, serverID, nymID, accountID, purse);
String strResponse = OTAPI_Func.SendTransaction(theRequest, "DEPOSIT_CASH"); // <========================

if (null == strResponse) {
System.out.println("IN depositCash: OTAPI_Func.SendTransaction(() failed. (I give up.) ");

if (isToken) {
System.out.println("IN depositCash, failed action for single token");
String assetID = otapi.OT_API_GetAccountWallet_AssetTypeID(accountID);
boolean importStatus = otapi.OT_API_Wallet_ImportPurse(serverID, assetID, nymID, purse) == 1 ? true : false;
System.out.println("Since failure of depositCashPurse, OT_API_Wallet_ImportPurse called, status of import:" + importStatus);
if (!importStatus) {
Utility.setOtDepositCash(purse);
}
}

return false;
}
// ----------------------------------------
return true;
}
</pre>

-----

Note about local storage: Usually whenever something important is downloaded from the server, the OT API will save it automatically to the default storage context, and you can then load it up using another API call. This is usually the most convenient way to do things.

-----

'''Account-to-Account Transfer''' A ''pending transfer'' will go into your outbox, and the recipient's inbox, pending acceptance by the recipient. FYI, every asset account has its own inbox and outbox for handling pending transactions, as well as receipts. FYI, every Nym similarly has its own Nymbox, used for receiving messages from other users, and for receiving new transaction numbers from the server.

Here is the OT Script implementation of Send Transfer, from the [https://github.com/FellowTraveler/Open-Transactions/tree/master/scripts/samples sample scripts] folder:

<pre>
def OT_ME::send_transfer(SERVER_ID, NYM_ID, ACCT_FROM, ACCT_TO, AMOUNT, NOTE)
{
var ot_Msg := OTAPI_Func()
// -------------------------
var theRequest := OTAPI_Func(ot_Msg.SEND_TRANSFER, SERVER_ID, NYM_ID, ACCT_FROM, ACCT_TO, AMOUNT, NOTE)
var strResponse = theRequest.SendTransaction(theRequest, "SEND_TRANSFER")

return strResponse
}
</pre>

'''Withdraw Voucher''' A voucher is like a "money order" or "cashier's cheque". It's a cheque, but drawn on a server account, instead of your own account. Withdrawing in voucher form is similar to withdrawing in cash: the server debits your asset account, and then gives you an official cheque.

But with cash, it's automatically saved to your purse, whereas with a voucher, you have to read the voucher out of the server reply, and display it on the screen!

Here is the complete Java code to perform Withdraw Voucher:

<pre>
public String withdrawVoucher(String serverID, String nymID, String accountID, String amount, String chequeMemo, String recepientNymID) {

System.out.println("In withdrawVoucher serverID:" + serverID + " nymID:" + nymID + " acount ID:" + accountID);

// ---------------------------------------------------
OTAPI_Func theRequest = new OTAPI_Func(OTAPI_Func.FT.WITHDRAW_VOUCHER, serverID, nymID, accountID, recepientNymID, chequeMemo, amount);
String strResponse = OTAPI_Func.SendTransaction(theRequest, "WITHDRAW_VOUCHER"); // <========================

if (null == strResponse) {
System.out.println("OTAPI_Func.SendTransaction() failed, in withdrawVoucher.");
return null;
}
// ---------------------------------------------------------
String ledger = otapi.OT_API_Message_GetLedger(strResponse);
if (ledger == null) {
System.out.println(" ledger is null, returned by OT_API_Message_GetLedger, serverResponseMessage passed as argument");
return null;
}
String transaction = otapi.OT_API_Ledger_GetTransactionByIndex(serverID, nymID, accountID, ledger, 0);
if (transaction == null) {
System.out.println("withdrawVoucher: transaction is null, returned by OT_API_Ledger_GetTransactionByIndex, argument passed, index 0 and ledger :" + ledger);
return null;
}
// ---------------------------------------------------------
String output = otapi.OT_API_Transaction_GetVoucher(serverID, nymID, accountID, transaction);
System.out.println("output returned by OT_API_Transaction_GetVoucher:" + output);

return output;
}
</pre>

-----

'''BASKET CURRENCIES'''

'''Create a new Basket Currency''' First, invent the basket in your head. Give it name: ''"Clams."''
Next, give it a ratio in terms of other existing currencies: ''"10 Clams equals a basket of 5 dollars, 3 Euro, and 20 Bitcoin".'' Call <code>OT_API_GenerateBasketCreation()</code> to begin creating the basket. The ''"10 Clams"'' from above is set here. Next, call <code>OT_API_AddBasketCreationItem()</code> for EACH currency in the basket. In the above example, I would call this function 3 times, in order to set the ''"5 dollars"'' the ''"3 Euro"'' and the ''"20 Bitcoin"'' from above. Now that the basket has been defined, call <code>OT_API_issueBasket()</code> to actually create the basket currency on the server. (Now you have created a new asset type--a basket--which the server will control. Any user may now create accounts using this type! And from there, they can write cheques, withdraw cash, trade on markets, etc. the same as with any other asset type.)

'''Exchange Digital Assets in/out of a Basket Currency (from your Asset Accounts)''' First, call <code>OT_API_GenerateBasketExchange()</code> to setup the exchange. You'll need to know the basket's asset type, and you'll need to have an existing asset account of that type. You will also set the "transfer multiple" in that call. What's the transfer multiple? Remember the ratio above: "10 Clams equals a basket of 5 dollars, 3 Euro, and 20 Bitcoin"

Here are examples of the transfer multiple: <br>
"10 Clams == 5 USD, 3 EUR, 20 BIT" (Transfer multiple: 1) <br>
"20 Clams == 10 USD, 6 EUR, 40 BIT" (Transfer multiple: 2) <br>
"30 Clams == 15 USD, 9 EUR, 60 BIT" (Transfer multiple: 3) <br>
"40 Clams == 20 USD, 12 EUR, 80 BIT" (Transfer multiple: 4) <br>
"50 Clams == 25 USD, 15 EUR, 100 BIT" (Transfer multiple: 5)<br>

Next, call <code>OT_API_AddBasketExchangeItem()</code> for each currency type in the basket. You will need to to pass the asset account ID for an existing asset account, for each currency type (since you are converting in or out, from your basket account, to your asset accounts.) Therefore you will call this function once for USD, once for EUR, and once for BIT, in that example, passing in your USD asset acct ID, your EUR asset acct ID, and your Bitcoin asset account ID.

Now that it's all set up, call <code>OT_API_exchangeBasket()</code> to actually message the server and perform the exchange.

'''Interesting: basket currencies themselves require no more additional system resources than normal currencies!''' The magic happens during the exchange process. The server simply stores internal asset accounts for the dollars, euros, and bitcoins (say), and it manages the issuer account for the basket, and it also manages the exchanging in and out, by moving digital assets in or out of the internal backing accounts. After that point, a basket is just another Asset Type ID, and requires no additional resources. You can even have baskets made up of other baskets, nested 10 times, and it won't affect the speed of operation of the server!

-----

'''PROCESSING YOUR INBOX'''

'''Process the Receipts and Pending Transfers in your Inbox''' <br>
If you wish, call <code>OT_API_getInbox()</code> to grab the latest inbox from the server. In the high-level API, this is often just automated for you, but nevertheless, check out the dl_acct_files.ot script. See also show_inbox.ot, etc.

During this time, your user has the opportunity to peruse the inbox, and to decide which transactions therein he wishes to accept or reject. Usually the inbox is display on the screen, then the user selects various items to accept or reject, and then the user clicks "Process Inbox" and then you do this:

Then call <code>OT_API_Ledger_CreateResponse()</code> in order to create a 'response' ledger for that inbox, which will be sent to the server to signal your responses to the various inbox transactions. <br>Then call <code>OT_API_Ledger_GetCount()</code> (pass it the inbox) to find out how many transactions are inside of it. Use that count to LOOP through them...
<br>Use <code>OT_API_Ledger_GetTransactionByIndex()</code> to grab each transaction as you iterate through the inbox. (There are various introspection functions you can use in the API here if you wish to display the inbox items on the screen for the user...)
<br>Next call <code>OT_API_Transaction_CreateResponse()</code> for each transaction in the inbox, to create a response to it, accepting or rejecting it. This function creates the response and adds it to the response ledger.
<br>Next, call <code>OT_API_Ledger_FinalizeResponse()</code> which will create a ''Balance Agreement'' for the ledger.
<br>Finally, call <code>OT_API_processInbox()</code> to send your message to the server and process the various items. (See the accept_inbox.ot script.)

If the message was successful, then use <code>OT_API_Message_GetBalanceAgreementSuccess()</code> and <code>OT_API_Message_GetTransactionSuccess()</code> to see just ''how'' successful.

-----

'''MARKETS and PAYMENT PLANS'''

'''Setup a Payment Plan''' The Merchant draws up the Payment Plan using <code>OT_API_ProposePaymentPlan</code> Then he sends it to the Customer, who calls <code>OT_API_ConfirmPaymentPlan</code> The Customer's wallet activates the payment plan by sending it to the server using this function: <code>OT_API_depositPaymentPlan()</code> (Receipts will process into the respective parties' inboxes.) Use OT_API_cancelCronItem() to cancel any payment plan (or market offer.)

If the message was successful, then use <code>OT_API_Message_GetBalanceAgreementSuccess()</code> and <code>OT_API_Message_GetTransactionSuccess()</code> as described above in the ''deposit cash'' instructions.

'''Issue a [[Markets|Market]] Offer'''

Call this function: <code>OT_API_issueMarketOffer()</code><br>
(That's the low-level one. See create_offer.ot script for the high-level version.)<br>
Call <code>OT_API_Message_GetSuccess</code> to find out if the message was a SUCCESS or FAILURE.<br>
If the message was successful, then use <code>OT_API_Message_GetBalanceAgreementSuccess()</code> and <code>OT_API_Message_GetTransactionSuccess()</code> as described above in the ''deposit cash'' instructions.<br>
See the OTScript and Java versions of these calls.

Once an offer goes onto the market, multiple trades may occur between it and the other offers on the market. (According to the rules in the offers.) Receipts will process into the respective parties' inboxes after each trade.

'''Cancel a Market Offer''' Use <code>OT_API_cancelNymMarketOffer</code> to remove an offer from a market. If the message was successful, then use <code>OT_API_Message_GetBalanceAgreementSuccess()</code> and <code>OT_API_Message_GetTransactionSuccess()</code>

'''Retrieving Market Data from OT Server:''' <code>OT_API_getMarketList</code> retrieves a list of all the markets available on a specific server, and details for each market. If the server call is a success, the data will be retrieved from the OT server, and written to local storage using the OT Storage API, at this path or key (inside your data_folder location): <code>markets/SERVER_ID/market_data.bin</code> <br>
If you want to verify whether the data is now available in local storage (after a successful call to getMarketList), your code would look like this: <br>
<code>if (otapi.Exists("markets", serverID, "market_data.bin")) bFoundFile = true;</code>

Here is some Java code that reads the market list object from local storage, assuming bFoundFile is true:

<pre class="Java"> MarketList marketList = null;
Storable storable = null;

if (otapi.Exists("markets", serverID, "market_data.bin"))
{
storable =
otapi.QueryObject(StoredObjectType.STORED_OBJ_MARKET_LIST,
"markets", serverID, "market_data.bin");
if (storable==null)
return null;
marketList = MarketList.ot_dynamic_cast(storable);
}</pre>
Once you have the market list, here is some sample Java code to read the details of an individual market from that list:

<pre class="Java">public static Object getMarketDetails(String marketID)
{
MarketList marketList = Utility.getMarketList();

if (marketList == null)
{
return null;
}

for (int i=0; i < marketList.GetMarketDataCount(); i++)
{
MarketData marketData = marketList.GetMarketData(i);

if (marketData == null)
continue;

String [] row = new String[2];

if (marketID.equals(marketData.getMarket_id()))
{
String[] data = new String[2];
marketData.getLast_sale_price();
marketData.getCurrent_ask();

// Etc!! This is where you get the market details.
}
}

// return custom object here (row/data or whatever), or null if failure..
return null;
}
</pre>
<code>OT_API_getMarketOffers</code> retrieves publicly-available info for all offers on a specific market, up until maximum depth, and saves the data here: <code>markets/SERVER_ID/offers/MARKET_ID.bin</code>

(See testwallet/OTAPI.i for ALL DATA OBJECTS that are used in local storage, including market offers, recent trades, etc. See the code above for a sample on how those data objects are used.)

<code>OT_API_getMarketRecentTrades</code>: Retrieves all recent trades on a market (up until maximum depth), and stores them here: <code>markets/SERVER_ID/recent/MARKET_ID.bin</code>

To retrieve the offers that a specific Nym has out on the market, use: <code>OT_API_getNym_MarketOffers</code> This ''getNym''MarketOffers_ data is ''private'' and thus a lot more detailed than what's retrieved via <code>OT_API_Market_GetOffers</code>, which is more meant for public use. After a successful retrieval, you can load the data from this location: <code>nyms/SERVER_ID/offers/NYM_ID.bin</code>

If you want to see the Nym's private list of his '''completed trades''', the path to load it from is here: <code>nyms/trades/SERVER_ID/NYM_ID</code> There is no need to send a server message in this last case--just read the data from local storage directly. (When market trading receipts are accepted and cleared out of your inbox, this is where they will go. So there's no need to download them, since they were already downloaded through your inbox previously.) As before, the appropriate data object can be found in testwallet/OTAPI.i along with all the others.

-----

I will be very responsive to developer needs and questions regarding the OT API, so I encourage you to play with the software and contact me anytime.

See also:<br>
[[API|The OT low-level API]]<br>
[[Install|Installation]] <br>
[https://github.com/FellowTraveler/Open-Transactions/wiki/opentxs opentxs command-line tool]

[[List of Classes|The OT C++ class library]]

''Diagrams:'' '''[http://billstclair.com/ot/ot-diagram.jpg Architecture Overview]''', '''[http://billstclair.com/ot/OT-Anon-CashOnly.jpg Fully-Anonymous]''' (cash only), and '''[http://billstclair.com/ot/OT-Pseudonym-Instruments.jpg Pseudo-Anonymous]''' (using accounts).

Use Cases

2015-07-08T22:46:15Z

FellowTraveler: updated a bit

* With that as your guide, a general rule of thumb is this: Anytime you need to do something, use the high-level API to do it (OT_ME.) Only if you can't find the function you are looking for, should you next resort to the low-level API (OTAPI.) And remember, you can always the copy the code you need from the test GUI, [http://github.com/Open-Transactions/Moneychanger Moneychanger].

'''What does this mean for you? It means you no longer have to worry about synchronizing request numbers, or harvesting transaction numbers, or comparing inbox hashes, or downloading your nymbox, or dropped messages, or timeouts, or retries, etc!''' Instead, you use simple functions like '''send_transfer''' or '''withdraw_cash.''' The high-level API manages everything else behind the scenes. And any sample code you need can be copied right out of Moneychanger's code.

-----

NOTE: The below notes are old, but preserved for usefulness.

-----

'''USE CASES for the OT API, described on this page:'''

* '''(Client software starts up.)''' Initialize the library and load the wallet.
* Display for user: '''Server Contracts, Nyms, Accounts, and Asset Types.'''
* Change the wallet's ''display label'' for any server, asset type, account, or nym.
* Import a server contract (or asset contract) to the wallet.
* Create a new '''Pseudonym''' (public/private key pair).
* Register a public key (a ''"Nym"'') at an OT server.
* '''Issue a new digital Asset Type'''. (Uploading an asset contract.)
* Retrieve Currency Contract (by ID).
* '''Create a new Asset Account'''.
* '''Write a cheque''' (or invoice)
* '''Send a Message''' to another user (via the server, encrypted to the recipient's public key.)
* '''Deposit a cheque'''
* '''Withdraw cash''' . . . . <==== CHAUMIAN DIGITAL CASH!!
* '''Deposit cash'''
* Withdraw Voucher
* '''Account-to-Account Transfer'''
* Create a new '''Basket Currency'''
* '''Exchange''' Digital Assets '''in and out of Baskets''' (from your Asset Accounts)
* '''Process your Inbox''' (Receipts and pending transfers)
* Set up a '''Payment Plan'''
* Issue a '''Market Offer'''

-----

'''USE CASES for the OT API'''

'''Initialize the library and Load your Wallet'''
(The user starts up the wallet software.)
Call <code>OT_API_Init()</code> Then call <code>OT_API_LoadWallet()</code>

(NOTE: these above 2 steps are not necessary in OT-script, only Java and other languages.)

'''Display the current list of server contracts on the screen''' Call <code>OT_API_GetServerCount()</code>, which returns the number of server contracts in your wallet. For each one, call <code>OT_API_GetServer_ID()</code> to get the Server ID (which is a hash of the contract.) Also for each, call <code>OT_API_GetServer_Name()</code> to get the Display Name from the contract. In your GUI, display the name on the screen, but use the ID behind the scenes (for your messages to the server.)

'''Do the same thing for Nyms, Accounts, and Asset Types.''' You can read about them on the [[API]] page, but here are the basic functions:

OT_API_GetNymCount(void);
OT_API_GetServerCount(void);
OT_API_GetAssetTypeCount(void);
OT_API_GetAccountCount(void);

OT_API_GetNym_ID() and OT_API_GetNym_Name()
OT_API_GetServer_ID() and OT_API_GetServer_Name()
OT_API_GetAssetType_ID() and OT_API_GetAssetType_Name()
OT_API_GetAccountWallet_ID() and OT_API_GetAccountWallet_Name()
Also:
OT_API_GetAccountWallet_Balance()
OT_API_GetAccountWallet_Type()
OT_API_GetAccountWallet_AssetTypeID()

'''Add a new server contract (or asset contract) to the wallet''' Call <code>OT_API_AddServerContract()</code>
or <code>OT_API_AddAssetContract()</code>.

'''Create a new Pseudonym''' (Each user's wallet may contain many pseudonyms. Each Nym consists of a public and a private key, aka a "key pair".) Call <code>OT_API_CreateNym()</code> This creates a new key pair ''("Nym")'' in your wallet, which you can use for communications with an OT server. (That is, for opening asset accounts and performing various other transactions. A Nym is a "user account".) (You can create as many of these pseudonyms as you want.) (You can register the same nyms at multiple servers.) (The same Nym will have the same Nym ID and public key on every server.)

Example

<pre>def details_create_nym(nKeybits, strName)
{
var madeEasy = OT_ME()
var strNymID = madeEasy.create_pseudonym(nKeybits, "", "") // returns new Nym ID

if (!VerifyStringVal(strNymID))
{
OT_API_Output(0, "details_create_nym: Failed in OT_ME::create_pseudonym(keybits == " + nKeybits.to_string() + ")\n")
return (0)
}
OT_API_Output(0, "Success creating! " + nKeybits.to_string() + " keybits, new ID: ") // stderr
print(strNymID) // stdout
OT_API_Output(0, "\n") //stderr
// -------------------
var bSetName = OT_API_SetNym_Name(strNymID, // subject
strNymID, // signer
strName)
if (!bSetName)
{
OT_API_Output(0, "Failed in OT_API_SetNym_Name(name == " + strName + ")\n")
return (0)
}
// -------------------
OT_API_Output(0, "Success setting name to: " + strName + "\n\n") // stderr
return 1
}</pre>
'''Register a public key (aka "Nym") at an OT server'''

<pre> var madeEasy = OT_ME()
if (VerifyExists("Server") && VerifyExists("MyNym"))
{
var strResponse = madeEasy.register_nym(Server, MyNym)
var nSuccess = VerifyMessageSuccess(strResponse)
switch(nSuccess)
{
case (1)
{
OT_API_Output(0, "\n\n SUCCESS in register_nym! Server response:\n\n");
print(strResponse) // stdout
break
}
default
{
OT_API_Output(0, "\n\n Failure or Error in register_nym!\n")

if (VerifyStringVal(strResponse))
{
OT_API_Output(0, "Server response:\n\n");
print(strResponse) // stdout
}
break
}
}</pre>
'''Change the wallet's label for any server/asset type/account/nym'''<br>
(This is only a client-side label, for display purposes only.)<br>
<code>OT_API_SetNym_Name()</code><br>
<code>OT_API_SetAccountWallet_Name()</code> <br>
<code>OT_API_SetAssetType_Name()</code> <br>
<code>OT_API_SetServer_Name()</code><br>

-----

'''Issue a new digital Asset Type''' User uploads a new currency contract to the server, so users can create asset accounts based on that asset type. Server replies with a new issuer account ID (The new Issuer account appears inside your wallet's account list, so go ahead and iterate the list again, in order to display the updated list of accounts on the screen.)

High-level API version (in OT script):

<pre>
var madeEasy = OT_ME()
OT_API_Output(0, "Please paste a currency contract, followed by an EOF or a ~ by itself on a blank line:\n\n")
var strContract = OT_CLI_ReadUntilEOF()
var strResponse = madeEasy.issue_asset_type(Server, MyNym, strContract)
var nStatus = VerifyMessageSuccess(strResponse)

switch(nStatus)
{
case (1)
{
OT_API_Output(0, "\n\n SUCCESS in issue_asset! Server response:\n\n");
print(strResponse) // stdout
break
}
default
{
OT_API_Output(0, "\n\n Failure or error in issue_asset. nStatus: "+nStatus.to_string()+"\n")
if (VerifyStringVal(strResponse))
{
OT_API_Output(0, "Server response:\n\n");
print(strResponse) // stdout
}
break
}
}</pre>
'''Retrieve Currency Contract (by ID)''' User wants to download a currency contract from the server (for a given asset type ID.) (The asset type ID is a hash of the contract, so OT will know if you get the wrong one, since this is verified whenever a contract is loaded up.)

High-level API version (in OT script):

<pre> var madeEasy = OT_ME()
var strRetrieved = madeEasy.retrieve_contract(Server, MyNym, strContractID)
var nRetrieved = VerifyMessageSuccess(strRetrieved)
var strSuccess = "ERROR"
if (1 == nRetrieved)
{ strSuccess = "SUCCESS" }
else if (0 == nRetrieved)
{ strSuccess = "FAILED" }
OT_API_Output(0, "\n\n " + strSuccess + " retrieving contract: "+strContractID+"\n\n")</pre>

'''Create a new Asset Account''' Example in OT Script, from the [https://github.com/FellowTraveler/Open-Transactions/tree/master/scripts/samples sample scripts] folder:

<pre>
def OT_ME::create_asset_acct(SERVER_ID, NYM_ID, ASSET_TYPE_ID)
{
var ot_Msg := OTAPI_Func()
// -------------------------
var theRequest := OTAPI_Func(ot_Msg.CREATE_ASSET_ACCT, SERVER_ID, NYM_ID, ASSET_TYPE_ID)
var strResponse = theRequest.SendRequest(theRequest, "CREATE_ASSET_ACCT")

return strResponse
}
</pre>

If it was a SUCCESS, then refresh the list of accounts in your display (from the OT API) since your new asset account should now be there.

(You can also use the "decode" command in the test wallet anytime you want to base64-decode something.)

-----

'''TRANSACTIONS'''

FYI: Balance agreement, combined with transaction numbers, is what makes it possible for the server and all other parties to ''eliminate account history, instead storing only the last signed receipt.'' (Of course they have the ''choice'' to keep their own records--but they are no longer ''forced'' to do so.)

In order to do any transaction, the wallet's ''balance agreement'' process requires that you have the latest copy of your account, inbox, and outbox files. You don't have to worry about this too much, since the high-level API will usually handle it for you.

'''You might ask: "But what if I download my account, or my outbox, and the server has maliciously inserted data into them?"''' ''No problem'' -- Open Transactions stores the last signed receipt from the server, and is able to verify the new intermediary files against that last receipt. You can see this happening when you run the command-line test client, and receipts can be verified programmatically using <code>OT_API_VerifyAccountReceipt()</code>.

The [[Triple Signed Receipts]] on Open Transactions ensure that this sort of protection is available to all parties, '''while simultaneously not having to store any transaction history!'''

-----

'''Write a Cheque''' Alice writes a cheque (offline): Call <code>OT_API_WriteCheque()</code> Alice then gives cheque to Bob (offline), ''or'' online if she prefers via <code>OT_API_sendUserMessage()</code> function. If Alice has Bob's UserID but not his public key, her wallet first uses <code>OT_API_checkUser()</code> to retrieve his public key from the server, and then encrypts the cheque before sending it.

NOTE: a quality wallet software will keep track of ALL instruments! Even when Alice gives a cheque to Bob, her wallet should still store a copy of that cheque. Until when? Until at least after he has cashed it... when he does that, a chequeReceipt will appear in her inbox. Only when she accepts that receipt, signing a new balance agreement, is she finally free of the transaction number that was on that cheque. (It was still signed-out to her, all the way up until that time.)

WHAT IF Bob had never cashed it? WHAT IF he lost it? Is Alice supposed to just keep signing for that number forever? (The chequeReceipt will never appear in her inbox. She is doomed to continue signing for this number on all of her receipts on into the future, ad infinitum, with no hope of ever closing it out!)

Fear not, there is a solution: <code>OT_API_DiscardCheque()</code>. (Lucky you saved a copy of that cheque in your wallet, eh?) This function will retrieve Alice's transaction # back from the cheque, so that her wallet is free to use it on her next valid transaction, and then close it out normally.

'''Deposit a cheque''' (A voucher is also a cheque, so you may deposit a voucher here the same as any other cheque.) Bob sends message to server requesting deposit:

'''(High level API version, in Java.)'''

<pre>
public boolean depositCheque(String serverID, String nymID, String accountID, String cheque) {

System.out.println("In depositCheque serverID:" + serverID + " nymID:" + nymID + " acount ID:" + accountID);

// ---------------------------------------------------
OTAPI_Func theRequest = new OTAPI_Func(OTAPI_Func.FT.DEPOSIT_CHEQUE, serverID, nymID, accountID, cheque);
String strResponse = OTAPI_Func.SendTransaction(theRequest, "DEPOSIT_CHEQUE"); // <========================

if (null == strResponse) {
System.out.println("OTAPI_Func.SendTransaction() failed, in depositCheque.");
return false;
}
// --------------------------------------------------------------------------------------

return true;
}
</pre>

'''Withdraw cash''' Alice's wallet first makes sure she has the latest public mint file, by calling <code>OT_API_getMint()</code>. (Note: if the mint she already has is within its valid date range, there's no need to do this.) (Note: If she does call getMint, Alice needs to check the server reply and make sure it was successful before continuing with the withdrawal. The public mint keys are necessary for cash withdrawal.) Alice then withdraws from her asset account, by messaging server: <code>OT_API_notarizeWithdrawal()</code> Server replies with chaumian cash, which is stored in the purse folder in local storage.

Here is the full Java implementation of Withdraw Cash:

<pre>
public boolean withdrawCash(String serverID, String nymID, String accountID, String amount)
{
String serverResponseMessage = null;
System.out.println("In withdrawCash serverID:" + serverID + " nymID:" + nymID + " acount ID:" + accountID);
String assetID = otapi.OT_API_GetAccountWallet_AssetTypeID(accountID);

// ----------------------------------------
// Make sure we have the proper asset contract for the withdrawal.
//
String assetContract = otapi.OT_API_LoadAssetContract(assetID);
if (assetContract == null) {
OTAPI_Func theRequest = new OTAPI_Func(OTAPI_Func.FT.GET_CONTRACT, serverID, nymID, assetID);
String strResponse = OTAPI_Func.SendRequest(theRequest, "GET_CONTRACT");

if (null == strResponse) {
System.out.println("IN withdrawCash: OTAPI_Func.SendRequest(GET_CONTRACT) failed. (I give up.) (Unable to find asset contract.)");
return false;
}
// ----------------------------------------
assetContract = otapi.OT_API_LoadAssetContract(assetID);
if (assetContract == null) {
System.out.println("OT_API_LoadAssetContract returned null even after OT_API_getContract (Unable to find asset contract.)");
return false;
}
}
// ---------------------------------------------------------
// Download the public mintfile if it's not there, or if it's expired.
// Also load it up into memory as a string (just to make sure it works.)
// Then we can actually send the withdrawal transaction request. (Until
// then, why bother?)
//
String mintFile;

// expired or missing.
if (1 != otapi.OT_API_Mint_IsStillGood(serverID, assetID))
{
// ----------------------------------------
OTAPI_Func theRequest = new OTAPI_Func(OTAPI_Func.FT.GET_MINT, serverID, nymID, assetID);
String strResponse = OTAPI_Func.SendRequest(theRequest, "GET_MINT");

if (null == strResponse) {
System.out.println("IN withdrawCash: OTAPI_Func.SendRequest(GET_MINT) failed. (I give up.) (Unable to get mint.)");
return false;
}
// ----------------------------------------
mintFile = otapi.OT_API_LoadMint(serverID, assetID);
if (mintFile == null) {
System.out.println("OT_API_LoadMint returned null even after OT_API_getMint (I give up.) (Unable to find mint.)");
return false;
}
}
else // current mint IS available already on local storage (and not expired.)
{
mintFile = otapi.OT_API_LoadMint(serverID, assetID);
if (mintFile == null) {
System.out.println("OT_API_LoadMint returned null even after successful OT_API_Mint_IsStillGood (I give up.) (Unable to find mint.)");
return false;
}
}
// ---------------------------------------------------
// By this point, the mintfile is DEFINITELY good (available, not null,
// not expired, and loaded up.) Now we know for a fact that when the API
// call is made to withdraw cash, that it will find the mint properly.
//
OTAPI_Func theRequest = new OTAPI_Func(OTAPI_Func.FT.WITHDRAW_CASH, serverID, nymID, accountID, amount);
String strResponse = OTAPI_Func.SendTransaction(theRequest, "WITHDRAW_CASH"); // <========================

if (null == strResponse) {
System.out.println("OTAPI_Func.SendTransaction() failed, in withdrawCash.");
return false;
}
// --------------------------------------------------------------------------------------

return true;
}
</pre>

'''Deposit cash''' Here is the complete Java implementation for Deposit Cash:

<pre>
public boolean depositCash(String serverID, String nymID, String accountID, String purse, boolean isToken) {

System.out.println("In depositCash serverID:" + serverID + " nymID:" + nymID + " acount ID:" + accountID + " isToken:" + isToken);
Utility.setOtDepositCash(null);
String oldPurse = purse;
if (isToken) {
purse = getNewPurse(purse, serverID, nymID, accountID);
System.out.println("purse after getting from push purse:" + purse);
if (purse == null) {
Utility.setOtDepositCash(oldPurse);
return false;
}
}
// ----------------------------------------
OTAPI_Func theRequest = new OTAPI_Func(OTAPI_Func.FT.DEPOSIT_CASH, serverID, nymID, accountID, purse);
String strResponse = OTAPI_Func.SendTransaction(theRequest, "DEPOSIT_CASH"); // <========================

if (null == strResponse) {
System.out.println("IN depositCash: OTAPI_Func.SendTransaction(() failed. (I give up.) ");

if (isToken) {
System.out.println("IN depositCash, failed action for single token");
String assetID = otapi.OT_API_GetAccountWallet_AssetTypeID(accountID);
boolean importStatus = otapi.OT_API_Wallet_ImportPurse(serverID, assetID, nymID, purse) == 1 ? true : false;
System.out.println("Since failure of depositCashPurse, OT_API_Wallet_ImportPurse called, status of import:" + importStatus);
if (!importStatus) {
Utility.setOtDepositCash(purse);
}
}

return false;
}
// ----------------------------------------
return true;
}
</pre>

-----

Note about local storage: Usually whenever something important is downloaded from the server, the OT API will save it automatically to the default storage context, and you can then load it up using another API call. This is usually the most convenient way to do things.

-----

'''Account-to-Account Transfer''' A ''pending transfer'' will go into your outbox, and the recipient's inbox, pending acceptance by the recipient. FYI, every asset account has its own inbox and outbox for handling pending transactions, as well as receipts. FYI, every Nym similarly has its own Nymbox, used for receiving messages from other users, and for receiving new transaction numbers from the server.

Here is the OT Script implementation of Send Transfer, from the [https://github.com/FellowTraveler/Open-Transactions/tree/master/scripts/samples sample scripts] folder:

<pre>
def OT_ME::send_transfer(SERVER_ID, NYM_ID, ACCT_FROM, ACCT_TO, AMOUNT, NOTE)
{
var ot_Msg := OTAPI_Func()
// -------------------------
var theRequest := OTAPI_Func(ot_Msg.SEND_TRANSFER, SERVER_ID, NYM_ID, ACCT_FROM, ACCT_TO, AMOUNT, NOTE)
var strResponse = theRequest.SendTransaction(theRequest, "SEND_TRANSFER")

return strResponse
}
</pre>

'''Withdraw Voucher''' A voucher is like a "money order" or "cashier's cheque". It's a cheque, but drawn on a server account, instead of your own account. Withdrawing in voucher form is similar to withdrawing in cash: the server debits your asset account, and then gives you an official cheque.

But with cash, it's automatically saved to your purse, whereas with a voucher, you have to read the voucher out of the server reply, and display it on the screen!

Here is the complete Java code to perform Withdraw Voucher:

<pre>
public String withdrawVoucher(String serverID, String nymID, String accountID, String amount, String chequeMemo, String recepientNymID) {

System.out.println("In withdrawVoucher serverID:" + serverID + " nymID:" + nymID + " acount ID:" + accountID);

// ---------------------------------------------------
OTAPI_Func theRequest = new OTAPI_Func(OTAPI_Func.FT.WITHDRAW_VOUCHER, serverID, nymID, accountID, recepientNymID, chequeMemo, amount);
String strResponse = OTAPI_Func.SendTransaction(theRequest, "WITHDRAW_VOUCHER"); // <========================

if (null == strResponse) {
System.out.println("OTAPI_Func.SendTransaction() failed, in withdrawVoucher.");
return null;
}
// ---------------------------------------------------------
String ledger = otapi.OT_API_Message_GetLedger(strResponse);
if (ledger == null) {
System.out.println(" ledger is null, returned by OT_API_Message_GetLedger, serverResponseMessage passed as argument");
return null;
}
String transaction = otapi.OT_API_Ledger_GetTransactionByIndex(serverID, nymID, accountID, ledger, 0);
if (transaction == null) {
System.out.println("withdrawVoucher: transaction is null, returned by OT_API_Ledger_GetTransactionByIndex, argument passed, index 0 and ledger :" + ledger);
return null;
}
// ---------------------------------------------------------
String output = otapi.OT_API_Transaction_GetVoucher(serverID, nymID, accountID, transaction);
System.out.println("output returned by OT_API_Transaction_GetVoucher:" + output);

return output;
}
</pre>

-----

'''BASKET CURRENCIES'''

'''Create a new Basket Currency''' First, invent the basket in your head. Give it name: ''"Clams."''
Next, give it a ratio in terms of other existing currencies: ''"10 Clams equals a basket of 5 dollars, 3 Euro, and 20 Bitcoin".'' Call <code>OT_API_GenerateBasketCreation()</code> to begin creating the basket. The ''"10 Clams"'' from above is set here. Next, call <code>OT_API_AddBasketCreationItem()</code> for EACH currency in the basket. In the above example, I would call this function 3 times, in order to set the ''"5 dollars"'' the ''"3 Euro"'' and the ''"20 Bitcoin"'' from above. Now that the basket has been defined, call <code>OT_API_issueBasket()</code> to actually create the basket currency on the server. (Now you have created a new asset type--a basket--which the server will control. Any user may now create accounts using this type! And from there, they can write cheques, withdraw cash, trade on markets, etc. the same as with any other asset type.)

'''Exchange Digital Assets in/out of a Basket Currency (from your Asset Accounts)''' First, call <code>OT_API_GenerateBasketExchange()</code> to setup the exchange. You'll need to know the basket's asset type, and you'll need to have an existing asset account of that type. You will also set the "transfer multiple" in that call. What's the transfer multiple? Remember the ratio above: "10 Clams equals a basket of 5 dollars, 3 Euro, and 20 Bitcoin"

Here are examples of the transfer multiple: <br>
"10 Clams == 5 USD, 3 EUR, 20 BIT" (Transfer multiple: 1) <br>
"20 Clams == 10 USD, 6 EUR, 40 BIT" (Transfer multiple: 2) <br>
"30 Clams == 15 USD, 9 EUR, 60 BIT" (Transfer multiple: 3) <br>
"40 Clams == 20 USD, 12 EUR, 80 BIT" (Transfer multiple: 4) <br>
"50 Clams == 25 USD, 15 EUR, 100 BIT" (Transfer multiple: 5)<br>

Next, call <code>OT_API_AddBasketExchangeItem()</code> for each currency type in the basket. You will need to to pass the asset account ID for an existing asset account, for each currency type (since you are converting in or out, from your basket account, to your asset accounts.) Therefore you will call this function once for USD, once for EUR, and once for BIT, in that example, passing in your USD asset acct ID, your EUR asset acct ID, and your Bitcoin asset account ID.

Now that it's all set up, call <code>OT_API_exchangeBasket()</code> to actually message the server and perform the exchange.

'''Interesting: basket currencies themselves require no more additional system resources than normal currencies!''' The magic happens during the exchange process. The server simply stores internal asset accounts for the dollars, euros, and bitcoins (say), and it manages the issuer account for the basket, and it also manages the exchanging in and out, by moving digital assets in or out of the internal backing accounts. After that point, a basket is just another Asset Type ID, and requires no additional resources. You can even have baskets made up of other baskets, nested 10 times, and it won't affect the speed of operation of the server!

-----

'''PROCESSING YOUR INBOX'''

'''Process the Receipts and Pending Transfers in your Inbox''' <br>
If you wish, call <code>OT_API_getInbox()</code> to grab the latest inbox from the server. In the high-level API, this is often just automated for you, but nevertheless, check out the dl_acct_files.ot script. See also show_inbox.ot, etc.

During this time, your user has the opportunity to peruse the inbox, and to decide which transactions therein he wishes to accept or reject. Usually the inbox is display on the screen, then the user selects various items to accept or reject, and then the user clicks "Process Inbox" and then you do this:

Then call <code>OT_API_Ledger_CreateResponse()</code> in order to create a 'response' ledger for that inbox, which will be sent to the server to signal your responses to the various inbox transactions. <br>Then call <code>OT_API_Ledger_GetCount()</code> (pass it the inbox) to find out how many transactions are inside of it. Use that count to LOOP through them...
<br>Use <code>OT_API_Ledger_GetTransactionByIndex()</code> to grab each transaction as you iterate through the inbox. (There are various introspection functions you can use in the API here if you wish to display the inbox items on the screen for the user...)
<br>Next call <code>OT_API_Transaction_CreateResponse()</code> for each transaction in the inbox, to create a response to it, accepting or rejecting it. This function creates the response and adds it to the response ledger.
<br>Next, call <code>OT_API_Ledger_FinalizeResponse()</code> which will create a ''Balance Agreement'' for the ledger.
<br>Finally, call <code>OT_API_processInbox()</code> to send your message to the server and process the various items. (See the accept_inbox.ot script.)

If the message was successful, then use <code>OT_API_Message_GetBalanceAgreementSuccess()</code> and <code>OT_API_Message_GetTransactionSuccess()</code> to see just ''how'' successful.

-----

'''MARKETS and PAYMENT PLANS'''

'''Setup a Payment Plan''' The Merchant draws up the Payment Plan using <code>OT_API_ProposePaymentPlan</code> Then he sends it to the Customer, who calls <code>OT_API_ConfirmPaymentPlan</code> The Customer's wallet activates the payment plan by sending it to the server using this function: <code>OT_API_depositPaymentPlan()</code> (Receipts will process into the respective parties' inboxes.) Use OT_API_cancelCronItem() to cancel any payment plan (or market offer.)

If the message was successful, then use <code>OT_API_Message_GetBalanceAgreementSuccess()</code> and <code>OT_API_Message_GetTransactionSuccess()</code> as described above in the ''deposit cash'' instructions.

'''Issue a [[Markets|Market]] Offer'''

Call this function: <code>OT_API_issueMarketOffer()</code><br>
(That's the low-level one. See create_offer.ot script for the high-level version.)<br>
Call <code>OT_API_Message_GetSuccess</code> to find out if the message was a SUCCESS or FAILURE.<br>
If the message was successful, then use <code>OT_API_Message_GetBalanceAgreementSuccess()</code> and <code>OT_API_Message_GetTransactionSuccess()</code> as described above in the ''deposit cash'' instructions.<br>
See the OTScript and Java versions of these calls.

Once an offer goes onto the market, multiple trades may occur between it and the other offers on the market. (According to the rules in the offers.) Receipts will process into the respective parties' inboxes after each trade.

'''Cancel a Market Offer''' Use <code>OT_API_cancelNymMarketOffer</code> to remove an offer from a market. If the message was successful, then use <code>OT_API_Message_GetBalanceAgreementSuccess()</code> and <code>OT_API_Message_GetTransactionSuccess()</code>

'''Retrieving Market Data from OT Server:''' <code>OT_API_getMarketList</code> retrieves a list of all the markets available on a specific server, and details for each market. If the server call is a success, the data will be retrieved from the OT server, and written to local storage using the OT Storage API, at this path or key (inside your data_folder location): <code>markets/SERVER_ID/market_data.bin</code> <br>
If you want to verify whether the data is now available in local storage (after a successful call to getMarketList), your code would look like this: <br>
<code>if (otapi.Exists("markets", serverID, "market_data.bin")) bFoundFile = true;</code>

Here is some Java code that reads the market list object from local storage, assuming bFoundFile is true:

<pre class="Java"> MarketList marketList = null;
Storable storable = null;

if (otapi.Exists("markets", serverID, "market_data.bin"))
{
storable =
otapi.QueryObject(StoredObjectType.STORED_OBJ_MARKET_LIST,
"markets", serverID, "market_data.bin");
if (storable==null)
return null;
marketList = MarketList.ot_dynamic_cast(storable);
}</pre>
Once you have the market list, here is some sample Java code to read the details of an individual market from that list:

<pre class="Java">public static Object getMarketDetails(String marketID)
{
MarketList marketList = Utility.getMarketList();

if (marketList == null)
{
return null;
}

for (int i=0; i < marketList.GetMarketDataCount(); i++)
{
MarketData marketData = marketList.GetMarketData(i);

if (marketData == null)
continue;

String [] row = new String[2];

if (marketID.equals(marketData.getMarket_id()))
{
String[] data = new String[2];
marketData.getLast_sale_price();
marketData.getCurrent_ask();

// Etc!! This is where you get the market details.
}
}

// return custom object here (row/data or whatever), or null if failure..
return null;
}
</pre>
<code>OT_API_getMarketOffers</code> retrieves publicly-available info for all offers on a specific market, up until maximum depth, and saves the data here: <code>markets/SERVER_ID/offers/MARKET_ID.bin</code>

(See testwallet/OTAPI.i for ALL DATA OBJECTS that are used in local storage, including market offers, recent trades, etc. See the code above for a sample on how those data objects are used.)

<code>OT_API_getMarketRecentTrades</code>: Retrieves all recent trades on a market (up until maximum depth), and stores them here: <code>markets/SERVER_ID/recent/MARKET_ID.bin</code>

To retrieve the offers that a specific Nym has out on the market, use: <code>OT_API_getNym_MarketOffers</code> This ''getNym''MarketOffers_ data is ''private'' and thus a lot more detailed than what's retrieved via <code>OT_API_Market_GetOffers</code>, which is more meant for public use. After a successful retrieval, you can load the data from this location: <code>nyms/SERVER_ID/offers/NYM_ID.bin</code>

If you want to see the Nym's private list of his '''completed trades''', the path to load it from is here: <code>nyms/trades/SERVER_ID/NYM_ID</code> There is no need to send a server message in this last case--just read the data from local storage directly. (When market trading receipts are accepted and cleared out of your inbox, this is where they will go. So there's no need to download them, since they were already downloaded through your inbox previously.) As before, the appropriate data object can be found in testwallet/OTAPI.i along with all the others.

-----

I will be very responsive to developer needs and questions regarding the OT API, so I encourage you to play with the software and contact me anytime.

See also:<br>
[[API|The OT low-level API]]<br>
[[Install|Installation]] <br>
[https://github.com/FellowTraveler/Open-Transactions/wiki/opentxs opentxs command-line tool]

[[List of Classes|The OT C++ class library]]

''Diagrams:'' '''[http://billstclair.com/ot/ot-diagram.jpg Architecture Overview]''', '''[http://billstclair.com/ot/OT-Anon-CashOnly.jpg Fully-Anonymous]''' (cash only), and '''[http://billstclair.com/ot/OT-Pseudonym-Instruments.jpg Pseudo-Anonymous]''' (using accounts).

Components and GNU Licensing

2015-07-08T22:39:51Z

FellowTraveler: added consortia

Open-Transactions is available under the '''[https://www.mozilla.org/MPL/2.0/ MPLv2 license.]''' The main components of Open-Transactions are the core library, the client API, the 'opentxs' command-line tool, the opentxs-notary server, and the Moneychanger GUI desktop application.

RELAXATION IN LICENSING: In 2015, the Open-Transactions licensing relaxed from AGPLv3 to MPLv2. What was our rationale for the change?

First, MPLv2 is much more business-friendly than GPL. For example, you can use MPL'd code files inside proprietary software projects. And importantly, you can also use MPL'd code to build apps for the Apple App Store and the Google Play Store. (This is important for making OT available on mobile devices.)

Importantly, MPLv2 is still a copyleft license, similar to GPL. The license terms mandate that improvements made to the OT source code itself ''must'' be released back to the open-source community under the MPLv2 license. This ensures that the open-source community will continue to benefit from any improvements made to OT by commercial entities.

The MPLv2 license is fully-compatible with GPLv3, as well as with BSD/MIT licenses and proprietary licenses. This means OT can be utilized in any software project, including any commercial project, without fear of legal repercussions.

The OT code base has many different contributors, and so the open-source community will never have to worry about a single copyright-holder trying to regain control over how it is used.

-----

Links:
<br>[http://www.fsf.org/ Free Software Movement].

Copyleft licenses create a [http://www.dwheeler.com/blog/2006/09/01/#gpl-bsd protective legal buffer zone] so that a long-term community can build around the software, safely contributing to it in a consortia-like arrangement, to the benefit of all, even amongst a large group of business competitors (see Linux, for example.) Copyleft licenses create an incentive for separate entities to plow money into development of the software, without any fear that their competitors will simply copy the code without reciprocating.

----------

David Wheeler explains why a copyleft license like GPL can benefit a software project, on [http://www.dwheeler.com/blog/2006/09/01/#gpl-bsd his blog:]

'''GPL, BSD, and NetBSD - why the GPL rocketed Linux to success'''

Charles M. Hannum (one of the 4 originators of NetBSD) has posted a sad article about serious problems in the NetBSD project, saying "the NetBSD Project has stagnated to the point of irrelevance." You can see the article or an LWN article about it.

<br>There are still active FreeBSD and OpenBSD communities, and there's much positive to say about FreeBSD and OpenBSD. I use them occasionally, and I always welcome a chance to talk to their developers - they're sharp folks. Perhaps NetBSD will partly revive. But systems based on the Linux kernel ("Linux") absolutely stomp the *BSDs (FreeBSD, OpenBSD, and NetBSD) in market share. And Linux-based systems will continue to stomp on the *BSDs into the foreseeable future.

<br>I think there is one primary reason Linux-based systems completely dominate the *BSDs' market share - Linux uses the protective GPL license, and the *BSDs use the permissive ("BSD-style") licenses. The BSD license has been a lot of trouble for all the *BSDs, even though they keep protesting that it's good for them. But look what happens. Every few years, for many years, someone has said, "Let's start a company based on this BSD code!" BSD/OS in particular comes to mind, but Sun (SunOS) and others have done the same. They pull the *BSD code in, and some of the best BSD developers, and write a proprietary derivative. But as a proprietary vendor, their fork becomes expensive to self-maintain, and eventually the company founders or loses interest in that codebase (BSD/OS is gone; Sun switched to Solaris). All that company work is then lost forever, and good developers were sucked away during that period. Repeat, repeat, repeat. That's enough by itself to explain why the BSDs don't maintain the pace of Linux kernel development. But wait - it gets worse.

<br>In contrast, the GPL has enforced a consortia-like arrangement on any major commercial companies that want to use it. Red Hat, Novell, IBM, and many others are all contributing as a result, and they feel safe in doing so because the others are legally required to do the same. Just look at the domain names on the Linux kernel mailing list - big companies, actively paying for people to contribute. In July 2004, Andrew Morton addressed a forum held by U.S. Senators, and reported that most Linux kernel code was generated by corporate programmers (37,000 of the last 38,000 changes were contributed by those paid by companies to do so; see my report on OSS/FS numbers for more information). BSD license advocates claim that the BSD is more "business friendly", but if you look at actual practice, that argument doesn't wash. The GPL has created a "safe" zone of cooperation among companies, without anyone having to sign complicated legal documents. A company can't feel safe contributing code to the BSDs, because its competitors might simply copy the code without reciprocating. There's much more corporate cooperation in the GPL'ed kernel code than with the BSD'd kernel code. Which means that in practice, it's actually been the GPL that's most "business-friendly".

<br>So while the BSDs have lost energy every time a company gets involved, the GPL'ed programs gain every time a company gets involved. And that explains it all.

<br>That's not the only issue, of course. Linus Torvalds makes mistakes, but in general he's a good leader; leadership issues are clearly an issue for some of the BSDs. And Linux's ability early on to support dual-boot computers turned out to be critical years ago. Some people worried about the legal threats that the BSDs were under early on, though I don't think it had that strong an effect. But the early Linux kernel had a number of problems (nonstandard threads, its early network stack was terrible, etc.), which makes it harder to argue that it was "better" at first. And the Linux kernel came AFTER the *BSDs - the BSDs had a head start, and a lot of really smart people. Yet the Linux kernel, and operating systems based on it, jumped quickly past all of them. I believe that's in large part because Linux didn't suffer the endless draining of people and effort caused by the BSD license.

<br>Clearly, some really excellent projects can work well on BSD-style licenses; witness Apache, for example. It would be a mistake to think that BSD licenses are "bad" licenses, or that the GPL is always the "best" license. But others, like Linux, gcc, etc., have done better with copylefting / "protective" licenses. And some projects, like Wine, have switched to a protective (copylefting) license to stem the tide of loss from the project. Again, it's not as simple as "BSD license bad" - I don't think we fully understand exactly when each license's effects truly have the most effect. But clearly the license matters; this as close to an experiment in competing licenses as you're likely to get.

<br>Obviously, a license choice should depend on your goals. But let's look more carefully at that statement, maybe we can see what type of license tends to be better for different purposes.

<br>If your goal is to get an idea or approach widely used to the largest possible extent, a permissive license like the BSD (or MIT) license has much to offer. Anyone can quickly snap up the code and use it. Much of the TCP/IP code (at least for tools) in Windows was originally from BSD, I believe; there are even some copyright statements still in it. BSD code is widely used, and even when it isn't used (the Linux kernel developers wrote their own TCP/IP code) it is certainly studied. But don't expect the public BSD-licensed code to be maintained by those with a commercial interest in it. I haven't noticed a large number of Microsoft developers being paid to improve any of the *BSDs, even though they share the same code ancestries in some cases.

<br>If your goal is to have a useful program that stays useful long-term, then a protective ("copylefting") license like the LGPL or GPL licenses has much to offer. Protective licenses force the cooperation that is good for everyone in the long term, if a long-term useful project is the goal. For example, I've noticed that GPL projects are far less likely to fork than BSD-licensed projects; the GPL completely eliminates any financial advantage to forking. The power of the GPL license is so strong that even if you choose to not use a copylefting license, it is critically important that an open source software project use a GPL-compatible license.

<br>Yes, companies could voluntarily cooperate without a license forcing them to. The *BSDs try to depend on this. But it today's cutthroat market, that's more like the "Prisoner's Dilemma". In the dilemma, it's better to cooperate; but since the other guy might choose to not cooperate, and exploit your naivete, you may choose to not cooperate. A way out of this dilemma is to create a situation where you must cooperate, and the GPL does that.

<br>Again, I don't think license selection is all that simple when developing a free-libre/open source software (FLOSS) program. Obviously the Apache web server does well with its BSD-ish license. But packages like Linux, gcc, Samba, and so on all show that the GPL does work. And more interestingly, they show that a lot of competing companies can cooperate, when the license requires them to.

Components and GNU Licensing

2015-07-08T22:36:47Z

FellowTraveler: wording

Open-Transactions is available under the '''[https://www.mozilla.org/MPL/2.0/ MPLv2 license.]''' The main components of Open-Transactions are the core library, the client API, the 'opentxs' command-line tool, the opentxs-notary server, and the Moneychanger GUI desktop application.

RELAXATION IN LICENSING: In 2015, the Open-Transactions licensing relaxed from AGPLv3 to MPLv2. What was our rationale for the change?

First, MPLv2 is much more business-friendly than GPL. For example, you can use MPL'd code files inside proprietary software projects. And importantly, you can also use MPL'd code to build apps for the Apple App Store and the Google Play Store. (This is important for making OT available on mobile devices.)

Importantly, MPLv2 is still a copyleft license, similar to GPL. The license terms mandate that improvements made to the OT source code itself ''must'' be released back to the open-source community under the MPLv2 license. This ensures that the open-source community will continue to benefit from any improvements made to OT by commercial entities.

The MPLv2 license is fully-compatible with GPLv3, as well as with BSD/MIT licenses and proprietary licenses. This means OT can be utilized in any software project, including any commercial project, without fear of legal repercussions.

The OT code base has many different contributors, and so the open-source community will never have to worry about a single copyright-holder trying to regain control over how it is used.

-----

Links:
<br>[http://www.fsf.org/ Free Software Movement].

Copyleft licenses create a [http://www.dwheeler.com/blog/2006/09/01/#gpl-bsd protective legal buffer zone] so that a long-term community can build around the software, safely contributing to it, to the benefit of all, even amongst a large group of business competitors (see Linux, for example.) Copyleft licenses create an incentive for separate entities to plow money into development of the software, without any fear that their competitors will simply copy the code without reciprocating.

----------

David Wheeler explains why a copyleft license like GPL can benefit a software project, on [http://www.dwheeler.com/blog/2006/09/01/#gpl-bsd his blog:]

'''GPL, BSD, and NetBSD - why the GPL rocketed Linux to success'''

Charles M. Hannum (one of the 4 originators of NetBSD) has posted a sad article about serious problems in the NetBSD project, saying "the NetBSD Project has stagnated to the point of irrelevance." You can see the article or an LWN article about it.

<br>There are still active FreeBSD and OpenBSD communities, and there's much positive to say about FreeBSD and OpenBSD. I use them occasionally, and I always welcome a chance to talk to their developers - they're sharp folks. Perhaps NetBSD will partly revive. But systems based on the Linux kernel ("Linux") absolutely stomp the *BSDs (FreeBSD, OpenBSD, and NetBSD) in market share. And Linux-based systems will continue to stomp on the *BSDs into the foreseeable future.

<br>I think there is one primary reason Linux-based systems completely dominate the *BSDs' market share - Linux uses the protective GPL license, and the *BSDs use the permissive ("BSD-style") licenses. The BSD license has been a lot of trouble for all the *BSDs, even though they keep protesting that it's good for them. But look what happens. Every few years, for many years, someone has said, "Let's start a company based on this BSD code!" BSD/OS in particular comes to mind, but Sun (SunOS) and others have done the same. They pull the *BSD code in, and some of the best BSD developers, and write a proprietary derivative. But as a proprietary vendor, their fork becomes expensive to self-maintain, and eventually the company founders or loses interest in that codebase (BSD/OS is gone; Sun switched to Solaris). All that company work is then lost forever, and good developers were sucked away during that period. Repeat, repeat, repeat. That's enough by itself to explain why the BSDs don't maintain the pace of Linux kernel development. But wait - it gets worse.

<br>In contrast, the GPL has enforced a consortia-like arrangement on any major commercial companies that want to use it. Red Hat, Novell, IBM, and many others are all contributing as a result, and they feel safe in doing so because the others are legally required to do the same. Just look at the domain names on the Linux kernel mailing list - big companies, actively paying for people to contribute. In July 2004, Andrew Morton addressed a forum held by U.S. Senators, and reported that most Linux kernel code was generated by corporate programmers (37,000 of the last 38,000 changes were contributed by those paid by companies to do so; see my report on OSS/FS numbers for more information). BSD license advocates claim that the BSD is more "business friendly", but if you look at actual practice, that argument doesn't wash. The GPL has created a "safe" zone of cooperation among companies, without anyone having to sign complicated legal documents. A company can't feel safe contributing code to the BSDs, because its competitors might simply copy the code without reciprocating. There's much more corporate cooperation in the GPL'ed kernel code than with the BSD'd kernel code. Which means that in practice, it's actually been the GPL that's most "business-friendly".

<br>So while the BSDs have lost energy every time a company gets involved, the GPL'ed programs gain every time a company gets involved. And that explains it all.

<br>That's not the only issue, of course. Linus Torvalds makes mistakes, but in general he's a good leader; leadership issues are clearly an issue for some of the BSDs. And Linux's ability early on to support dual-boot computers turned out to be critical years ago. Some people worried about the legal threats that the BSDs were under early on, though I don't think it had that strong an effect. But the early Linux kernel had a number of problems (nonstandard threads, its early network stack was terrible, etc.), which makes it harder to argue that it was "better" at first. And the Linux kernel came AFTER the *BSDs - the BSDs had a head start, and a lot of really smart people. Yet the Linux kernel, and operating systems based on it, jumped quickly past all of them. I believe that's in large part because Linux didn't suffer the endless draining of people and effort caused by the BSD license.

<br>Clearly, some really excellent projects can work well on BSD-style licenses; witness Apache, for example. It would be a mistake to think that BSD licenses are "bad" licenses, or that the GPL is always the "best" license. But others, like Linux, gcc, etc., have done better with copylefting / "protective" licenses. And some projects, like Wine, have switched to a protective (copylefting) license to stem the tide of loss from the project. Again, it's not as simple as "BSD license bad" - I don't think we fully understand exactly when each license's effects truly have the most effect. But clearly the license matters; this as close to an experiment in competing licenses as you're likely to get.

<br>Obviously, a license choice should depend on your goals. But let's look more carefully at that statement, maybe we can see what type of license tends to be better for different purposes.

<br>If your goal is to get an idea or approach widely used to the largest possible extent, a permissive license like the BSD (or MIT) license has much to offer. Anyone can quickly snap up the code and use it. Much of the TCP/IP code (at least for tools) in Windows was originally from BSD, I believe; there are even some copyright statements still in it. BSD code is widely used, and even when it isn't used (the Linux kernel developers wrote their own TCP/IP code) it is certainly studied. But don't expect the public BSD-licensed code to be maintained by those with a commercial interest in it. I haven't noticed a large number of Microsoft developers being paid to improve any of the *BSDs, even though they share the same code ancestries in some cases.

<br>If your goal is to have a useful program that stays useful long-term, then a protective ("copylefting") license like the LGPL or GPL licenses has much to offer. Protective licenses force the cooperation that is good for everyone in the long term, if a long-term useful project is the goal. For example, I've noticed that GPL projects are far less likely to fork than BSD-licensed projects; the GPL completely eliminates any financial advantage to forking. The power of the GPL license is so strong that even if you choose to not use a copylefting license, it is critically important that an open source software project use a GPL-compatible license.

<br>Yes, companies could voluntarily cooperate without a license forcing them to. The *BSDs try to depend on this. But it today's cutthroat market, that's more like the "Prisoner's Dilemma". In the dilemma, it's better to cooperate; but since the other guy might choose to not cooperate, and exploit your naivete, you may choose to not cooperate. A way out of this dilemma is to create a situation where you must cooperate, and the GPL does that.

<br>Again, I don't think license selection is all that simple when developing a free-libre/open source software (FLOSS) program. Obviously the Apache web server does well with its BSD-ish license. But packages like Linux, gcc, Samba, and so on all show that the GPL does work. And more interestingly, they show that a lot of competing companies can cooperate, when the license requires them to.

Components and GNU Licensing

2015-07-08T22:35:15Z

FellowTraveler: updated license info to MPLv2

Open-Transactions is available under the '''[https://www.mozilla.org/MPL/2.0/ MPLv2 license.]''' The main components of Open-Transactions are the core library, the client API, the 'opentxs' command-line tool, the opentxs-notary server, and the Moneychanger GUI desktop application.

RELAXATION IN LICENSING: In 2015, the Open-Transactions licensing relaxed from AGPLv3 to MPLv2. What was our rationale for the change?

First, MPLv2 is much more business-friendly than GPL. For example, you can use MPL'd code files inside proprietary software projects. And importantly, you can also use MPL'd code to build apps for the Apple App Store and the Google Play Store. (This is important for making OT available on mobile devices.)

Importantly, MPLv2 is still a copyleft license, similar to GPL. The license terms mandate that improvements made to the OT source code itself ''must'' be released back to the open-source community under the MPLv2 license. This ensures that the open-source community will continue to benefit from any improvements made to OT by commercial entities.

The MPLv2 license is fully-compatible with GPLv3, as well as with BSD/MIT licenses and proprietary licenses. This means OT can be utilized in any software project without fear of legal repercussions.

The OT code base has many different contributors, and so the open-source community will never have to worry about a single copyright-holder trying to regain control over how it is used.

-----

Links:
<br>[http://www.fsf.org/ Free Software Movement].

Copyleft licenses create a [http://www.dwheeler.com/blog/2006/09/01/#gpl-bsd protective legal buffer zone] so that a long-term community can build around the software, safely contributing to it, to the benefit of all, even amongst a large group of business competitors (see Linux, for example.) Copyleft licenses create an incentive for separate entities to plow money into development of the software, without any fear that their competitors will simply copy the code without reciprocating.

----------

David Wheeler explains why a copyleft license like GPL can benefit a software project, on [http://www.dwheeler.com/blog/2006/09/01/#gpl-bsd his blog:]

'''GPL, BSD, and NetBSD - why the GPL rocketed Linux to success'''

Charles M. Hannum (one of the 4 originators of NetBSD) has posted a sad article about serious problems in the NetBSD project, saying "the NetBSD Project has stagnated to the point of irrelevance." You can see the article or an LWN article about it.

<br>There are still active FreeBSD and OpenBSD communities, and there's much positive to say about FreeBSD and OpenBSD. I use them occasionally, and I always welcome a chance to talk to their developers - they're sharp folks. Perhaps NetBSD will partly revive. But systems based on the Linux kernel ("Linux") absolutely stomp the *BSDs (FreeBSD, OpenBSD, and NetBSD) in market share. And Linux-based systems will continue to stomp on the *BSDs into the foreseeable future.

<br>I think there is one primary reason Linux-based systems completely dominate the *BSDs' market share - Linux uses the protective GPL license, and the *BSDs use the permissive ("BSD-style") licenses. The BSD license has been a lot of trouble for all the *BSDs, even though they keep protesting that it's good for them. But look what happens. Every few years, for many years, someone has said, "Let's start a company based on this BSD code!" BSD/OS in particular comes to mind, but Sun (SunOS) and others have done the same. They pull the *BSD code in, and some of the best BSD developers, and write a proprietary derivative. But as a proprietary vendor, their fork becomes expensive to self-maintain, and eventually the company founders or loses interest in that codebase (BSD/OS is gone; Sun switched to Solaris). All that company work is then lost forever, and good developers were sucked away during that period. Repeat, repeat, repeat. That's enough by itself to explain why the BSDs don't maintain the pace of Linux kernel development. But wait - it gets worse.

<br>In contrast, the GPL has enforced a consortia-like arrangement on any major commercial companies that want to use it. Red Hat, Novell, IBM, and many others are all contributing as a result, and they feel safe in doing so because the others are legally required to do the same. Just look at the domain names on the Linux kernel mailing list - big companies, actively paying for people to contribute. In July 2004, Andrew Morton addressed a forum held by U.S. Senators, and reported that most Linux kernel code was generated by corporate programmers (37,000 of the last 38,000 changes were contributed by those paid by companies to do so; see my report on OSS/FS numbers for more information). BSD license advocates claim that the BSD is more "business friendly", but if you look at actual practice, that argument doesn't wash. The GPL has created a "safe" zone of cooperation among companies, without anyone having to sign complicated legal documents. A company can't feel safe contributing code to the BSDs, because its competitors might simply copy the code without reciprocating. There's much more corporate cooperation in the GPL'ed kernel code than with the BSD'd kernel code. Which means that in practice, it's actually been the GPL that's most "business-friendly".

<br>So while the BSDs have lost energy every time a company gets involved, the GPL'ed programs gain every time a company gets involved. And that explains it all.

<br>That's not the only issue, of course. Linus Torvalds makes mistakes, but in general he's a good leader; leadership issues are clearly an issue for some of the BSDs. And Linux's ability early on to support dual-boot computers turned out to be critical years ago. Some people worried about the legal threats that the BSDs were under early on, though I don't think it had that strong an effect. But the early Linux kernel had a number of problems (nonstandard threads, its early network stack was terrible, etc.), which makes it harder to argue that it was "better" at first. And the Linux kernel came AFTER the *BSDs - the BSDs had a head start, and a lot of really smart people. Yet the Linux kernel, and operating systems based on it, jumped quickly past all of them. I believe that's in large part because Linux didn't suffer the endless draining of people and effort caused by the BSD license.

<br>Clearly, some really excellent projects can work well on BSD-style licenses; witness Apache, for example. It would be a mistake to think that BSD licenses are "bad" licenses, or that the GPL is always the "best" license. But others, like Linux, gcc, etc., have done better with copylefting / "protective" licenses. And some projects, like Wine, have switched to a protective (copylefting) license to stem the tide of loss from the project. Again, it's not as simple as "BSD license bad" - I don't think we fully understand exactly when each license's effects truly have the most effect. But clearly the license matters; this as close to an experiment in competing licenses as you're likely to get.

<br>Obviously, a license choice should depend on your goals. But let's look more carefully at that statement, maybe we can see what type of license tends to be better for different purposes.

<br>If your goal is to get an idea or approach widely used to the largest possible extent, a permissive license like the BSD (or MIT) license has much to offer. Anyone can quickly snap up the code and use it. Much of the TCP/IP code (at least for tools) in Windows was originally from BSD, I believe; there are even some copyright statements still in it. BSD code is widely used, and even when it isn't used (the Linux kernel developers wrote their own TCP/IP code) it is certainly studied. But don't expect the public BSD-licensed code to be maintained by those with a commercial interest in it. I haven't noticed a large number of Microsoft developers being paid to improve any of the *BSDs, even though they share the same code ancestries in some cases.

<br>If your goal is to have a useful program that stays useful long-term, then a protective ("copylefting") license like the LGPL or GPL licenses has much to offer. Protective licenses force the cooperation that is good for everyone in the long term, if a long-term useful project is the goal. For example, I've noticed that GPL projects are far less likely to fork than BSD-licensed projects; the GPL completely eliminates any financial advantage to forking. The power of the GPL license is so strong that even if you choose to not use a copylefting license, it is critically important that an open source software project use a GPL-compatible license.

<br>Yes, companies could voluntarily cooperate without a license forcing them to. The *BSDs try to depend on this. But it today's cutthroat market, that's more like the "Prisoner's Dilemma". In the dilemma, it's better to cooperate; but since the other guy might choose to not cooperate, and exploit your naivete, you may choose to not cooperate. A way out of this dilemma is to create a situation where you must cooperate, and the GPL does that.

<br>Again, I don't think license selection is all that simple when developing a free-libre/open source software (FLOSS) program. Obviously the Apache web server does well with its BSD-ish license. But packages like Linux, gcc, Samba, and so on all show that the GPL does work. And more interestingly, they show that a lot of competing companies can cooperate, when the license requires them to.

About

2015-07-08T22:19:36Z

FellowTraveler: /* Diagrams */ added white paper

__NOTOC__
<div class="plainlinks">
{| id="mp-topbanner" style="width:100%; background:#f6f6f6; margin-top:1.2em; border:1px solid #ddd;"
| style="width:61%; color:#000;" |

{| style="width:100%; border:none; background:none;"
| style="text-align:center; white-space:nowrap; color:#000;" |
<div style="font-size:162%; border:none; margin:0; padding:.1em; color:#000;">About the Open-Transactions project.</div>
<div style="top:+0.2em; font-size:95%;">Financial cryptography software.</div>
<div id="articlecount" style="width:100%; text-align:center; font-size:85%;">[[Special:Statistics|{{NUMBEROFARTICLES}}]] [[Special:Allpages|articles]].</div>
|}
|}

<div style="float:left; max-width: 550px;">

<big>'''What is Open-Transactions?'''</big>

* Open-Transactions is an [[Use Cases|easy-to-use]], financial crypto, [[Sample Cash|digital cash]] and transaction [[List of Classes|library]].
* Open-Transactions is open-source.
* Open-Transactions includes a [[API|client API]], a working [[Otserver|server]], a [[TestGUI|GUI test wallet]] (in Java) and a [[opentxs|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, [http://iang.org/papers/ricardian_contract.html Ricardian contracts], Smart Contracts (scriptable clauses), and more.

<big>'''What does it do?'''</big>

* Open-Transactions allows users to issue and manipulate digital assets.
* Any issuer can sign and distribute new [[Sample Currency Contract|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 '''[[Sample Cash|unlinkable digital cash]]'''.

<big>'''Financial Instruments'''</big>
* Users can transfer digital assets ''securely and provably'', with [[Triple-Signed Receipts|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 '''[[Instruments|financial instruments]]''' such as account transfer, '''[[Sample-Cheque|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.

<big>'''Markets, Basket Currencies, and Smart Contracts'''</big>
* Open-Transactions also implements higher-level, '''contract-based transactions''' such as '''payment plans''' and '''markets with trades'''.
* The [[Markets|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]]: <code>!/usr/bin/env ot</code> The entire (mostly) high and low level OT API is available within your scripts.

<big>'''Triple Signed Receipts'''</big>
* 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.

<big>'''Is Open-Transactions [[CENTRALIZED|centralized]]?'''</big>
* No—quite the opposite. Open-Transactions is highly '''decentralized'''.
* Typical centralized servers have power over their users, but in OT, '''no server has power over the clients it serves''', because:
# An OT server does not control user transactions—it merely notarizes them.
# Anyone can operate an OT server, and users can go to any OT server to notarize transactions. Thus OT servers compete with each other to attract users to use their notary services.
# Anyone can download an OT client, and use it to execute transactions on any OT server, or any group of OT servers.
# OT uses triple-signed receipts, so transaction parties have independent cryptographic proof of transactions and balances.
# OT servers do not store user assets. Rather, cryptocurrencies are stored in voting pools so the server can't steal them.

In every way, '''the user is in control, not the server'''—even when you're using servers you do not trust. These characteristics generate a '''federated''' network architecture—similar to the internet, and it has the same virtues as the internet—openness, decentralization, resilience, censorship-resistance, and user control.

The community behind OT is strongly committed to developing systems that give users full control over their own assets and information.

</div>

<div style="float:right; max-width: 300px; margin: -20px 10px 0 20px;">

== White Paper ==

[http://www.opentransactions.org/open-transactions.pdf OT White Paper]

== Diagrams ==

[[Voting_Pool_Deposit_Process|Voting Pools]]

[http://i.imgur.com/HTyAJjg.png Architecture Overview (new)]

[http://billstclair.com/ot/ot-diagram.jpg Architecture Overview (old)]

[http://billstclair.com/ot/OT-Pseudonym-Instruments.jpg Financial Instruments]

== Radio Interviews ==

[https://www.youtube.com/watch?v=teNzIFu5L70 "Trust No One" Miami Speech]

[http://agoristradio.com/?p=234 AgoristRadio Interview, Part 1]

[http://agoristradio.com/?p=246 AgoristRadio Interview, Part 2]

[https://www.youtube.com/watch?v=vtJcUM5-TeA Interview with "Let's Talk Bitcoin"]

[http://www.youtube.com/watch?v=HSgpStCTw2g Interview with FutureMoneyTrends.com]

== Video Walkthrough ==

[https://www.youtube.com/watch?v=5qtTayW-RyM Android demo video (Monetas)]

[http://goo.gl/Ea6rzq Desktop video 1 - Introduction]

[http://goo.gl/i0J3AF Desktop video 2 - Advanced]

[http://goo.gl/8Dxak1 iPhone video 1 - Introduction]

[http://goo.gl/u6xqHc iPhone video 2 - Advanced]

[http://vimeo.com/28141679 java testclient video 1]

[http://vimeo.com/28142096 java testclient video 2]

[http://open-transactions.github.io/tv/ Official video archive (more videos)]

-----

[[Components and GNU Licensing]]

[[Vulnerabilities|Potential vulnerabilities]] of Open-Transactions

== Related Systems ==

[[Monetas]] - Enterprise platform based on OT.

---------

[http://bitcoin.org/ Bitcoin] - A censorship-resistant global ledger

[https://loom.cc/help Loom] - Asset issuance and transactions

[http://www.csee.umbc.edu/~woodcock/cmsc482/proj1/magmoney.html Magic Money] - PGP-based Chaumian blinding (unlinkable cash)

[http://opencoin.org/ OpenCoin.org] - REST-based blinded tokens

[http://www.opentransact.org/ OpenTransact] - REST-based transaction protocol

[https://payswarm.com/ PaySwarm] - REST-based transaction protocol

[https://www.facebook.com/publickeytransaction PKTP] - Public-Key Transaction Processor

[http://wiki.dgcmagazine.com/index.php?title=Ricardo Ricardo] - Transaction system by Ian Grigg

[https://ripple.com/ Ripple] - Consensus-based debt ledger

[https://www.stellar.org/ Stellar] - Ripple-based

[http://truledger.com/ Truledger] - Destruction of account history

[http://www.voucher-safe.com/index.cfm Voucher-Safe] - Secure asset issuance with auditing

---------

Article: [http://pelagic.wavyhill.xsmail.com/Private_Digital_Economy.html Toward a Private Digital Economy]

</div>

<div style="clear: both; padding-top: 40px;">

== In More Detail... ==

The server itself is a [[Transactions|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 '''[[Sample Cash|unlinkable digital cash]]'''. The software uses Chaumian-style, blinded tokens courtesy of the [http://anoncvs.aldigital.co.uk/lucre/ 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 [http://pktp.co.cc/ 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 [[Sample Currency Contract|currency contract]] to the server. (This functionality is comparable to [http://www.systemics.com/docs/sox/overview.html Ricardo] by [http://financialcryptography.com/ Ian Grigg].)
* '''Users can open asset accounts of any type.''' You can have as many as you want, associated with each user account. (See [http://loom.cc/ Loom] by Patrick Chkoreff.)
* [[Triple-Signed Receipts|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 [http://truledger.com/ Truledger] for an [http://truledger.com/doc/plain-english.html 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: [http://szabo.best.vwh.net/contractlanguage.html 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: <pre>#!/usr/local/bin/ot --script</pre>
* 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 '''[[Sample Currency Contract | 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: [http://www.goldstandardinstitute.net/2010/06/what-is-a-real-bill/ 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 [[API]]s''' for '''Java, Ruby, Python, PHP, Perl, C, [http://www.digitalmars.com/d/2.0/overview.html 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 [http://zeromq.org/ 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.

</div>

API

2015-07-08T22:18:16Z

FellowTraveler: added moneychanger link

NOTE: This page is old, but preserved in case of any usefulness. [http://github.com/Open-Transactions/Moneychanger Moneychanger] is the reference implementation and it shows how to use the OT client API. If you ever need to write code that uses OT, just copy the sample code you need out of Moneychanger itself. It's that easy!

=== API Docs ===
* [http://opentransactions.org/docs/class_o_t___m_e.html High-level API (C++)]

* [http://opentransactions.org/docs/class_o_t_made_easy.html High-level API (all other languages)]

* [http://opentransactions.org/docs/class_o_t_a_p_i___wrap.html Low-level API (C++)]

* [http://opentransactions.org/docs/class_o_t_a_p_i___basic.html Low-level API (all other languages)]

The general rule of thumb is: Always prefer the high-level API. (Only use the low-level API for functions where no high-level API version is available.)

=== Introduction ===
* See the [https://github.com/FellowTraveler/Open-Transactions/blob/master/include/otapi/OTMadeEasy.h#L159 OTMadeEasy] class, as well as the sample scripts provided in [https://github.com/FellowTraveler/Open-Transactions/blob/master/scripts/demo/php/php_ot_test.php PHP] [https://github.com/FellowTraveler/Open-Transactions/blob/master/scripts/demo/python/python_ot_test.py Python] and [https://github.com/FellowTraveler/Open-Transactions/blob/master/scripts/demo/csharp/Main.cs C-Sharp].

* OT's high-level API is also available in OT [https://github.com/FellowTraveler/Open-Transactions/wiki/Client-side-scripting client-side scripts]

* The '''opentxs list''' and [https://github.com/FellowTraveler/Open-Transactions/wiki/opentxs opentxs help] commands display a complete list of all the OT API functions available on the command line. The actual code for those commands, written using the OT high-level API, [https://github.com/FellowTraveler/Open-Transactions/blob/master/scripts/ot/ot_commands.ot#L1288 is available here for your perusal]. This way, you can test the complete OT functionality at the command line, and then flip through the actual code for each command, and see how the OT API calls are used. '''You might be surprised how simple they really are.'''

* With that as your guide, a general rule of thumb is this: Anytime you need to do something, use the [https://github.com/FellowTraveler/Open-Transactions/blob/master/include/otapi/OTMadeEasy.h#L159 high-level API] to do it. Only if you can't find the function you are looking for, should you next resort to the [https://github.com/FellowTraveler/Open-Transactions/blob/master/include/otapi/OTAPI_Basic.h#L170 low-level API]. And remember, you can always the copy the code you need from the [https://github.com/FellowTraveler/Open-Transactions/blob/master/scripts/ot/ot_commands.ot#L1288 opentxs] tool, or from the test GUI, [http://github.com/FellowTraveler/otapij otapiJ].

What does this mean for you? It means you no longer have to worry about synchronizing request numbers, or harvesting transaction numbers, or comparing inbox hashes, or downloading your nymbox, or dropped messages, or timeouts, or retries, etc! Instead, you use simple functions like '''send_transfer''' or '''withdraw_cash'''. The high-level API manages everything else behind the scenes.

The OT high-level API (OTMadeEasy) is now available in these languages: [http://www.chaiscript.com/ ChaiScript] ( [https://github.com/FellowTraveler/Open-Transactions/blob/master/include/otapi/OTMadeEasy.h#L159 ot script] ) and Java, CSharp, PHP, Python, D, Perl, and TCL. The [https://github.com/FellowTraveler/Open-Transactions/blob/master/include/otapi/OTAPI_Basic.h#L170 low-level API] is available in D, Python, PHP, Perl, Java, etc. (Via [http://www.swig.org/ SWIG] wrappers.)

=== USE CASES for the OT API ===

* '''(Client software starts up.)''' Initialize the library and load the wallet.
* Display for user: '''Server Contracts, Nyms, Accounts, and Asset Types.'''
* Change the wallet's ''display label'' for any server, asset type, account, or nym.
* Import a server contract (or asset contract) to the wallet.
* Create a new '''Pseudonym''' (public/private key pair).
* Register a public key (a ''"Nym"'') at an OT server.
* '''Issue a new digital Asset Type'''. (Uploading an asset contract.)
* Retrieve Currency Contract (by ID).
* '''Create a new Asset Account'''.
* '''Write a cheque''' (or invoice)
* '''Send a Message''' to another user (via the server, encrypted to the recipient's public key.)
* '''Deposit a cheque'''
* '''Withdraw cash''' . . . . <==== CHAUMIAN DIGITAL CASH!!
* '''Deposit cash'''
* Withdraw Voucher
* '''Account-to-Account Transfer'''
* Create a new '''Basket Currency'''
* '''Exchange''' Digital Assets '''in and out of Baskets''' (from your Asset Accounts)
* '''Process your Inbox''' (Receipts and pending transfers)
* Set up a '''Payment Plan'''
* Issue a '''Market Offer'''

-------

'''Initialize the library and Load your Wallet'''

(The user starts up the wallet software.)

Call '''OT_API_Init()'''

Then call '''OT_API_LoadWallet()'''

(NOTE: these above 2 steps are not necessary in OT-script, only Java and other languages.)

'''Display the current list of server contracts on the screen'''

Call '''OT_API_GetServerCount()''', which returns the number of server contracts in your wallet.

For each one, call '''OT_API_GetServer_ID()''' to get the Server ID (which is a hash of the contract.)

Also for each, call '''OT_API_GetServer_Name()''' to get the Display Name from the contract.

In your GUI, display the name on the screen, but use the ID behind the scenes (for your messages to the server.)

'''Do the same thing for Nyms, Accounts, and Asset Types.'''

You can read about them on the [[API]] page, but here are the basic functions:

OT_API_GetNymCount(void);

OT_API_GetServerCount(void);

OT_API_GetAssetTypeCount(void);

OT_API_GetAccountCount(void);

OT_API_GetNym_ID() and OT_API_GetNym_Name()

OT_API_GetServer_ID() and OT_API_GetServer_Name()

OT_API_GetAssetType_ID() and OT_API_GetAssetType_Name()

OT_API_GetAccountWallet_ID() and OT_API_GetAccountWallet_Name()

Also:

OT_API_GetAccountWallet_Balance()

OT_API_GetAccountWallet_Type()

OT_API_GetAccountWallet_AssetTypeID()

'''Add a new server contract (or asset contract) to the wallet'''

Call '''OT_API_AddServerContract()'''

or '''OT_API_AddAssetContract()'''.

'''Create a new Pseudonym'''

(Each user's wallet may contain many pseudonyms. Each Nym consists of a public and a private key, aka a "key pair".)

Call '''OT_API_CreateNym()'''

This creates a new key pair _("Nym")_ in your wallet, which you can use for communications with an OT server.

(That is, for opening asset accounts and performing various other transactions. A Nym is a "user account".)

(You can create as many of these pseudonyms as you want.)

(You can register the same nyms at multiple servers.)

(The same Nym will have the same Nym ID and public key on every server.)

Example

<pre>
def details_create_nym(nKeybits, strName)
{
var madeEasy = OT_ME()
var strNymID = madeEasy.create_pseudonym(nKeybits, "", "") // returns new Nym ID

if (!VerifyStringVal(strNymID))
{
OT_API_Output(0, "details_create_nym: Failed in OT_ME::create_pseudonym(keybits == " + nKeybits.to_string() + ")\n")
return (0)
}
OT_API_Output(0, "Success creating! " + nKeybits.to_string() + " keybits, new ID: ") // stderr
print(strNymID) // stdout
OT_API_Output(0, "\n") //stderr
// -------------------
var bSetName = OT_API_SetNym_Name(strNymID, // subject
strNymID, // signer
strName)
if (!bSetName)
{
OT_API_Output(0, "Failed in OT_API_SetNym_Name(name == " + strName + ")\n")
return (0)
}
// -------------------
OT_API_Output(0, "Success setting name to: " + strName + "\n\n") // stderr
return 1
}
</pre>

'''Register a public key (aka "Nym") at an OT server'''

<pre>
var madeEasy = OT_ME()
if (VerifyExists("Server") && VerifyExists("MyNym"))
{
var strResponse = madeEasy.register_nym(Server, MyNym)
var nSuccess = VerifyMessageSuccess(strResponse)
switch(nSuccess)
{
case (1)
{
OT_API_Output(0, "\n\n SUCCESS in register_nym! Server response:\n\n");
print(strResponse) // stdout
break
}
default
{
OT_API_Output(0, "\n\n Failure or Error in register_nym!\n")

if (VerifyStringVal(strResponse))
{
OT_API_Output(0, "Server response:\n\n");
print(strResponse) // stdout
}
break
}
}
</pre>

'''Change the wallet's label for any server/asset type/account/nym'''

(This is only a client-side label, for display purposes only.)

'''OT_API_SetNym_Name()'''

'''OT_API_SetAccountWallet_Name()'''

'''OT_API_SetAssetType_Name()'''

'''OT_API_SetServer_Name()'''

----------------------------

'''Issue a new digital Asset Type'''

User uploads a new currency contract to the server, so users can create asset accounts based on that asset type.

Server replies with a new issuer account ID (The new Issuer account appears inside your wallet's account list, so go ahead and iterate the list again, in order to display the updated list of accounts on the screen.)

High-level API version (in OT script):

<pre>
var madeEasy = OT_ME()
OT_API_Output(0, "Please paste a currency contract, followed by an EOF or a ~ by itself on a blank line:\n\n")
var strContract = OT_CLI_ReadUntilEOF()
var strResponse = madeEasy.issue_asset_type(Server, MyNym, strContract)
var nStatus = VerifyMessageSuccess(strResponse)

switch(nStatus)
{
case (1)
{
OT_API_Output(0, "\n\n SUCCESS in issue_asset! Server response:\n\n");
print(strResponse) // stdout
break
}
default
{
OT_API_Output(0, "\n\n Failure or error in issue_asset. nStatus: "+nStatus.to_string()+"\n")
if (VerifyStringVal(strResponse))
{
OT_API_Output(0, "Server response:\n\n");
print(strResponse) // stdout
}
break
}
}
</pre>

'''Retrieve Currency Contract (by ID)'''

User wants to download a currency contract from the server (for a given asset type ID.)

(The asset type ID is a hash of the contract, so OT will know if you get the wrong one, since this is verified whenever a contract is loaded up.)

High-level API version (in OT script):

<pre>
var madeEasy = OT_ME()
var strRetrieved = madeEasy.retrieve_contract(Server, MyNym, strContractID)
var nRetrieved = VerifyMessageSuccess(strRetrieved)
var strSuccess = "ERROR"
if (1 == nRetrieved)
{ strSuccess = "SUCCESS" }
else if (0 == nRetrieved)
{ strSuccess = "FAILED" }
OT_API_Output(0, "\n\n " + strSuccess + " retrieving contract: "+strContractID+"\n\n")
</pre>

'''Create a new Asset Account'''

Example in OT Script, from the "sample scripts":https://github.com/FellowTraveler/Open-Transactions/tree/master/scripts/samples folder:

<pre>
def OT_ME::create_asset_acct(SERVER_ID, NYM_ID, ASSET_TYPE_ID)
{
var ot_Msg := OTAPI_Func()
// -------------------------
var theRequest := OTAPI_Func(ot_Msg.CREATE_ASSET_ACCT, SERVER_ID, NYM_ID, ASSET_TYPE_ID)
var strResponse = theRequest.SendRequest(theRequest, "CREATE_ASSET_ACCT")

return strResponse
}
</pre>

If it was a SUCCESS, then refresh the list of accounts in your display (from the OT API) since your new asset account should now be there.

(You can also use the "decode" command in the test wallet anytime you want to base64-decode something.)

--------------------------

'''TRANSACTIONS'''

FYI: Balance agreement, combined with transaction numbers, is what makes it possible for the server and all other parties to _eliminate account history, instead storing only the last signed receipt._ (Of course they have the ''choice'' to keep their own records--but they are no longer ''forced'' to do so.)

In order to do any transaction, the wallet's _balance agreement_ process requires that you have the latest copy of your account, inbox, and outbox files. You don't have to worry about this too much, since the high-level API will usually handle it for you.

'''You might ask: ''"But what if I download my account, or my outbox, and the server has maliciously inserted data into them?"'' '''
''No problem'' -- Open Transactions stores the last signed receipt from the server, and is able to verify the new intermediary files against that last receipt. You can see this happening when you run the command-line test client, and receipts can be verified programmatically using '''OT_API_VerifyAccountReceipt()'''.

The [[Triple-Signed Receipts]] on Open Transactions ensure that this sort of protection is available to all parties, '''while simultaneously not having to store any transaction history!'''

------------------

'''Write a Cheque'''

Alice writes a cheque (offline): Call '''OT_API_WriteCheque()'''

Alice then gives cheque to Bob (offline), _or_ online if she prefers via '''OT_API_sendUserMessage()''' function.

If Alice has Bob's UserID but not his public key, her wallet first uses '''OT_API_checkUser()''' to retrieve his public key from the server, and then encrypts the cheque before sending it.

NOTE: a quality wallet software will keep track of ALL instruments! Even when Alice gives a cheque to Bob, her wallet should still store a copy of that cheque. Until when? Until at least after he has cashed it... when he does that, a chequeReceipt will appear in her inbox. Only when she accepts that receipt, signing a new balance agreement, is she finally free of the transaction number that was on that cheque. (It was still signed-out to her, all the way up until that time.)

WHAT IF Bob had never cashed it? WHAT IF he lost it? Is Alice supposed to just keep signing for that number forever? (The chequeReceipt will never appear in her inbox. She is doomed to continue signing for this number on all of her receipts on into the future, ad infinitum, with no hope of ever closing it out!)

Fear not, there is a solution: '''OT_API_DiscardCheque()'''. (Lucky you saved a copy of that cheque in your wallet, eh?) This function will retrieve Alice's transaction # back from the cheque, so that her wallet is free to use it on her next valid transaction, and then close it out normally.

'''Deposit a cheque'''

(A voucher is also a cheque, so you may deposit a voucher here the same as any other cheque.)

Bob sends message to server requesting deposit:

'''(High level API version, in Java.)'''

<pre>
public boolean depositCheque(String serverID, String nymID, String accountID, String cheque) {

System.out.println("In depositCheque serverID:" + serverID + " nymID:" + nymID + " acount ID:" + accountID);

// ---------------------------------------------------
OTAPI_Func theRequest = new OTAPI_Func(OTAPI_Func.FT.DEPOSIT_CHEQUE, serverID, nymID, accountID, cheque);
String strResponse = OTAPI_Func.SendTransaction(theRequest, "DEPOSIT_CHEQUE"); // <========================

if (null == strResponse) {
System.out.println("OTAPI_Func.SendTransaction() failed, in depositCheque.");
return false;
}
// --------------------------------------------------------------------------------------

return true;
}
</pre>

'''Withdraw cash'''

Alice's wallet first makes sure she has the latest public mint file, by calling '''OT_API_getMint()'''.

(Note: if the mint she already has is within its valid date range, there's no need to do this.)

(Note: If she does call getMint, Alice needs to check the server reply and make sure it was successful before continuing with the withdrawal. The public mint keys are necessary for cash withdrawal.)

Alice then withdraws from her asset account, by messaging server: '''OT_API_notarizeWithdrawal()'''

Server replies with chaumian cash, which is stored in the purse folder in local storage.

Here is the full Java implementation of Withdraw Cash:

<pre>
public boolean withdrawCash(String serverID, String nymID, String accountID, String amount)
{
String serverResponseMessage = null;
System.out.println("In withdrawCash serverID:" + serverID + " nymID:" + nymID + " acount ID:" + accountID);
String assetID = otapi.OT_API_GetAccountWallet_AssetTypeID(accountID);

// ----------------------------------------
// Make sure we have the proper asset contract for the withdrawal.
//
String assetContract = otapi.OT_API_LoadAssetContract(assetID);
if (assetContract == null) {
OTAPI_Func theRequest = new OTAPI_Func(OTAPI_Func.FT.GET_CONTRACT, serverID, nymID, assetID);
String strResponse = OTAPI_Func.SendRequest(theRequest, "GET_CONTRACT");

if (null == strResponse) {
System.out.println("IN withdrawCash: OTAPI_Func.SendRequest(GET_CONTRACT) failed. (I give up.) (Unable to find asset contract.)");
return false;
}
// ----------------------------------------
assetContract = otapi.OT_API_LoadAssetContract(assetID);
if (assetContract == null) {
System.out.println("OT_API_LoadAssetContract returned null even after OT_API_getContract (Unable to find asset contract.)");
return false;
}
}
// ---------------------------------------------------------
// Download the public mintfile if it's not there, or if it's expired.
// Also load it up into memory as a string (just to make sure it works.)
// Then we can actually send the withdrawal transaction request. (Until
// then, why bother?)
//
String mintFile;

// expired or missing.
if (1 != otapi.OT_API_Mint_IsStillGood(serverID, assetID))
{
// ----------------------------------------
OTAPI_Func theRequest = new OTAPI_Func(OTAPI_Func.FT.GET_MINT, serverID, nymID, assetID);
String strResponse = OTAPI_Func.SendRequest(theRequest, "GET_MINT");

if (null == strResponse) {
System.out.println("IN withdrawCash: OTAPI_Func.SendRequest(GET_MINT) failed. (I give up.) (Unable to get mint.)");
return false;
}
// ----------------------------------------
mintFile = otapi.OT_API_LoadMint(serverID, assetID);
if (mintFile == null) {
System.out.println("OT_API_LoadMint returned null even after OT_API_getMint (I give up.) (Unable to find mint.)");
return false;
}
}
else // current mint IS available already on local storage (and not expired.)
{
mintFile = otapi.OT_API_LoadMint(serverID, assetID);
if (mintFile == null) {
System.out.println("OT_API_LoadMint returned null even after successful OT_API_Mint_IsStillGood (I give up.) (Unable to find mint.)");
return false;
}
}
// ---------------------------------------------------
// By this point, the mintfile is DEFINITELY good (available, not null,
// not expired, and loaded up.) Now we know for a fact that when the API
// call is made to withdraw cash, that it will find the mint properly.
//
OTAPI_Func theRequest = new OTAPI_Func(OTAPI_Func.FT.WITHDRAW_CASH, serverID, nymID, accountID, amount);
String strResponse = OTAPI_Func.SendTransaction(theRequest, "WITHDRAW_CASH"); // <========================

if (null == strResponse) {
System.out.println("OTAPI_Func.SendTransaction() failed, in withdrawCash.");
return false;
}
// --------------------------------------------------------------------------------------

return true;
}
</pre>

'''Deposit cash'''

Here is the complete Java implementation for Deposit Cash:

<pre>
public boolean depositCash(String serverID, String nymID, String accountID, String purse, boolean isToken) {

System.out.println("In depositCash serverID:" + serverID + " nymID:" + nymID + " acount ID:" + accountID + " isToken:" + isToken);
Utility.setOtDepositCash(null);
String oldPurse = purse;
if (isToken) {
purse = getNewPurse(purse, serverID, nymID, accountID);
System.out.println("purse after getting from push purse:" + purse);
if (purse == null) {
Utility.setOtDepositCash(oldPurse);
return false;
}
}
// ----------------------------------------
OTAPI_Func theRequest = new OTAPI_Func(OTAPI_Func.FT.DEPOSIT_CASH, serverID, nymID, accountID, purse);
String strResponse = OTAPI_Func.SendTransaction(theRequest, "DEPOSIT_CASH"); // <========================

if (null == strResponse) {
System.out.println("IN depositCash: OTAPI_Func.SendTransaction(() failed. (I give up.) ");

if (isToken) {
System.out.println("IN depositCash, failed action for single token");
String assetID = otapi.OT_API_GetAccountWallet_AssetTypeID(accountID);
boolean importStatus = otapi.OT_API_Wallet_ImportPurse(serverID, assetID, nymID, purse) == 1 ? true : false;
System.out.println("Since failure of depositCashPurse, OT_API_Wallet_ImportPurse called, status of import:" + importStatus);
if (!importStatus) {
Utility.setOtDepositCash(purse);
}
}

return false;
}
// ----------------------------------------
return true;
}
</pre>

--------------------------------------

Note about local storage: Usually whenever something important is downloaded from the server, the OT API will save it automatically to the default storage context, and you can then load it up using another API call. This is usually the most convenient way to do things.

--------------------------------------

'''Account-to-Account Transfer'''

A _pending transfer_ will go into your outbox, and the recipient's inbox, pending acceptance by the recipient.

FYI, every asset account has its own inbox and outbox for handling pending transactions, as well as receipts.

FYI, every Nym similarly has its own Nymbox, used for receiving messages from other users, and for receiving new transaction numbers from the server.

Here is the OT Script implementation of Send Transfer, from the "sample scripts":https://github.com/FellowTraveler/Open-Transactions/tree/master/scripts/samples folder:

<pre>
def OT_ME::send_transfer(SERVER_ID, NYM_ID, ACCT_FROM, ACCT_TO, AMOUNT, NOTE)
{
var ot_Msg := OTAPI_Func()
// -------------------------
var theRequest := OTAPI_Func(ot_Msg.SEND_TRANSFER, SERVER_ID, NYM_ID, ACCT_FROM, ACCT_TO, AMOUNT, NOTE)
var strResponse = theRequest.SendTransaction(theRequest, "SEND_TRANSFER")

return strResponse
}
</pre>

'''Withdraw Voucher'''

A voucher is like a "money order" or "cashier's cheque". It's a cheque, but drawn on a server account, instead of your own account.

Withdrawing in voucher form is similar to withdrawing in cash: the server debits your asset account, and then gives you an official cheque.

But with cash, it's automatically saved to your purse, whereas with a voucher, you have to read the voucher out of the server reply, and display it on the screen!

Here is the complete Java code to perform Withdraw Voucher:

<pre>
public String withdrawVoucher(String serverID, String nymID, String accountID, String amount, String chequeMemo, String recepientNymID) {

System.out.println("In withdrawVoucher serverID:" + serverID + " nymID:" + nymID + " acount ID:" + accountID);

// ---------------------------------------------------
OTAPI_Func theRequest = new OTAPI_Func(OTAPI_Func.FT.WITHDRAW_VOUCHER, serverID, nymID, accountID, recepientNymID, chequeMemo, amount);
String strResponse = OTAPI_Func.SendTransaction(theRequest, "WITHDRAW_VOUCHER"); // <========================

if (null == strResponse) {
System.out.println("OTAPI_Func.SendTransaction() failed, in withdrawVoucher.");
return null;
}
// ---------------------------------------------------------
String ledger = otapi.OT_API_Message_GetLedger(strResponse);
if (ledger == null) {
System.out.println(" ledger is null, returned by OT_API_Message_GetLedger, serverResponseMessage passed as argument");
return null;
}
String transaction = otapi.OT_API_Ledger_GetTransactionByIndex(serverID, nymID, accountID, ledger, 0);
if (transaction == null) {
System.out.println("withdrawVoucher: transaction is null, returned by OT_API_Ledger_GetTransactionByIndex, argument passed, index 0 and ledger :" + ledger);
return null;
}
// ---------------------------------------------------------
String output = otapi.OT_API_Transaction_GetVoucher(serverID, nymID, accountID, transaction);
System.out.println("output returned by OT_API_Transaction_GetVoucher:" + output);

return output;
}
</pre>

---------------

'''BASKET CURRENCIES'''

'''Create a new Basket Currency'''

First, invent the basket in your head. Give it name: _"Clams."_

Next, give it a ratio in terms of other existing currencies: _"10 Clams equals a basket of 5 dollars, 3 Euro, and 20 Bitcoin"_

Call '''OT_API_GenerateBasketCreation()''' to begin creating the basket. The _"10 Clams"_ from above is set here.

Next, call '''OT_API_AddBasketCreationItem()''' for EACH currency in the basket. In the above example, I would call this function 3 times, in order to set the _"5 dollars"_ the _"3 Euro"_ and the _"20 Bitcoin"_ from above.

Now that the basket has been defined, call '''OT_API_issueBasket()''' to actually create the basket currency on the server.

(Now you have created a new asset type--a basket--which the server will control. Any user may now create accounts using this type! And from there, they can write cheques, withdraw cash, trade on markets, etc. the same as with any other asset type.)

'''Exchange Digital Assets in/out of a Basket Currency (from your Asset Accounts)'''

First, call '''OT_API_GenerateBasketExchange()''' to setup the exchange. You'll need to know the basket's asset type, and you'll need to have an existing asset account of that type. You will also set the "transfer multiple" in that call.

What's the transfer multiple? Remember the ratio above: "10 Clams equals a basket of 5 dollars, 3 Euro, and 20 Bitcoin"

Here are examples of the transfer multiple:

"10 Clams == 5 USD, 3 EUR, 20 BIT" (Transfer multiple: 1)

"20 Clams == 10 USD, 6 EUR, 40 BIT" (Transfer multiple: 2)

"30 Clams == 15 USD, 9 EUR, 60 BIT" (Transfer multiple: 3)

"40 Clams == 20 USD, 12 EUR, 80 BIT" (Transfer multiple: 4)

"50 Clams == 25 USD, 15 EUR, 100 BIT" (Transfer multiple: 5)

Next, call '''OT_API_AddBasketExchangeItem()''' for each currency type in the basket. You will need to to pass the asset account ID for an existing asset account, for each currency type (since you are converting in or out, from your basket account, to your asset accounts.)

Therefore you will call this function once for USD, once for EUR, and once for BIT, in that example, passing in your USD asset acct ID, your EUR asset acct ID, and your Bitcoin asset account ID.

Now that it's all set up, call '''OT_API_exchangeBasket()''' to actually message the server and perform the exchange.

'''Interesting''': ''basket currencies themselves require no more additional system resources than normal currencies!'' The magic happens during the exchange process. The server simply stores internal asset accounts for the dollars, euros, and bitcoins (say), and it manages the issuer account for the basket, and it also manages the exchanging in and out, by moving digital assets in or out of the internal backing accounts. After that point, a basket is just another Asset Type ID, and requires no additional resources. You can even have baskets made up of other baskets, nested 10 times, and it won't affect the speed of operation of the server!

------------------------

'''PROCESSING YOUR INBOX'''

'''Process the Receipts and Pending Transfers in your Inbox'''

If you wish, call '''OT_API_getInbox()''' to grab the latest inbox from the server.

In the high-level API, this is often just automated for you, but nevertheless, check out the dl_acct_files.ot script. See also show_inbox.ot, etc.

During this time, your user has the opportunity to peruse the inbox, and to decide which transactions therein he wishes to accept or reject. Usually the inbox is display on the screen, then the user selects various items to accept or reject, and then the user clicks "Process Inbox" and then you do this:

Then call '''OT_API_Ledger_CreateResponse()''' in order to create a 'response' ledger for that inbox, which will be sent to the server to signal your responses to the various inbox transactions.

Then call '''OT_API_Ledger_GetCount()''' (pass it the inbox) to find out how many transactions are inside of it. Use that count to LOOP through them...

Use '''OT_API_Ledger_GetTransactionByIndex()''' to grab each transaction as you iterate through the inbox. (There are various introspection functions you can use in the API here if you wish to display the inbox items on the screen for the user...)

Next call '''OT_API_Transaction_CreateResponse()''' for each transaction in the inbox, to create a response to it, accepting or rejecting it. This function creates the response and adds it to the response ledger.

Next, call '''OT_API_Ledger_FinalizeResponse()''' which will create a _Balance Agreement_ for the ledger.

Finally, call '''OT_API_processInbox()''' to send your message to the server and process the various items.

(See the accept_inbox.ot script.)

If the message was successful, then use '''OT_API_Message_GetBalanceAgreementSuccess()''' and '''OT_API_Message_GetTransactionSuccess()''' to see just _how_ successful.

---------------------------------

'''MARKETS and PAYMENT PLANS'''

'''Setup a Payment Plan'''

The Merchant draws up the Payment Plan using '''OT_API_ProposePaymentPlan'''

Then he sends it to the Customer, who calls '''OT_API_ConfirmPaymentPlan'''

The Customer's wallet activates the payment plan by sending it to the server using this function: '''OT_API_depositPaymentPlan()'''

(Receipts will process into the respective parties' inboxes.)

Use OT_API_cancelCronItem() to cancel any payment plan (or market offer.)

If the message was successful, then use '''OT_API_Message_GetBalanceAgreementSuccess()''' and '''OT_API_Message_GetTransactionSuccess()''' as described above in the _deposit cash_ instructions.

'''Issue a [[Markets|Market]] Offer'''

Call this function: '''OT_API_issueMarketOffer()'''

(That's the low-level one. See create_offer.ot script for the high-level version.)

Call '''OT_API_Message_GetSuccess''' to find out if the message was a SUCCESS or FAILURE.

If the message was successful, then use '''OT_API_Message_GetBalanceAgreementSuccess()''' and '''OT_API_Message_GetTransactionSuccess()''' as described above in the _deposit cash_ instructions.
See the OTScript and Java versions of these calls.

Once an offer goes onto the market, multiple trades may occur between it and the other offers on the market.

(According to the rules in the offers.) Receipts will process into the respective parties' inboxes after each trade.

'''Cancel a Market Offer'''

Use '''OT_API_cancelNymMarketOffer''' to remove an offer from a market.

If the message was successful, then use '''OT_API_Message_GetBalanceAgreementSuccess()''' and '''OT_API_Message_GetTransactionSuccess()'''

'''Retrieving Market Data from OT Server:'''

'''OT_API_getMarketList''' retrieves a list of all the markets available on a specific server, and details for each market. If the server call is a success, the data will be retrieved from the OT server, and written to local storage using the OT Storage API, at this path or key (inside your data_folder location): '''markets/SERVER_ID/market_data.bin'''

If you want to verify whether the data is now available in local storage (after a successful call to getMarketList), your code would look like this:

'''if (otapi.Exists("markets", serverID, "market_data.bin")) bFoundFile = true;'''

Here is some Java code that reads the market list object from local storage, assuming bFoundFile is true:

<pre>
MarketList marketList = null;
Storable storable = null;

if (otapi.Exists("markets", serverID, "market_data.bin"))
{
storable =
otapi.QueryObject(StoredObjectType.STORED_OBJ_MARKET_LIST,
"markets", serverID, "market_data.bin");
if (storable==null)
return null;
marketList = MarketList.ot_dynamic_cast(storable);
}
</pre>

Once you have the market list, here is some sample Java code to read the details of an individual market from that list:

<pre>
public static Object getMarketDetails(String marketID)
{
MarketList marketList = Utility.getMarketList();

if (marketList == null)
{
return null;
}

for (int i=0; i < marketList.GetMarketDataCount(); i++)
{
MarketData marketData = marketList.GetMarketData(i);

if (marketData == null)
continue;

String [] row = new String[2];

if (marketID.equals(marketData.getMarket_id()))
{
String[] data = new String[2];
marketData.getLast_sale_price();
marketData.getCurrent_ask();

// Etc!! This is where you get the market details.
}
}

// return custom object here (row/data or whatever), or null if failure..
return null;
}
</pre>

'''OT_API_getMarketOffers''' retrieves publicly-available info for all offers on a specific market, up until maximum depth, and saves the data here: '''markets/SERVER_ID/offers/MARKET_ID.bin'''

(See testwallet/OTAPI.i for ALL DATA OBJECTS that are used in local storage, including market offers, recent trades, etc. See the code above for a sample on how those data objects are used.)

'''OT_API_getMarketRecentTrades''': Retrieves all recent trades on a market (up until maximum depth), and stores them here: '''markets/SERVER_ID/recent/MARKET_ID.bin'''

To retrieve the offers that a specific Nym has out on the market, use: '''OT_API_getNym_MarketOffers'''

This _getNym_MarketOffers_ data is _private_ and thus a lot more detailed than what's retrieved via '''OT_API_Market_GetOffers''', which is more meant for public use.

After a successful retrieval, you can load the data from this location: '''nyms/SERVER_ID/offers/NYM_ID.bin'''

If you want to see the Nym's private list of his ''completed trades'', the path to load it from is here:

'''nyms/trades/SERVER_ID/NYM_ID'''

There is no need to send a server message in this last case--just read the data from local storage directly. (When market trading receipts are accepted and cleared out of your inbox, this is where they will go. So there's no need to download them, since they were already downloaded through your inbox previously.)

As before, the appropriate data object can be found in testwallet/OTAPI.i along with all the others.

----------------------

I will be very responsive to developer needs and questions regarding the OT API, so I encourage you to play with the software and contact me anytime.

See also:

[[Opentxs | opentxs command-line tool]]

[[List of Classes | The OT C++ class library]]

[[OTX | The OTX protocol]]

API

2015-07-08T22:17:46Z

FellowTraveler: wording

NOTE: This page is old, but preserved in case of any usefulness. [github.com/Open-Transactions/Moneychanger Moneychanger] is the reference implementation and it shows how to use the OT client API. If you ever need to write code that uses OT, just copy the sample code you need out of Moneychanger itself. It's that easy!

=== API Docs ===
* [http://opentransactions.org/docs/class_o_t___m_e.html High-level API (C++)]

* [http://opentransactions.org/docs/class_o_t_made_easy.html High-level API (all other languages)]

* [http://opentransactions.org/docs/class_o_t_a_p_i___wrap.html Low-level API (C++)]

* [http://opentransactions.org/docs/class_o_t_a_p_i___basic.html Low-level API (all other languages)]

The general rule of thumb is: Always prefer the high-level API. (Only use the low-level API for functions where no high-level API version is available.)

=== Introduction ===
* See the [https://github.com/FellowTraveler/Open-Transactions/blob/master/include/otapi/OTMadeEasy.h#L159 OTMadeEasy] class, as well as the sample scripts provided in [https://github.com/FellowTraveler/Open-Transactions/blob/master/scripts/demo/php/php_ot_test.php PHP] [https://github.com/FellowTraveler/Open-Transactions/blob/master/scripts/demo/python/python_ot_test.py Python] and [https://github.com/FellowTraveler/Open-Transactions/blob/master/scripts/demo/csharp/Main.cs C-Sharp].

* OT's high-level API is also available in OT [https://github.com/FellowTraveler/Open-Transactions/wiki/Client-side-scripting client-side scripts]

* The '''opentxs list''' and [https://github.com/FellowTraveler/Open-Transactions/wiki/opentxs opentxs help] commands display a complete list of all the OT API functions available on the command line. The actual code for those commands, written using the OT high-level API, [https://github.com/FellowTraveler/Open-Transactions/blob/master/scripts/ot/ot_commands.ot#L1288 is available here for your perusal]. This way, you can test the complete OT functionality at the command line, and then flip through the actual code for each command, and see how the OT API calls are used. '''You might be surprised how simple they really are.'''

* With that as your guide, a general rule of thumb is this: Anytime you need to do something, use the [https://github.com/FellowTraveler/Open-Transactions/blob/master/include/otapi/OTMadeEasy.h#L159 high-level API] to do it. Only if you can't find the function you are looking for, should you next resort to the [https://github.com/FellowTraveler/Open-Transactions/blob/master/include/otapi/OTAPI_Basic.h#L170 low-level API]. And remember, you can always the copy the code you need from the [https://github.com/FellowTraveler/Open-Transactions/blob/master/scripts/ot/ot_commands.ot#L1288 opentxs] tool, or from the test GUI, [http://github.com/FellowTraveler/otapij otapiJ].

What does this mean for you? It means you no longer have to worry about synchronizing request numbers, or harvesting transaction numbers, or comparing inbox hashes, or downloading your nymbox, or dropped messages, or timeouts, or retries, etc! Instead, you use simple functions like '''send_transfer''' or '''withdraw_cash'''. The high-level API manages everything else behind the scenes.

The OT high-level API (OTMadeEasy) is now available in these languages: [http://www.chaiscript.com/ ChaiScript] ( [https://github.com/FellowTraveler/Open-Transactions/blob/master/include/otapi/OTMadeEasy.h#L159 ot script] ) and Java, CSharp, PHP, Python, D, Perl, and TCL. The [https://github.com/FellowTraveler/Open-Transactions/blob/master/include/otapi/OTAPI_Basic.h#L170 low-level API] is available in D, Python, PHP, Perl, Java, etc. (Via [http://www.swig.org/ SWIG] wrappers.)

=== USE CASES for the OT API ===

* '''(Client software starts up.)''' Initialize the library and load the wallet.
* Display for user: '''Server Contracts, Nyms, Accounts, and Asset Types.'''
* Change the wallet's ''display label'' for any server, asset type, account, or nym.
* Import a server contract (or asset contract) to the wallet.
* Create a new '''Pseudonym''' (public/private key pair).
* Register a public key (a ''"Nym"'') at an OT server.
* '''Issue a new digital Asset Type'''. (Uploading an asset contract.)
* Retrieve Currency Contract (by ID).
* '''Create a new Asset Account'''.
* '''Write a cheque''' (or invoice)
* '''Send a Message''' to another user (via the server, encrypted to the recipient's public key.)
* '''Deposit a cheque'''
* '''Withdraw cash''' . . . . <==== CHAUMIAN DIGITAL CASH!!
* '''Deposit cash'''
* Withdraw Voucher
* '''Account-to-Account Transfer'''
* Create a new '''Basket Currency'''
* '''Exchange''' Digital Assets '''in and out of Baskets''' (from your Asset Accounts)
* '''Process your Inbox''' (Receipts and pending transfers)
* Set up a '''Payment Plan'''
* Issue a '''Market Offer'''

-------

'''Initialize the library and Load your Wallet'''

(The user starts up the wallet software.)

Call '''OT_API_Init()'''

Then call '''OT_API_LoadWallet()'''

(NOTE: these above 2 steps are not necessary in OT-script, only Java and other languages.)

'''Display the current list of server contracts on the screen'''

Call '''OT_API_GetServerCount()''', which returns the number of server contracts in your wallet.

For each one, call '''OT_API_GetServer_ID()''' to get the Server ID (which is a hash of the contract.)

Also for each, call '''OT_API_GetServer_Name()''' to get the Display Name from the contract.

In your GUI, display the name on the screen, but use the ID behind the scenes (for your messages to the server.)

'''Do the same thing for Nyms, Accounts, and Asset Types.'''

You can read about them on the [[API]] page, but here are the basic functions:

OT_API_GetNymCount(void);

OT_API_GetServerCount(void);

OT_API_GetAssetTypeCount(void);

OT_API_GetAccountCount(void);

OT_API_GetNym_ID() and OT_API_GetNym_Name()

OT_API_GetServer_ID() and OT_API_GetServer_Name()

OT_API_GetAssetType_ID() and OT_API_GetAssetType_Name()

OT_API_GetAccountWallet_ID() and OT_API_GetAccountWallet_Name()

Also:

OT_API_GetAccountWallet_Balance()

OT_API_GetAccountWallet_Type()

OT_API_GetAccountWallet_AssetTypeID()

'''Add a new server contract (or asset contract) to the wallet'''

Call '''OT_API_AddServerContract()'''

or '''OT_API_AddAssetContract()'''.

'''Create a new Pseudonym'''

(Each user's wallet may contain many pseudonyms. Each Nym consists of a public and a private key, aka a "key pair".)

Call '''OT_API_CreateNym()'''

This creates a new key pair _("Nym")_ in your wallet, which you can use for communications with an OT server.

(That is, for opening asset accounts and performing various other transactions. A Nym is a "user account".)

(You can create as many of these pseudonyms as you want.)

(You can register the same nyms at multiple servers.)

(The same Nym will have the same Nym ID and public key on every server.)

Example

<pre>
def details_create_nym(nKeybits, strName)
{
var madeEasy = OT_ME()
var strNymID = madeEasy.create_pseudonym(nKeybits, "", "") // returns new Nym ID

if (!VerifyStringVal(strNymID))
{
OT_API_Output(0, "details_create_nym: Failed in OT_ME::create_pseudonym(keybits == " + nKeybits.to_string() + ")\n")
return (0)
}
OT_API_Output(0, "Success creating! " + nKeybits.to_string() + " keybits, new ID: ") // stderr
print(strNymID) // stdout
OT_API_Output(0, "\n") //stderr
// -------------------
var bSetName = OT_API_SetNym_Name(strNymID, // subject
strNymID, // signer
strName)
if (!bSetName)
{
OT_API_Output(0, "Failed in OT_API_SetNym_Name(name == " + strName + ")\n")
return (0)
}
// -------------------
OT_API_Output(0, "Success setting name to: " + strName + "\n\n") // stderr
return 1
}
</pre>

'''Register a public key (aka "Nym") at an OT server'''

<pre>
var madeEasy = OT_ME()
if (VerifyExists("Server") && VerifyExists("MyNym"))
{
var strResponse = madeEasy.register_nym(Server, MyNym)
var nSuccess = VerifyMessageSuccess(strResponse)
switch(nSuccess)
{
case (1)
{
OT_API_Output(0, "\n\n SUCCESS in register_nym! Server response:\n\n");
print(strResponse) // stdout
break
}
default
{
OT_API_Output(0, "\n\n Failure or Error in register_nym!\n")

if (VerifyStringVal(strResponse))
{
OT_API_Output(0, "Server response:\n\n");
print(strResponse) // stdout
}
break
}
}
</pre>

'''Change the wallet's label for any server/asset type/account/nym'''

(This is only a client-side label, for display purposes only.)

'''OT_API_SetNym_Name()'''

'''OT_API_SetAccountWallet_Name()'''

'''OT_API_SetAssetType_Name()'''

'''OT_API_SetServer_Name()'''

----------------------------

'''Issue a new digital Asset Type'''

User uploads a new currency contract to the server, so users can create asset accounts based on that asset type.

Server replies with a new issuer account ID (The new Issuer account appears inside your wallet's account list, so go ahead and iterate the list again, in order to display the updated list of accounts on the screen.)

High-level API version (in OT script):

<pre>
var madeEasy = OT_ME()
OT_API_Output(0, "Please paste a currency contract, followed by an EOF or a ~ by itself on a blank line:\n\n")
var strContract = OT_CLI_ReadUntilEOF()
var strResponse = madeEasy.issue_asset_type(Server, MyNym, strContract)
var nStatus = VerifyMessageSuccess(strResponse)

switch(nStatus)
{
case (1)
{
OT_API_Output(0, "\n\n SUCCESS in issue_asset! Server response:\n\n");
print(strResponse) // stdout
break
}
default
{
OT_API_Output(0, "\n\n Failure or error in issue_asset. nStatus: "+nStatus.to_string()+"\n")
if (VerifyStringVal(strResponse))
{
OT_API_Output(0, "Server response:\n\n");
print(strResponse) // stdout
}
break
}
}
</pre>

'''Retrieve Currency Contract (by ID)'''

User wants to download a currency contract from the server (for a given asset type ID.)

(The asset type ID is a hash of the contract, so OT will know if you get the wrong one, since this is verified whenever a contract is loaded up.)

High-level API version (in OT script):

<pre>
var madeEasy = OT_ME()
var strRetrieved = madeEasy.retrieve_contract(Server, MyNym, strContractID)
var nRetrieved = VerifyMessageSuccess(strRetrieved)
var strSuccess = "ERROR"
if (1 == nRetrieved)
{ strSuccess = "SUCCESS" }
else if (0 == nRetrieved)
{ strSuccess = "FAILED" }
OT_API_Output(0, "\n\n " + strSuccess + " retrieving contract: "+strContractID+"\n\n")
</pre>

'''Create a new Asset Account'''

Example in OT Script, from the "sample scripts":https://github.com/FellowTraveler/Open-Transactions/tree/master/scripts/samples folder:

<pre>
def OT_ME::create_asset_acct(SERVER_ID, NYM_ID, ASSET_TYPE_ID)
{
var ot_Msg := OTAPI_Func()
// -------------------------
var theRequest := OTAPI_Func(ot_Msg.CREATE_ASSET_ACCT, SERVER_ID, NYM_ID, ASSET_TYPE_ID)
var strResponse = theRequest.SendRequest(theRequest, "CREATE_ASSET_ACCT")

return strResponse
}
</pre>

If it was a SUCCESS, then refresh the list of accounts in your display (from the OT API) since your new asset account should now be there.

(You can also use the "decode" command in the test wallet anytime you want to base64-decode something.)

--------------------------

'''TRANSACTIONS'''

FYI: Balance agreement, combined with transaction numbers, is what makes it possible for the server and all other parties to _eliminate account history, instead storing only the last signed receipt._ (Of course they have the ''choice'' to keep their own records--but they are no longer ''forced'' to do so.)

In order to do any transaction, the wallet's _balance agreement_ process requires that you have the latest copy of your account, inbox, and outbox files. You don't have to worry about this too much, since the high-level API will usually handle it for you.

'''You might ask: ''"But what if I download my account, or my outbox, and the server has maliciously inserted data into them?"'' '''
''No problem'' -- Open Transactions stores the last signed receipt from the server, and is able to verify the new intermediary files against that last receipt. You can see this happening when you run the command-line test client, and receipts can be verified programmatically using '''OT_API_VerifyAccountReceipt()'''.

The [[Triple-Signed Receipts]] on Open Transactions ensure that this sort of protection is available to all parties, '''while simultaneously not having to store any transaction history!'''

------------------

'''Write a Cheque'''

Alice writes a cheque (offline): Call '''OT_API_WriteCheque()'''

Alice then gives cheque to Bob (offline), _or_ online if she prefers via '''OT_API_sendUserMessage()''' function.

If Alice has Bob's UserID but not his public key, her wallet first uses '''OT_API_checkUser()''' to retrieve his public key from the server, and then encrypts the cheque before sending it.

NOTE: a quality wallet software will keep track of ALL instruments! Even when Alice gives a cheque to Bob, her wallet should still store a copy of that cheque. Until when? Until at least after he has cashed it... when he does that, a chequeReceipt will appear in her inbox. Only when she accepts that receipt, signing a new balance agreement, is she finally free of the transaction number that was on that cheque. (It was still signed-out to her, all the way up until that time.)

WHAT IF Bob had never cashed it? WHAT IF he lost it? Is Alice supposed to just keep signing for that number forever? (The chequeReceipt will never appear in her inbox. She is doomed to continue signing for this number on all of her receipts on into the future, ad infinitum, with no hope of ever closing it out!)

Fear not, there is a solution: '''OT_API_DiscardCheque()'''. (Lucky you saved a copy of that cheque in your wallet, eh?) This function will retrieve Alice's transaction # back from the cheque, so that her wallet is free to use it on her next valid transaction, and then close it out normally.

'''Deposit a cheque'''

(A voucher is also a cheque, so you may deposit a voucher here the same as any other cheque.)

Bob sends message to server requesting deposit:

'''(High level API version, in Java.)'''

<pre>
public boolean depositCheque(String serverID, String nymID, String accountID, String cheque) {

System.out.println("In depositCheque serverID:" + serverID + " nymID:" + nymID + " acount ID:" + accountID);

// ---------------------------------------------------
OTAPI_Func theRequest = new OTAPI_Func(OTAPI_Func.FT.DEPOSIT_CHEQUE, serverID, nymID, accountID, cheque);
String strResponse = OTAPI_Func.SendTransaction(theRequest, "DEPOSIT_CHEQUE"); // <========================

if (null == strResponse) {
System.out.println("OTAPI_Func.SendTransaction() failed, in depositCheque.");
return false;
}
// --------------------------------------------------------------------------------------

return true;
}
</pre>

'''Withdraw cash'''

Alice's wallet first makes sure she has the latest public mint file, by calling '''OT_API_getMint()'''.

(Note: if the mint she already has is within its valid date range, there's no need to do this.)

(Note: If she does call getMint, Alice needs to check the server reply and make sure it was successful before continuing with the withdrawal. The public mint keys are necessary for cash withdrawal.)

Alice then withdraws from her asset account, by messaging server: '''OT_API_notarizeWithdrawal()'''

Server replies with chaumian cash, which is stored in the purse folder in local storage.

Here is the full Java implementation of Withdraw Cash:

<pre>
public boolean withdrawCash(String serverID, String nymID, String accountID, String amount)
{
String serverResponseMessage = null;
System.out.println("In withdrawCash serverID:" + serverID + " nymID:" + nymID + " acount ID:" + accountID);
String assetID = otapi.OT_API_GetAccountWallet_AssetTypeID(accountID);

// ----------------------------------------
// Make sure we have the proper asset contract for the withdrawal.
//
String assetContract = otapi.OT_API_LoadAssetContract(assetID);
if (assetContract == null) {
OTAPI_Func theRequest = new OTAPI_Func(OTAPI_Func.FT.GET_CONTRACT, serverID, nymID, assetID);
String strResponse = OTAPI_Func.SendRequest(theRequest, "GET_CONTRACT");

if (null == strResponse) {
System.out.println("IN withdrawCash: OTAPI_Func.SendRequest(GET_CONTRACT) failed. (I give up.) (Unable to find asset contract.)");
return false;
}
// ----------------------------------------
assetContract = otapi.OT_API_LoadAssetContract(assetID);
if (assetContract == null) {
System.out.println("OT_API_LoadAssetContract returned null even after OT_API_getContract (Unable to find asset contract.)");
return false;
}
}
// ---------------------------------------------------------
// Download the public mintfile if it's not there, or if it's expired.
// Also load it up into memory as a string (just to make sure it works.)
// Then we can actually send the withdrawal transaction request. (Until
// then, why bother?)
//
String mintFile;

// expired or missing.
if (1 != otapi.OT_API_Mint_IsStillGood(serverID, assetID))
{
// ----------------------------------------
OTAPI_Func theRequest = new OTAPI_Func(OTAPI_Func.FT.GET_MINT, serverID, nymID, assetID);
String strResponse = OTAPI_Func.SendRequest(theRequest, "GET_MINT");

if (null == strResponse) {
System.out.println("IN withdrawCash: OTAPI_Func.SendRequest(GET_MINT) failed. (I give up.) (Unable to get mint.)");
return false;
}
// ----------------------------------------
mintFile = otapi.OT_API_LoadMint(serverID, assetID);
if (mintFile == null) {
System.out.println("OT_API_LoadMint returned null even after OT_API_getMint (I give up.) (Unable to find mint.)");
return false;
}
}
else // current mint IS available already on local storage (and not expired.)
{
mintFile = otapi.OT_API_LoadMint(serverID, assetID);
if (mintFile == null) {
System.out.println("OT_API_LoadMint returned null even after successful OT_API_Mint_IsStillGood (I give up.) (Unable to find mint.)");
return false;
}
}
// ---------------------------------------------------
// By this point, the mintfile is DEFINITELY good (available, not null,
// not expired, and loaded up.) Now we know for a fact that when the API
// call is made to withdraw cash, that it will find the mint properly.
//
OTAPI_Func theRequest = new OTAPI_Func(OTAPI_Func.FT.WITHDRAW_CASH, serverID, nymID, accountID, amount);
String strResponse = OTAPI_Func.SendTransaction(theRequest, "WITHDRAW_CASH"); // <========================

if (null == strResponse) {
System.out.println("OTAPI_Func.SendTransaction() failed, in withdrawCash.");
return false;
}
// --------------------------------------------------------------------------------------

return true;
}
</pre>

'''Deposit cash'''

Here is the complete Java implementation for Deposit Cash:

<pre>
public boolean depositCash(String serverID, String nymID, String accountID, String purse, boolean isToken) {

System.out.println("In depositCash serverID:" + serverID + " nymID:" + nymID + " acount ID:" + accountID + " isToken:" + isToken);
Utility.setOtDepositCash(null);
String oldPurse = purse;
if (isToken) {
purse = getNewPurse(purse, serverID, nymID, accountID);
System.out.println("purse after getting from push purse:" + purse);
if (purse == null) {
Utility.setOtDepositCash(oldPurse);
return false;
}
}
// ----------------------------------------
OTAPI_Func theRequest = new OTAPI_Func(OTAPI_Func.FT.DEPOSIT_CASH, serverID, nymID, accountID, purse);
String strResponse = OTAPI_Func.SendTransaction(theRequest, "DEPOSIT_CASH"); // <========================

if (null == strResponse) {
System.out.println("IN depositCash: OTAPI_Func.SendTransaction(() failed. (I give up.) ");

if (isToken) {
System.out.println("IN depositCash, failed action for single token");
String assetID = otapi.OT_API_GetAccountWallet_AssetTypeID(accountID);
boolean importStatus = otapi.OT_API_Wallet_ImportPurse(serverID, assetID, nymID, purse) == 1 ? true : false;
System.out.println("Since failure of depositCashPurse, OT_API_Wallet_ImportPurse called, status of import:" + importStatus);
if (!importStatus) {
Utility.setOtDepositCash(purse);
}
}

return false;
}
// ----------------------------------------
return true;
}
</pre>

--------------------------------------

Note about local storage: Usually whenever something important is downloaded from the server, the OT API will save it automatically to the default storage context, and you can then load it up using another API call. This is usually the most convenient way to do things.

--------------------------------------

'''Account-to-Account Transfer'''

A _pending transfer_ will go into your outbox, and the recipient's inbox, pending acceptance by the recipient.

FYI, every asset account has its own inbox and outbox for handling pending transactions, as well as receipts.

FYI, every Nym similarly has its own Nymbox, used for receiving messages from other users, and for receiving new transaction numbers from the server.

Here is the OT Script implementation of Send Transfer, from the "sample scripts":https://github.com/FellowTraveler/Open-Transactions/tree/master/scripts/samples folder:

<pre>
def OT_ME::send_transfer(SERVER_ID, NYM_ID, ACCT_FROM, ACCT_TO, AMOUNT, NOTE)
{
var ot_Msg := OTAPI_Func()
// -------------------------
var theRequest := OTAPI_Func(ot_Msg.SEND_TRANSFER, SERVER_ID, NYM_ID, ACCT_FROM, ACCT_TO, AMOUNT, NOTE)
var strResponse = theRequest.SendTransaction(theRequest, "SEND_TRANSFER")

return strResponse
}
</pre>

'''Withdraw Voucher'''

A voucher is like a "money order" or "cashier's cheque". It's a cheque, but drawn on a server account, instead of your own account.

Withdrawing in voucher form is similar to withdrawing in cash: the server debits your asset account, and then gives you an official cheque.

But with cash, it's automatically saved to your purse, whereas with a voucher, you have to read the voucher out of the server reply, and display it on the screen!

Here is the complete Java code to perform Withdraw Voucher:

<pre>
public String withdrawVoucher(String serverID, String nymID, String accountID, String amount, String chequeMemo, String recepientNymID) {

System.out.println("In withdrawVoucher serverID:" + serverID + " nymID:" + nymID + " acount ID:" + accountID);

// ---------------------------------------------------
OTAPI_Func theRequest = new OTAPI_Func(OTAPI_Func.FT.WITHDRAW_VOUCHER, serverID, nymID, accountID, recepientNymID, chequeMemo, amount);
String strResponse = OTAPI_Func.SendTransaction(theRequest, "WITHDRAW_VOUCHER"); // <========================

if (null == strResponse) {
System.out.println("OTAPI_Func.SendTransaction() failed, in withdrawVoucher.");
return null;
}
// ---------------------------------------------------------
String ledger = otapi.OT_API_Message_GetLedger(strResponse);
if (ledger == null) {
System.out.println(" ledger is null, returned by OT_API_Message_GetLedger, serverResponseMessage passed as argument");
return null;
}
String transaction = otapi.OT_API_Ledger_GetTransactionByIndex(serverID, nymID, accountID, ledger, 0);
if (transaction == null) {
System.out.println("withdrawVoucher: transaction is null, returned by OT_API_Ledger_GetTransactionByIndex, argument passed, index 0 and ledger :" + ledger);
return null;
}
// ---------------------------------------------------------
String output = otapi.OT_API_Transaction_GetVoucher(serverID, nymID, accountID, transaction);
System.out.println("output returned by OT_API_Transaction_GetVoucher:" + output);

return output;
}
</pre>

---------------

'''BASKET CURRENCIES'''

'''Create a new Basket Currency'''

First, invent the basket in your head. Give it name: _"Clams."_

Next, give it a ratio in terms of other existing currencies: _"10 Clams equals a basket of 5 dollars, 3 Euro, and 20 Bitcoin"_

Call '''OT_API_GenerateBasketCreation()''' to begin creating the basket. The _"10 Clams"_ from above is set here.

Next, call '''OT_API_AddBasketCreationItem()''' for EACH currency in the basket. In the above example, I would call this function 3 times, in order to set the _"5 dollars"_ the _"3 Euro"_ and the _"20 Bitcoin"_ from above.

Now that the basket has been defined, call '''OT_API_issueBasket()''' to actually create the basket currency on the server.

(Now you have created a new asset type--a basket--which the server will control. Any user may now create accounts using this type! And from there, they can write cheques, withdraw cash, trade on markets, etc. the same as with any other asset type.)

'''Exchange Digital Assets in/out of a Basket Currency (from your Asset Accounts)'''

First, call '''OT_API_GenerateBasketExchange()''' to setup the exchange. You'll need to know the basket's asset type, and you'll need to have an existing asset account of that type. You will also set the "transfer multiple" in that call.

What's the transfer multiple? Remember the ratio above: "10 Clams equals a basket of 5 dollars, 3 Euro, and 20 Bitcoin"

Here are examples of the transfer multiple:

"10 Clams == 5 USD, 3 EUR, 20 BIT" (Transfer multiple: 1)

"20 Clams == 10 USD, 6 EUR, 40 BIT" (Transfer multiple: 2)

"30 Clams == 15 USD, 9 EUR, 60 BIT" (Transfer multiple: 3)

"40 Clams == 20 USD, 12 EUR, 80 BIT" (Transfer multiple: 4)

"50 Clams == 25 USD, 15 EUR, 100 BIT" (Transfer multiple: 5)

Next, call '''OT_API_AddBasketExchangeItem()''' for each currency type in the basket. You will need to to pass the asset account ID for an existing asset account, for each currency type (since you are converting in or out, from your basket account, to your asset accounts.)

Therefore you will call this function once for USD, once for EUR, and once for BIT, in that example, passing in your USD asset acct ID, your EUR asset acct ID, and your Bitcoin asset account ID.

Now that it's all set up, call '''OT_API_exchangeBasket()''' to actually message the server and perform the exchange.

'''Interesting''': ''basket currencies themselves require no more additional system resources than normal currencies!'' The magic happens during the exchange process. The server simply stores internal asset accounts for the dollars, euros, and bitcoins (say), and it manages the issuer account for the basket, and it also manages the exchanging in and out, by moving digital assets in or out of the internal backing accounts. After that point, a basket is just another Asset Type ID, and requires no additional resources. You can even have baskets made up of other baskets, nested 10 times, and it won't affect the speed of operation of the server!

------------------------

'''PROCESSING YOUR INBOX'''

'''Process the Receipts and Pending Transfers in your Inbox'''

If you wish, call '''OT_API_getInbox()''' to grab the latest inbox from the server.

In the high-level API, this is often just automated for you, but nevertheless, check out the dl_acct_files.ot script. See also show_inbox.ot, etc.

During this time, your user has the opportunity to peruse the inbox, and to decide which transactions therein he wishes to accept or reject. Usually the inbox is display on the screen, then the user selects various items to accept or reject, and then the user clicks "Process Inbox" and then you do this:

Then call '''OT_API_Ledger_CreateResponse()''' in order to create a 'response' ledger for that inbox, which will be sent to the server to signal your responses to the various inbox transactions.

Then call '''OT_API_Ledger_GetCount()''' (pass it the inbox) to find out how many transactions are inside of it. Use that count to LOOP through them...

Use '''OT_API_Ledger_GetTransactionByIndex()''' to grab each transaction as you iterate through the inbox. (There are various introspection functions you can use in the API here if you wish to display the inbox items on the screen for the user...)

Next call '''OT_API_Transaction_CreateResponse()''' for each transaction in the inbox, to create a response to it, accepting or rejecting it. This function creates the response and adds it to the response ledger.

Next, call '''OT_API_Ledger_FinalizeResponse()''' which will create a _Balance Agreement_ for the ledger.

Finally, call '''OT_API_processInbox()''' to send your message to the server and process the various items.

(See the accept_inbox.ot script.)

If the message was successful, then use '''OT_API_Message_GetBalanceAgreementSuccess()''' and '''OT_API_Message_GetTransactionSuccess()''' to see just _how_ successful.

---------------------------------

'''MARKETS and PAYMENT PLANS'''

'''Setup a Payment Plan'''

The Merchant draws up the Payment Plan using '''OT_API_ProposePaymentPlan'''

Then he sends it to the Customer, who calls '''OT_API_ConfirmPaymentPlan'''

The Customer's wallet activates the payment plan by sending it to the server using this function: '''OT_API_depositPaymentPlan()'''

(Receipts will process into the respective parties' inboxes.)

Use OT_API_cancelCronItem() to cancel any payment plan (or market offer.)

If the message was successful, then use '''OT_API_Message_GetBalanceAgreementSuccess()''' and '''OT_API_Message_GetTransactionSuccess()''' as described above in the _deposit cash_ instructions.

'''Issue a [[Markets|Market]] Offer'''

Call this function: '''OT_API_issueMarketOffer()'''

(That's the low-level one. See create_offer.ot script for the high-level version.)

Call '''OT_API_Message_GetSuccess''' to find out if the message was a SUCCESS or FAILURE.

If the message was successful, then use '''OT_API_Message_GetBalanceAgreementSuccess()''' and '''OT_API_Message_GetTransactionSuccess()''' as described above in the _deposit cash_ instructions.
See the OTScript and Java versions of these calls.

Once an offer goes onto the market, multiple trades may occur between it and the other offers on the market.

(According to the rules in the offers.) Receipts will process into the respective parties' inboxes after each trade.

'''Cancel a Market Offer'''

Use '''OT_API_cancelNymMarketOffer''' to remove an offer from a market.

If the message was successful, then use '''OT_API_Message_GetBalanceAgreementSuccess()''' and '''OT_API_Message_GetTransactionSuccess()'''

'''Retrieving Market Data from OT Server:'''

'''OT_API_getMarketList''' retrieves a list of all the markets available on a specific server, and details for each market. If the server call is a success, the data will be retrieved from the OT server, and written to local storage using the OT Storage API, at this path or key (inside your data_folder location): '''markets/SERVER_ID/market_data.bin'''

If you want to verify whether the data is now available in local storage (after a successful call to getMarketList), your code would look like this:

'''if (otapi.Exists("markets", serverID, "market_data.bin")) bFoundFile = true;'''

Here is some Java code that reads the market list object from local storage, assuming bFoundFile is true:

<pre>
MarketList marketList = null;
Storable storable = null;

if (otapi.Exists("markets", serverID, "market_data.bin"))
{
storable =
otapi.QueryObject(StoredObjectType.STORED_OBJ_MARKET_LIST,
"markets", serverID, "market_data.bin");
if (storable==null)
return null;
marketList = MarketList.ot_dynamic_cast(storable);
}
</pre>

Once you have the market list, here is some sample Java code to read the details of an individual market from that list:

<pre>
public static Object getMarketDetails(String marketID)
{
MarketList marketList = Utility.getMarketList();

if (marketList == null)
{
return null;
}

for (int i=0; i < marketList.GetMarketDataCount(); i++)
{
MarketData marketData = marketList.GetMarketData(i);

if (marketData == null)
continue;

String [] row = new String[2];

if (marketID.equals(marketData.getMarket_id()))
{
String[] data = new String[2];
marketData.getLast_sale_price();
marketData.getCurrent_ask();

// Etc!! This is where you get the market details.
}
}

// return custom object here (row/data or whatever), or null if failure..
return null;
}
</pre>

'''OT_API_getMarketOffers''' retrieves publicly-available info for all offers on a specific market, up until maximum depth, and saves the data here: '''markets/SERVER_ID/offers/MARKET_ID.bin'''

(See testwallet/OTAPI.i for ALL DATA OBJECTS that are used in local storage, including market offers, recent trades, etc. See the code above for a sample on how those data objects are used.)

'''OT_API_getMarketRecentTrades''': Retrieves all recent trades on a market (up until maximum depth), and stores them here: '''markets/SERVER_ID/recent/MARKET_ID.bin'''

To retrieve the offers that a specific Nym has out on the market, use: '''OT_API_getNym_MarketOffers'''

This _getNym_MarketOffers_ data is _private_ and thus a lot more detailed than what's retrieved via '''OT_API_Market_GetOffers''', which is more meant for public use.

After a successful retrieval, you can load the data from this location: '''nyms/SERVER_ID/offers/NYM_ID.bin'''

If you want to see the Nym's private list of his ''completed trades'', the path to load it from is here:

'''nyms/trades/SERVER_ID/NYM_ID'''

There is no need to send a server message in this last case--just read the data from local storage directly. (When market trading receipts are accepted and cleared out of your inbox, this is where they will go. So there's no need to download them, since they were already downloaded through your inbox previously.)

As before, the appropriate data object can be found in testwallet/OTAPI.i along with all the others.

----------------------

I will be very responsive to developer needs and questions regarding the OT API, so I encourage you to play with the software and contact me anytime.

See also:

[[Opentxs | opentxs command-line tool]]

[[List of Classes | The OT C++ class library]]

[[OTX | The OTX protocol]]

Main Page

2015-07-08T22:15:43Z

FellowTraveler: /* Source Code */ added white paper

==Open-Transactions==

'''[http://www.opentransactions.org/open-transactions.pdf Click here for white paper.]'''

The Open-Transactions project is a collaborative effort to develop a robust, commercial-grade, fully-featured, '''free-software toolkit''' implementing the [[OTX|OTX protocol]] as well as a full-strength '''financial cryptography''' [[List_of_Classes|library]], API, GUI, command-line interface, and prototype notary server. The project is managed by a worldwide community of volunteers that use the Internet to communicate, plan, and develop the Open-Transactions toolkit and its related documentation.

===Financial Cryptography===

Financial cryptography means using using strong cryptographic techniques to create secure financial instruments, such as digital signing to create non-repudiable contracts, and encryption to create untraceable digital cash. In OT, transactions are unforgeable, receipts are destructible, and balances cannot be falsified or changed without user consent. OT is able to prove all balances, as well as which instruments are valid, and which transactions have closed, without storing any history except the last signed receipt.

Open-Transactions implements financial instruments as Ricardian Contracts; contracts which can be understood both by humans and manipulated by software.

All contracts in Open-Transactions use the same basic structure: all parties involved sign an agreement which is notarized by an independent third party witness. This technique is known as [[Triple-Signed Receipts]]. Importantly, transactions are formed and signed on the client side first, before being notarized by any server. An OT client is thus ensured that an OT notary server cannot falsify his receipts against his will, since the server can't forge the client's signature.

This basic structure can be built upon to create many types of financial instruments.

===Financial Instruments===

Financial instruments are any representation of a financial agreement between two or more parties.

The simplest financial instrument is a deposit agreement. A custodian of some asset (legal tender, or maybe gold) stores it on behalf of a depositor and agrees to redeem it on demand when presented with proof of a valid claim on the asset.

Other types of financial instruments include securities, of which there can be many variations. A security is an instrument that entitles the bearer to a certain revenue stream, either because it represents a loan or perhaps because it represents equity in a business.

Financial instruments in Open-Transactions have an issuer, who creates the contracts and is responsible for fulfilling the terms, and one or more bearers. Financial instruments are liabilities of the issuer owed to the bearers.

===Working with Financial Instruments===

Open-Transactions is designed to provide the highest security possible for both the issuers and bearers of financial instruments. Servers in Open-Transactions act as notaries which can witness and confirm balances, but cannot change them. Every party associated in a financial instrument can prove their balance to any other party, and no party can alter the balance of any other party without their agreement. Even a malicious notary cannot do this.

Open-Transactions represents quantities of a given unit type as deposit agreements, which are signed by the bearer and a notary.

Portions of a balance may be transferred between users via several asset-independent transaction types, including:

; Transfers
: An atomic movement of funds from one account to a different account, like a bank account-to-account transfer.
; Cheques
: A payment which is not deducted from the sender's account until the recipient claims it.
; Vouchers
: A payment which is deducted from the senders account at the time of creation.
; Invoices
: A payment request which the recipient can opt to pay from any of his accounts.
; Cash
: Anonymous cryptographic tokens which can be securely redeemed by the recipient without revealing the sender.
; Market offers
: Open agreements to exchange a given quantity of one instrument type for a given quantity of another instrument type.
; Smart Contracts
: Customizable agreements between multiple parties, containing user-defined scripted clauses, hooks, and variables.

==Use Cases==

===Encouraged use cases===

Encouraged uses cases are officially supported by Open-Transactions.

====Deposit accounting====

Entities that hold assets on behalf of depositors can use Open-Transactions to issue promissory notes as negotiable instruments.

Examples of such depositories includes:

* Precious metals
* Central bank currencies
* Cryptocurrencies

====Payments====

Users of OT negotiable instruments can authorize recurring payments to pay for services which operate on a billing cycle.

====Bearer Securities====

The negotiable instruments created by Open-Transactions can be used as the basis for financial products such as loans.

===Discouraged use cases===

Discouraged use cases are not supported by Open-Transactions, either because they violate the security requirements, or because they conflict with the philosophical goals of the project.

In many cases, discouraged use cases may be achievable, but users are required to create and support their own smart contracts.

====Third party balance editing====

The only entity in Open-Transactions that can edit a balance is the holder of that balance receipt. Open-Transactions does not and will not include any functionality to bypass this design decision.

==More Information==

* [[About|About Open-Transactions]]
* [[Installation]]
* [[opentxs|Using the command-line tool]]
* [[API|Using the API]]
* [[otserver|Using the server]]
* [https://github.com/Open-Transactions/Moneychanger Moneychanger (Qt-based Desktop Client)]

This product includes software developed by Ben Laurie for use in the [https://github.com/benlaurie/lucre Lucre] project.

Credit for the OT logo goes to: [http://www.michpalmer.com/ moltenmich]

=== Mailing list and IRC ===

Mailing list: ot-dev@opentransactions.org

[http://opentransactions.org/mailman/listinfo/ot-dev_opentransactions.org Subscribe to mailing list]

IRC channel: '''#opentransactions''' on irc.freenode.net

=== Sponsors and Contributors ===

The OT community gratefully acknowledges the support and contributions of the following individuals and businesses to OT development: Chris Odom, Cameron Garnham, Randy Waterhouse, [[Monetas]].

=== Install Programs ===

[http://nightowl.cc/Moneychanger.dmg Mac OSX install for Moneychanger GUI] Self-contained.
<br />Note: This Mac install of Moneychanger includes the notary server as well.<br />It can be found at: /Applications/moneychanger-qt.app/Contents/MacOS/opentxs-notary

[https://bitcointalk.org/index.php?topic=77301.msg859040#msg859040 (old) Windows binary installer ]

=== White Paper ===

[http://www.opentransactions.org/open-transactions.pdf Open-Transactions White Paper]

=== Source Code ===

[http://github.com/Open-Transactions/opentxs Open-Transactions source code on github] (core library, client API, and 'opentxs' command-line client)

[http://github.com/Open-Transactions/opentxs-notary The Open-Transactions notary server on github] (Install OT core first)

[http://github.com/Open-Transactions/Moneychanger Moneychanger GUI source code on github] (Install OT core first, and then build Moneychanger with the latest version of Qt Creator)

Main Page

2015-07-08T22:12:56Z

FellowTraveler: /* Open-Transactions */ added bold

==Open-Transactions==

'''[http://www.opentransactions.org/open-transactions.pdf Click here for white paper.]'''

The Open-Transactions project is a collaborative effort to develop a robust, commercial-grade, fully-featured, '''free-software toolkit''' implementing the [[OTX|OTX protocol]] as well as a full-strength '''financial cryptography''' [[List_of_Classes|library]], API, GUI, command-line interface, and prototype notary server. The project is managed by a worldwide community of volunteers that use the Internet to communicate, plan, and develop the Open-Transactions toolkit and its related documentation.

===Financial Cryptography===

Financial cryptography means using using strong cryptographic techniques to create secure financial instruments, such as digital signing to create non-repudiable contracts, and encryption to create untraceable digital cash. In OT, transactions are unforgeable, receipts are destructible, and balances cannot be falsified or changed without user consent. OT is able to prove all balances, as well as which instruments are valid, and which transactions have closed, without storing any history except the last signed receipt.

Open-Transactions implements financial instruments as Ricardian Contracts; contracts which can be understood both by humans and manipulated by software.

All contracts in Open-Transactions use the same basic structure: all parties involved sign an agreement which is notarized by an independent third party witness. This technique is known as [[Triple-Signed Receipts]]. Importantly, transactions are formed and signed on the client side first, before being notarized by any server. An OT client is thus ensured that an OT notary server cannot falsify his receipts against his will, since the server can't forge the client's signature.

This basic structure can be built upon to create many types of financial instruments.

===Financial Instruments===

Financial instruments are any representation of a financial agreement between two or more parties.

The simplest financial instrument is a deposit agreement. A custodian of some asset (legal tender, or maybe gold) stores it on behalf of a depositor and agrees to redeem it on demand when presented with proof of a valid claim on the asset.

Other types of financial instruments include securities, of which there can be many variations. A security is an instrument that entitles the bearer to a certain revenue stream, either because it represents a loan or perhaps because it represents equity in a business.

Financial instruments in Open-Transactions have an issuer, who creates the contracts and is responsible for fulfilling the terms, and one or more bearers. Financial instruments are liabilities of the issuer owed to the bearers.

===Working with Financial Instruments===

Open-Transactions is designed to provide the highest security possible for both the issuers and bearers of financial instruments. Servers in Open-Transactions act as notaries which can witness and confirm balances, but cannot change them. Every party associated in a financial instrument can prove their balance to any other party, and no party can alter the balance of any other party without their agreement. Even a malicious notary cannot do this.

Open-Transactions represents quantities of a given unit type as deposit agreements, which are signed by the bearer and a notary.

Portions of a balance may be transferred between users via several asset-independent transaction types, including:

; Transfers
: An atomic movement of funds from one account to a different account, like a bank account-to-account transfer.
; Cheques
: A payment which is not deducted from the sender's account until the recipient claims it.
; Vouchers
: A payment which is deducted from the senders account at the time of creation.
; Invoices
: A payment request which the recipient can opt to pay from any of his accounts.
; Cash
: Anonymous cryptographic tokens which can be securely redeemed by the recipient without revealing the sender.
; Market offers
: Open agreements to exchange a given quantity of one instrument type for a given quantity of another instrument type.
; Smart Contracts
: Customizable agreements between multiple parties, containing user-defined scripted clauses, hooks, and variables.

==Use Cases==

===Encouraged use cases===

Encouraged uses cases are officially supported by Open-Transactions.

====Deposit accounting====

Entities that hold assets on behalf of depositors can use Open-Transactions to issue promissory notes as negotiable instruments.

Examples of such depositories includes:

* Precious metals
* Central bank currencies
* Cryptocurrencies

====Payments====

Users of OT negotiable instruments can authorize recurring payments to pay for services which operate on a billing cycle.

====Bearer Securities====

The negotiable instruments created by Open-Transactions can be used as the basis for financial products such as loans.

===Discouraged use cases===

Discouraged use cases are not supported by Open-Transactions, either because they violate the security requirements, or because they conflict with the philosophical goals of the project.

In many cases, discouraged use cases may be achievable, but users are required to create and support their own smart contracts.

====Third party balance editing====

The only entity in Open-Transactions that can edit a balance is the holder of that balance receipt. Open-Transactions does not and will not include any functionality to bypass this design decision.

==More Information==

* [[About|About Open-Transactions]]
* [[Installation]]
* [[opentxs|Using the command-line tool]]
* [[API|Using the API]]
* [[otserver|Using the server]]
* [https://github.com/Open-Transactions/Moneychanger Moneychanger (Qt-based Desktop Client)]

This product includes software developed by Ben Laurie for use in the [https://github.com/benlaurie/lucre Lucre] project.

Credit for the OT logo goes to: [http://www.michpalmer.com/ moltenmich]

=== Mailing list and IRC ===

Mailing list: ot-dev@opentransactions.org

[http://opentransactions.org/mailman/listinfo/ot-dev_opentransactions.org Subscribe to mailing list]

IRC channel: '''#opentransactions''' on irc.freenode.net

=== Sponsors and Contributors ===

The OT community gratefully acknowledges the support and contributions of the following individuals and businesses to OT development: Chris Odom, Cameron Garnham, Randy Waterhouse, [[Monetas]].

=== Install Programs ===

[http://nightowl.cc/Moneychanger.dmg Mac OSX install for Moneychanger GUI] Self-contained.
<br />Note: This Mac install of Moneychanger includes the notary server as well.<br />It can be found at: /Applications/moneychanger-qt.app/Contents/MacOS/opentxs-notary

[https://bitcointalk.org/index.php?topic=77301.msg859040#msg859040 (old) Windows binary installer ]

=== Source Code ===

[http://github.com/Open-Transactions/opentxs Open-Transactions source code on github] (core library, client API, and 'opentxs' command-line client)

[http://github.com/Open-Transactions/opentxs-notary The Open-Transactions notary server on github] (Install OT core first)

[http://github.com/Open-Transactions/Moneychanger Moneychanger GUI source code on github] (Install OT core first, and then build Moneychanger with the latest version of Qt Creator)