Difference between revisions of "Future Direction"

From Open Transactions
Jump to navigation Jump to search
(Created page with "'''''Every camera phone is a potential customer!''''' <br>'''''Every computer monitor is a potential cash register!''''' How can this be? It's actually pretty simple: '''2D ...")
 
m (chaumian)
 
Line 98: Line 98:
  
 
Featuring:  
 
Featuring:  
* '''Untraceable Digital Cash''' (real blinded tokens).  
+
* '''Chaumian Digital Cash''' (real blinded tokens).  
 
* '''Pseudonymous User Accounts''' (&quot;user account&quot; == PGP key).  
 
* '''Pseudonymous User Accounts''' (&quot;user account&quot; == PGP key).  
 
* Many '''[[Instruments|Financial Instruments]]''' ([[Sample-Cheque|cheques]], [[Sample Cash|cash]], vouchers, invoices, transfers, etc).  
 
* Many '''[[Instruments|Financial Instruments]]''' ([[Sample-Cheque|cheques]], [[Sample Cash|cash]], vouchers, invoices, transfers, etc).  

Latest revision as of 23:47, 18 September 2013

Every camera phone is a potential customer!
Every computer monitor is a potential cash register!

How can this be? It's actually pretty simple:

2D Barcodes

STEP ONE:
1) The cashier, Alice, rings up Bob's purchase. His total is: 98 Clams.
2) The "cash register" (Alice's computer, running OT) creates an invoice with a total of 98 Clams.
3) The "cash register" posts the invoice at a url: https://AliceStore.com/invoices/kd893734j
4) The "cash register" generates a barcode which contains the URL, and displays it on the screen.

STEP TWO:
1) Bob pulls out his camera phone, running an OT wallet... with a software barcode reader...
2) Beep. Bob's phone scans the barcode on the screen, reads the URL from it, and downloads the invoice.
3) Bob's phone displays: "AliceStore, 98 Clams".
4) Bob clicks "accept purchase", and his wallet runs the invoice through his account.

Purchase complete! With receipts on both sides.

Using any computer monitor, and the camera phones in everyone's pocket, you can compete head-to-head with the install base of the credit card companies themselves, and entirely replace the credit card with an alternate viable system, using technologies that are already in everyone's pocket!



Future (planned or potential) types of financial instruments that should be added to Open Transactions:

Stocks A stock is similar to a normal asset type. Someone (who controls the key and signs the currency contract) issues the stock the same as you would issue any other currency: by uploading the currency contract to the OT server. That entity (the issuer) therefore also controls the issuer account. From there, any other person can open a stock account, the issuer can give him some stock, and they can now write cheques, trade the stock on markets, etc the same as any other asset type. What are the differences, then, compared to other asset types? 1) Need the ability to pay dividends to the shareholders. Let's say you hold 100 shares of Pepsi stock, and they just paid out $3 per share in dividends? In that case, a $300 cheque (in dollars) would show up in your Nymbox (in a message). 2) Notice the dividend is paid in a different asset type than the stock itself. (Dollars versus Pepsi shares.) Thus, the cheque in your box. 3) Issuer needs the ability to select a large chunk of dollars, and have the OT server automatically distribute those dollars to the shareholders, according to the terms in the stock's contract. 4) Might want to have the number of shares issued, restricted to a set number, based on the stock's contract. 5) Similarly, might want to be able to issue several different classes of shares. (For now this is easily done by using a separate contract for each.) 6) Rules about transfer of ownership. Some corporations might have rules about the sale or transfer of shares. These ideally should be described in the contract and enforced by the server. Certain forms of stock, therefore, might not allow cash instruments, or might require signatures from X out of Y corporate agents before the "name on the books" is allowed to be changed.

Bonds Bonds are similar to Stocks (in implementation) since Stocks need the ability to pay dividends, and Bonds need the ability to pay interest. The big difference here is, dividends are unpredictable (based on profits) whereas interest payments are predictable (based on the interest rate.) This means that rules could be defined in the Bond Contract, about how much cash must remain in the reserve account to cover interest payments. The server could enforce these rules, and provide transparency, to help markets accurately assess the risk profile of any given bond contract.

Funds OT already supports basket currencies. Stocks could be bundled, using baskets, into funds. Then shares in those funds could be issued and traded on markets the same as any other asset type.

Collateralized Debt Obligations Similarly, different classes of bonds could be grouped (based on risk and other factors) into specific tranches. A currency contract is then issued for each tranch, allowing that issuer to create shares in it, which can then be traded on markets. Funds and CDOs will have an internal server-controlled account where the dividends and interest payments are deposited. The OT server can automate the process of dividing up the proceeds (from funds and CDOs) to the shareholders, according to whatever rules are defined in the currency contract. When any shareholder wishes to cash out, he sells his fund shares on the market, the same as selling off any other shares.

Multi-Signer Accounts Right now accounts only support a single signer. (The owner.) At some point I need to add an optional list of signers to accounts. This way you could have joint accounts, corporate accounts, and "X out of Y" rules defined about the authorization needed for transactions on a given account.

Escrow Escrow is definitely coming to Open Transactions. In its most simple form: 1) Alice puts certain assets (voucher, cash, or other instrument) into Escrow. 2) Bob also puts certain assets into Escrow. 3) Both Alice and Bob can view the assets, which the server confirms for them. 4) Once both Alice and Bob have both agreed to make the trade, the Server performs the trade.

From there we'd want to add:

  • Signing an escrow contract in advance that allows custom terms.
  • Configuration of which parties are adding assets, and which parties are allowed to view the assets.
  • Configuration of how many parties must sign off on closing the transaction (X out of Y algorithm.)
  • Many contracts may be self-closing (by putting terms into the contract so the server can process them.)



New thoughts (voting groups, and group control of funds):

  • I realized that OT is the ideal library to add classes for voting protocols.
  • ...Using existing asset accounts (for share ownership of stocks), OT is capable of weighted voting.
  • ...Using the existing mint and token classes, OT is capable of secret ballots. (Using chaumian blinding...)
  • ...Using existing inboxes, ballots could be sent to relevant Nyms.
  • Then I realized that a class could be written, a VOTING GROUP, maybe "OTVoterGroup", that would have a list of members, or a way to verify members (based on stock ownership, etc) and that could have its own rules about how decisions are made. Such as, single member authorization, single member veto, majority vote, winner takes all, preferential voting, 2/3rds vote, 3/4s vote, X out of Y, etc. CONFIGURABLE.
  • These voting groups could be used ALL OVER the place... They can be used for multi-signer accounts, they can be used for escrow agreements, they can be used for corporate ownership or agency, they can be used any time you have to make a decision about something.
  • Then I realized that a "political body" is just a collection of voting groups, with the ability to edit its own laws. For example, one model of the USA voting process would have the voters as one voting group, the Senate as another voting group, and the House as another voting group. The first group merely selects the members of the other two groups, who edit the laws.
  • This is also like a corporation. The shareholders are one voting group, with weighted voting and proportional representation on the board of directors, who are another voting group. The shareholders only job is to select the members of the board. The board is responsible to edit the bylaws, and to select the members of the executive team, who are another voting group, with a "dictator" (CEO).
  • Then I realized that what corporations add, starting at the executive team, is the hierarchical distribution of money; the ability to open asset accounts and to have funds flow to them, based on the decisions of the voting groups.
  • I saw that the entire hierarchy of employees in a corporation is really just nested departments, the same object repeated inside copies of itself, with funds flowing down and up the hierarchy, with rules set from above.
  • The board just selects the dictator of the top "department" (the CEO) and the rest of the departments are created recursively from there, growing organically based on need, each one able to receive funds from above, and distribute funds to departments below (with full ability to view all their receipts, and the minutes from their voting groups)
  • This is all possible from only adding a couple of classes: voting group, ballot, political body, and department.
  • I think those 4 classes would enable everything from a model of a real democracy, to a model of a real corporation, to a model of a real multi-constituency republic, or really any political / financial structure that you wanted.
  • For a corporation, sales from stock go into the main account, and the executives distribute it from there, paying dividends back out to shareholders whenever they want to push the button.
  • A corporation itself would be an actual "articles of incorporation" filed as a contract (probably a SMART CONTRACT)
  • The bylaws of the corporation would be edited by the board, just as the bylaws of a democracy might be edited by the members, and these could contain various scripts that trigger at certain key times, allowing them to configure their organization however they wanted to, with money flows, weighted votes, secret votes, ballots in the inbox for any committee decisions, etc.

Think of how powerful that could be, just from adding a few extra classes!! Most of it uses pieces that are already working.



.....Integrate this software with as many legitimate entities as possible. Such as community currencies and LETS systems. Make transaction processors a normal part of the Internet with many legitimate uses and users, and integrated everywhere.

.....Integrate with as many profitable entities as possible. Such as Tor banks, online casinos, and any other online business that benefits from offering anonymity to their customers. Find specific niches where the software adds value now. Let the money drive it.

.....Integrate with anonymous networks. Networks such as Tor, I2P, Freenet, etc could all benefit from an anonymous payment mechanism. Open Transactions wallet software should also be a file-sharing client and node for anonymous networks. They should be one and the same.

.....Android client, Windows client, iPhone client, iPad client, Java client, Mac OSX client...

.....High-level interfaces for developers. Build this library into a multitude of different software apps.

.....Integrate with popular Wordpress payment processing plugins. So the Internet can become digital-cash enabled overnight...

.....Integrate with Anonymous Remailers, Nym Servers, and other projects that would benefit.

.....Get a network of servers up and operating, as well as a bunch of different issuers, so that the first real basket currencies can be issued.



Diagrams: Architecture Overview, Fully-Anonymous (cash only), and Pseudo-Anonymous (using accounts).

WHAT IS "Open Transactions" ?

Featuring:

  • Chaumian Digital Cash (real blinded tokens).
  • Pseudonymous User Accounts ("user account" == PGP key).
  • Many Financial Instruments (cheques, cash, vouchers, invoices, transfers, etc).
  • Anyone An Issuer (Ricardian-style Contracts)
  • Triple-Signed Receipts ("asset account" == the receipt).
  • Basket Currencies
  • NEW! Markets with Trades
  • NEW! Payment Plans
  • NEW! Native API now available in Java, Ruby, Python, PHP, Perl, C, C++, Objective-C, C#, Tcl, and LISP.
  • NEW! Open Transactions as a Web Service (XmlRpc / HTTP transport now available.)
  • Soon: Stocks that pay dividends, Bonds that pay interest, and Collateralized Debt Obligations.
  • Soon: 2-D Barcodes to make possible "Any screen a cash register" and "Any camera phone a customer."
  • Soon: Multi-signer Escrow

Please see the Use Cases, FAQ, Business Cases, Install Notes and the Release Notes