http://opentransactions.org/wiki/api.php?action=feedcontributions&user=Cryptoman&feedformat=atomOpen Transactions - User contributions [en]2024-03-28T10:17:10ZUser contributionsMediaWiki 1.32.2http://opentransactions.org/wiki/index.php?title=Install_OpenSSL&diff=126Install OpenSSL2013-06-12T17:24:33Z<p>Cryptoman: Created page with "Please go to [https://github.com/FellowTraveler/Open-Transactions/tree/master/docs The Documentation Directory] for up-to-date notes."</p>
<hr />
<div>Please go to [https://github.com/FellowTraveler/Open-Transactions/tree/master/docs The Documentation Directory] for up-to-date notes.</div>Cryptomanhttp://opentransactions.org/wiki/index.php?title=Warehouse_Receipts&diff=125Warehouse Receipts2013-06-12T17:22:44Z<p>Cryptoman: Created page with "'''WAREHOUSE RECEIPTS, TITLE OF PROPERTY, and ARBITRATION''' INITIAL UNDERSTANDING The current system is account-based, meaning that the instruments always refer to assets t..."</p>
<hr />
<div>'''WAREHOUSE RECEIPTS, TITLE OF PROPERTY, and ARBITRATION'''<br />
<br />
INITIAL UNDERSTANDING<br />
<br />
The current system is account-based, meaning that the instruments always refer to assets that are in some account. (That is, even if you are operating cash-free, with no accounts, there is still a server account somewhere containing the ''backing funds'' for your cash. This is a security mechanism.)<br />
<br />
So if I have a cheque for 10 clams, it's drawn against a clam account, and if the clams aren't there, the cheque will bounce.<br />
<br />
Similarly, the cash tokens are also drawn against an account. When you withdraw cash, the server takes it from your clam account, and adds it to the server's clam account for backing cash, and then issues you the appropriate amount of cash. Later on, when someone deposits the cash note, assuming it's a valid note, the server then pulls 10 clams back out of its server backing account, and puts them into the depositor's account. (This is similar to how it works when you exchange in/out of a basket currency.)<br />
<br />
Having the server &quot;double&quot; the cash in a backing account is a way of protecting in case of security breach in the token code. After all, even if you have a bad token that slips through, the server still can't give you any more clams than are stored in the clam account. The server can never have more notes out than it has backing assets to cover them. The account would just go empty, which, if the note was still good, would reveal that the token system had been compromised.<br />
<br />
As we can see, cheques and cash are very similar, in that they are both merely a transfer mechanism; an instrument to be redeemed, when the &quot;real value&quot; is actually sitting in an account somewhere. Both cheques and cash have ACCOUNT BACKING. The only difference is, the cheques are traceable and they use transaction numbers for invalidating instruments, whereas the cash is untraceable, and it uses a spent token database along with expiring mint series for invalidating instruments.<br />
<br />
I should also point out that the &quot;account backing&quot; on the server side, when it really comes down to it, is really nothing more than ''the signed agreement from the issuer, authorizing a certain amount of a specific currency, as described in its currency contract.''<br />
<br />
'''NOW WE TURN TO WAREHOUSE RECEIPTS...'''<br />
<br />
What if the backing for the [cheques/cash] was not account based, but rather, was warehouse based?<br />
<br />
What if the OT server actually stored a whole warehouse of serial-numbered (and signed) &quot;bars of gold&quot; from the issuer?<br />
<br />
Let's further assume that these &quot;bars&quot; are all otherwise identical, or that they are all in identical groups for denominations (1 clams, 5 clams, 10 clams, 20 clams, 50 clams, etc matching the cash denominations that are described in the currency contract.) This means, again, that each individual group contains notes that are all otherwise ''identical, besides their serial number,'' and are all signed by the issuer.<br />
<br />
Now, can't the existing OT cash token mechanism be used for performing untraceable transfers of these serial numbers?<br />
<br />
If I wanted to withdraw 10 serial-numbered bars of gold into untraceable cash form, couldn't the server just set aside 10 clams worth of the serial numbers back in the warehouse, and then issue me a matching number of (untraceable) cash tokens? Then whenever the cash tokens are redeemed in the future, the OT warehouse just takes some serial numbers out from the &quot;circulation&quot; pile and puts them back into the &quot;warehouse&quot; pile.<br />
<br />
I don't really care what ''specific'' serial numbers I get from the warehouse when I redeem the cash notes, as long as the ''asset type'' is the same, and the ''quantity'' is the same. The exact serial numbers cannot be matched from withdrawal to deposit, only the quantity (since the tokens are blinded and their token IDs are different every time they are deposited.)<br />
<br />
In fact, if only the quantity is actually being tracked, and the individual tokens cannot be matched to the individual serial numbers, it forces one to ask: Why not use the existing account-based system, since it's functionally identical? Why warehouse all of these signed receipts from the issuer at all, instead of just storing a single balance agreement like we do with accounts?<br />
<br />
Because perhaps there are cases where the existence of explicitly numbered and signed notes from the issuer (versus an account balance) provides additional evidence that the digital assets, after having been issued, have now passed beyond the issuer's control and into circulation.<br />
<br />
Notice the Federal Reserve is never held responsible for fraudulent transactions using their currency, though E-Gold is... Why? This is the exact distinction. Because the Federal Reserve has released their currency into circulation and they have no more control over it. Whereas E-Gold, the issuer of a currency, has direct control over all of the transactions of their currency -- and therefore they are held responsible to track and report all of those transactions.<br />
<br />
Warehousing also more strongly presents the transaction server as merely performing warehousing services (which is true). That is, using the Chaumian cash tokens to serve as the &quot;warehouse receipts&quot; while the actual serial-numbered &quot;bars of gold&quot; are stored back in the &quot;warehouse&quot; on the OT server.<br />
<br />
In this scenario, the OT server could be configured to run in &quot;cash only&quot; mode--so that there aren't any accounts at all. Instead, there is only the warehouse--and an interface for token exchanges. (Consider the consequences if such a server were to be destroyed or stolen: the issuer could cancel the serial numbers and issue them on a new server, and the users could produce their signed receipts to resolve all disputes.)<br />
<br />
I think, BTW, that all of the technical properties are the same whether you use an account or a warehouse. Either can be used in ''cash-only mode''. Either can have the issuer and the server as separate entities.<br />
<br />
It seems to me, rather, that the real difference is ''legal'', in that it makes a stronger legal clarification (in my non-lawyer opinion) that ''real'' digital assets, with serial numbers, have been issued and released into circulation, and that ''the issuer has no more reach over them,'' and that many other entities control them now, and that none of the parties involved, including the issuer or even the OT transaction server itself, manages any accounts for any users, nor has any power to view any of the transactions.<br />
<br />
<br />
-----<br />
<br />
'''CLEAR TITLE for UNIQUE PIECES OF PROPERTY'''<br />
<br />
From all this, now we can imagine an instrument where EACH serial numbered item, instead of belonging to an identical group, actually refers to a ''different contract ID each time.'' '''This is not useful for a circulating currency, but it ''is'' useful for attaching clear and transferrable title to unique pieces of property.'''<br />
<br />
Imagine if I have a car, and I want to put it in the &quot;warehouse&quot;. First I draw up a contract describing the car, containing its VIN number, and various other identifying characteristics. Now (as the car's owner) I upload the contract to the server in order to &quot;register&quot; the existence of this new property. Of course, I am already the owner of the car in reality. Registering it this way, in a commonly trusted registry, just gives me more proof and leverage regarding this fact. My public key is included in the original contract, and I have also signed it with that key. (So only ''I'' may upload it...)<br />
<br />
The server doesn't have to issue a new currency based on that contract (like it normally would when a new contract is uploaded...) Instead, the server just stores the contract on a registry. It hashes the contract (producing the ID for the car) and lists that contract as one of my &quot;assets&quot; (since I am the one who uploaded it.) No, I cannot use that ID to open an asset account, since it's not a currency contract, but rather, a property contract. But I CAN &quot;store&quot; it on the server as my asset, and transfer it to someone else, or sell it, or put it into escrow, ETC! It becomes title of property.<br />
<br />
How will this all work?<br />
<br />
For example, when I first upload the car's contract, a transaction number is issued and a coupon is given to me, referencing the car's contract ID as well as the transaction number, which is signed out to me. (Let's say, transaction number 5.)<br />
<br />
Next I sell the car to my friend. He puts 1000 clams into escrow, where I also put the car. Once BOTH of us sign off on the escrow instrument, the server gives the clams to me and the car to my friend. The server is able to verify both instruments, so both parties know they are valid.<br />
<br />
As you can see, escrow MUST be built into the server for people to even be able to safely negotiate unique pieces of property! Unlike account-based forms of property, which have access to markets, there is no way to safely guarantee that you'll get the money in exchange for your car... unless you have escrow! That is what makes it possible for people to verify that both instruments are valid, and to verify that the exchange will be two ways. (Outside of markets, this restriction is also true for account-based instruments. Without escrow, each transfer is one-way and you have no guarantee that the corresponding payment will be made in return. Escrow enables safe two-way transfers.)<br />
<br />
When the car is given to my friend, the server burns my old coupon, which was transaction #5 in reference to my car's ID, and then it generates for my friend a NEW coupon, say with transaction # 9, ALSO in reference to the same car ID that my original coupon referenced. (Now my friend has the newest, and the only valid, coupon for that car! He is now the owner.)<br />
<br />
NOW: if I try to redeem the old car coupon, the OT server says, &quot;Sorry, 5 is an old transaction number, and it's no longer any good. That's a bad coupon.&quot; The server even has a signed receipt from me by this time, proving that transaction #5 is no longer signed out to me. But when my ''friend'' tries to redeem his coupon (say, to sell the car to someone else) the server knows that ''his'' coupon ''is'' valid, since the transaction number on it is good, so the server performs the transfer as requested. In the event of any dispute, my friend can prove his title by producing his last signed receipt from the server (showing that transaction #9 is still signed out to him), and by producing his coupon, which is signed by the server, and which shows that transaction #9 is in reference to a car contract, and is made out to him!<br />
<br />
IN THIS WAY, INDIVIDUAL PIECES OF PROPERTY can be registered to their initial owners, and then transferred securely to other people, providing clean title!<br />
<br />
And what is that coupon really, but a form of voucher? On OT, a voucher is like a cashier's cheque... it's a cheque guaranteed by the server. The coupon has an asset type ID, just like a cheque (the contract ID)... it has a transaction number, just like a cheque... it is functionally identical to a cheque! (Or, a voucher, since it's guaranteed by the server instead of by a user account.) The only difference is that the instrument transfers a unique piece of property, instead of a specific AMOUNT of an asset type. (So it has no amount.)<br />
<br />
Therefore, since the cheque instrument can clearly be adapted for transfers of property title, couldn't the cash instrument be similarly used for unique items, just as the cheque is?<br />
<br />
That is, instead of putting a transaction number on the note, which is traceable, put a BLINDED TOKEN ID on the note, which is untraceable... The note can still be signed, and still be considered valid, even though the server has no way of knowing who the bearer is!<br />
<br />
Of course, if the server gives ''me'' an &quot;untraceable&quot; note for a certain car, and then ''you'' deposit it, the server still clearly knows that I transferred it to you! (Even though the server didn't know the actual token ID, it can still clearly see both ends of that transfer. This is because the car itself is unique and can only belong to one person at a time. It I withdrew it, and you deposited it... the untraceable token ID by itself, does us no good...)<br />
<br />
'''UNTRACEABLE TRANSFER of UNIQUE PIECES OF PROPERTY'''<br />
<br />
BUT! If ALL titles being transferred via the cash instrument were additionally transferred using a &quot;title-only interface&quot; (similar to a &quot;cash only interface&quot; that appears in the OT diagrams), where all actual &quot;title exchanges&quot; were performed BY THE SAME ACCOUNT EVERY TIME, then all of those property transfers become untraceable! In effect, they become bearer coupons to unique pieces of property. Just like any other OT cash, you can see the Nym who withdrew it, and you can see the Nym who deposits it, ''but you can't see all the Nyms who had it in between!''<br />
<br />
I find it interesting, by the way, that the storage of ''unique'' items in these warehouses, must lend some weight to the legal argument that ''serial-numbered'' items can also be stored in such warehouses.<br />
<br />
<br />
-----<br />
<br />
'''ARBITRATION'''<br />
<br />
Will Strong Encrypton Protect Privacy and Make Government Obsolete?<br />
<br />
(From http://www.independent.org/events/transcript.asp?eventID=20): &quot;You and I sign a contract. In the contract, we specify a private arbitrator. The contract includes the private arbitrator’s public key. The contract is digitally signed by both you and me. Now, you think I violated the contract. You demand arbitration. The arbitrator rules that I owe you damages. I refuse to pay. The arbitrator writes a brief statement that I agreed to—that he would be the arbitrator of disputes, that he gave a verdict, and that I refused to pay the damages. Digitally signs it and gives it to you. You now have a package. That package consists of the original contract which I digitally signed, so provably I agreed to it, and the arbitrator’s verdict, which he digitally signed, so provably the arbitrator I agreed to, said that I cheated. You may now e-mail that package to anybody else in the industry. — You want the arbitrator who gets the right result at low cost. This is a market mechanism for generating efficient law for the private market.&quot;<br />
<br />
'''What Open Transactions adds to this picture''' is that due to the [[Triple-Signed Receipts]] (with a transaction number being &quot;signed out&quot; to a specific Nym as long as its instrument is still outstanding), ''such &quot;Verdict&quot; packages can thus be amended and revoked as necessary'', according to their terms. Whether a debt has been paid, an arbiter needs to reverse a mistake, or an instrument is simply old or expired, parties can prove instrument status and validity simply by producing their last signed receipt.<br />
<br />
How would this work on OT?<br />
<br />
Alice and Bob agree to terms, and communicate them to the Judge (arbitration service.) The Judge actually issues the contract on the OT server (terms may be encrypted if the parties prefer to keep them private, with the relevant public keys available in the contract.) The Judge uses one of his transaction numbers (#13) to issue the contract onto the server.<br />
<br />
From there, Alice and Bob can both download the contract from the server (or a hash of it) and examine it to be sure that the terms and arbitrar are all correctly outlined. (All they need is the contract ID, which is a hash of the contract.)<br />
<br />
Once they are satisfied, each submits a new transaction, under a new #, requesting to be bound to the original contract (by ID). For example, Alice burns transaction #24 to sign on, and Bob burns transaction #45. Both request to sign on to the same Contract ID.<br />
<br />
As long as the contract remains open, the Judge will have #13 signed out, Alice has #24 signed out, and Bob has #45 signed out. Therefore none of them can claim they aren't responsible for those numbers, since their #s appear on all of their receipts. (Until the Judge decides to RELEASE the contract, which frees the parties, but this also delivers a receipt to them all, containing the Judge's signed request to do so.)<br />
<br />
Later there is a dispute about the fulfillment of the agreement (a dispute filed by either party, which causes a dispute receipt to go into the Judge's inbox). Alice says Bob is refusing to do the floor tiles. Next the Judge makes a decision, which also creates a receipt into each party's inbox. He decides that Bob has broken the contract. (Optionally this history can also be stored on the server and queried based on ContractID--some contracts may have publicly available history in this way.)<br />
<br />
At this point Alice now has a signed receipt showing the original contract, showing Bob's original request to sign on and his transaction #45 and his signature, and also the Judge's signature on the ruling that Bob violated the agreement, showing the Judge's transaction #13, and of course also showing Alice's #24.<br />
<br />
Alice can now present this receipt in any Court, or to any entity, proving the ruling of the arbitration Judge. If Bob wishes to disprove her to the same entity (or on a registry somewhere), all he must do is produce a newer receipt showing that he's not responsible for #45.<br />
<br />
Of course if the Judge is an entity with little credibility, then no one may care whether the number is on Bob's receipt or not. Bob may also optionally remove the number from his future transaction statements by disputing the ruling, but he cannot get away with this, since the same dispute process would undoubtably drop a receipt into the inboxes of all concerned parties, so they'd all have his signature on the dispute request. Later any of them could produce this in order to prove what happened.</div>Cryptomanhttp://opentransactions.org/wiki/index.php?title=Voting_Groups&diff=124Voting Groups2013-06-12T17:19:03Z<p>Cryptoman: Created page with "New thoughts (voting groups, and group control of funds): I realized that OT is the ideal class library to add objects performing '''voting protocols''' for group control of ..."</p>
<hr />
<div>New thoughts (voting groups, and group control of funds):<br />
<br />
I realized that OT is the ideal class library to add objects performing '''voting protocols''' for group control of contracts and asset accounts.<br />
<br />
Using the existing system of asset accounts, '''OT is capable of weighted voting (for share ownership of stocks.)'''<br />
<br />
Using the existing mint and token classes, '''OT is capable of secret ballots. (Using chaumian blinding.)'''<br />
<br />
Using existing inboxes, ballots could be sent to relevant Nyms.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.''<br />
<br />
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.<br />
<br />
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).<br />
<br />
Then I realized that what corporations add 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.<br />
<br />
I saw that the entire hierarchy after that '''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.'''<br />
<br />
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.)<br />
<br />
This is all possible from only adding a couple of classes: voting group, ballot, political body, and department.<br />
<br />
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.<br />
<br />
A corporation itself would be an actual “articles of incorporation” filed as a contract (probably a SMART CONTRACT)<br />
<br />
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.<br />
<br />
Think of how powerful that could be, just from adding a few extra classes!</div>Cryptomanhttp://opentransactions.org/wiki/index.php?title=TODO&diff=123TODO2013-06-12T17:15:13Z<p>Cryptoman: Created page with "UPDATE: SOURCE CODE HAS BEEN RELEASED! NOTE: All new issues will be going into the Issues section of this github page. This is stored here for historical reasons. ----- Ge..."</p>
<hr />
<div>UPDATE: SOURCE CODE HAS BEEN RELEASED!<br />
<br />
<br />
NOTE: All new issues will be going into the Issues section of this github page.<br />
This is stored here for historical reasons.<br />
-----<br />
<br />
Get a test server up and running somewhere...<br />
-----<br />
Need to add Fees (for issuers and server operators). They will just be another transaction item type. <br />
(User must agree to all items in a transaction if the user wishes to process the transaction. Fees will be added as additional items on the transaction types that are already functional.)<br />
<br />
-----<br />
Need security audit done. Need to make sure buffer overflows are all cleaned up and hopefully get some hackers to blitz away at it.<br />
----- <br />
Need to validate carefully whenever converting between string and long. This will require a good once-over.<br />
----- <br />
When uploading currency contracts, need to validate them in a separate process before importing to the main server. (Currently validating in-server.)<br />
-----<br />
When uploading currency contracts, need to generate the mint keys in a separate process. (Currently requires the server operator to run otCreateMint utility by hand, or the server would freeze while the keys were generating.)<br />
----- <br />
Need to add support for PGP private keys. Right now the software supports PGP '''public''' keys (like on contracts, etc), but the user must still have an OpenSSL key pair in order to have a private key so that he can create accounts.<br />
-----<br />
Denominations are currently hardcoded to:<br />
<br />
pMint->GenerateNewMint(ASSET_ID, m_nymServer, 1, 5, 10, 25, 100, 500, 1000, 2000, 10000, 100000);<br />
<br>// penny, nickel, dime, quarter, $1, $5, $10, $20, $100, $1000<br />
<br>Need to make this configurable in the currency contract.<br />
<br />
-----<br />
<br />
NEED GUI CLIENTS: (This is where you come in!)<br />
<br>--- Mac Client<br />
<br>--- Windows Client<br />
<br>--- Java Client<br />
<br>--- Web Client<br />
<br>--- iPhone Client<br />
<br>--- iPad Client<br />
<br>--- Android Client<br />
<br />
-----<br />
SPENT TOKENS<br />
<br>--- DONE! (Version .2) Spent token database. I guess I'll throw these into a folder, too, based on hash of the token. Long term will be wherever the above Database questions are resolved.<br />
<br>--- DONE! (Version .2) Need to implement TOKEN EXPIRATION DATES so the spent token database never needs to get too large or be stored for too long. Wallets will handle automatically exchanging tokens as they approach expiration date.<br />
<br>--- DONE: (Mint Series and expiration..) Finished and in Release 0.2: Added expiry dates to the mints and started storing and verifying the transaction numbers.<br />
<br />
-----<br />
INTEGRATION<br />
<br>--- Need to find other projects that could benefit from integration. <br />
<br>--- Such as anonymous / pseudonymous email, proxies, and other services.<br />
<br>--- Perhaps parties who could serve as issuers<br />
<br>--- Or funders :P</div>Cryptomanhttp://opentransactions.org/wiki/index.php?title=SAMY_Hash&diff=122SAMY Hash2013-06-12T17:10:09Z<p>Cryptoman: Created page with "Samy Kamkar (of MySpace fame, for his Samy worm) suggested that the message digest algorithm should be a combination of 2 separate algorithms, XOR'd together, so that when the..."</p>
<hr />
<div>Samy Kamkar (of MySpace fame, for his Samy worm) suggested that the message digest algorithm should be a combination of 2 separate algorithms, XOR'd together, so that when the time inevitably comes that one of them is compromised, the system is still secure and a new one can be swapped in.<br />
<br />
Samy's website is: "http://samy.pl/"<br />
<br />
The SAMY hash in this implementation is:<br />
# Run the plaintext through WHIRLPOOL (which has a 512 bit output.)<br />
# Run the plaintext through SHA-512 (same output size.)<br />
# XOR the two outputs together.<br />
<br />
Open Transactions should still be able to read and process the other message digest algorithms, should a contract be signed with one. But the SAMY hash is the default hash algorithm.<br />
<br />
The SAMY hash, being the default behavior of OTIdentifier, is also the source of all of the IDs in OpenTransactions. All IDs are 512 bit and though they might appear unwieldy, consider these two points: (a) You can just double click it and the entire ID will be selected perfectly every time. (b) The actual user will probably not see the ID, or see it rarely, because he will be protected from such ugliness by a nice, attractive, client GUI for his favorite platform. Perhaps you will help to create that GUI.</div>Cryptomanhttp://opentransactions.org/wiki/index.php?title=Sample_Server_Contract&diff=121Sample Server Contract2013-06-12T17:08:05Z<p>Cryptoman: Created page with "<pre> -----BEGIN SIGNED CONTRACT----- Hash: SAMY <?xml version="1.0"?> <notaryProviderContract version="1.0"> <entity shortname="OT Test Server" longname="Open Transactions..."</p>
<hr />
<div><pre><br />
-----BEGIN SIGNED CONTRACT-----<br />
Hash: SAMY<br />
<br />
<?xml version="1.0"?><br />
<notaryProviderContract version="1.0"><br />
<br />
<entity shortname="OT Test Server" <br />
longname="Open Transactions Test Server" <br />
email="FellowTraveler@rayservers.net"<br />
serverURL="https://github.com/FellowTraveler/Open-Transactions/wiki"/><br />
<br />
<notaryServer hostname="ft.vm.to" <br />
port="7084"<br />
URL="https://github.com/FellowTraveler/Open-Transactions/wiki" /><br />
<br />
<!-- Perhaps the OT server is operating also on I2P --><br />
<connection <br />
protocol="otx"<br />
transport="i2p"<br />
address="lkjsdf908345klj.i2p"/><br />
<br />
<!-- Perhaps it is also operating on Tor --><br />
<connection <br />
protocol="otx"<br />
transport="tor"<br />
address="89234kjh398sdfj1.onion"/><br />
<br />
<condition name="backing"><br />
Neither FellowTraveler, nor Open Transactions, actually issue any<br />
currencies or digital assets, and does not back any of the same. <br />
You are solely responsible for whom you choose to trade with. <br />
</condition><br />
<br />
<condition name="audit"><br />
Open Transactions software is open source, and<br />
code audits are randomly performed by hackers in the <br />
open source community. Fellow Traveler also uses Valgrind. <br />
</condition><br />
<br />
<condition name="rate"><br />
There is no rate: I wrote this as free software for the open source<br />
community. However, funding or coding contributions are welcome. <br />
</condition><br />
<br />
<condition name="liability"><br />
Issuers are solely liable to perform according to<br />
the conditions specified in their asset contracts.<br />
</condition><br />
<br />
<condition name="mint"><br />
Float - the total quantity of any digital asset outstanding -<br />
is created by the issuer from his own mint, and signed by his private key.<br />
<br />
Disbursements from the Mint account are to be made on receipt of<br />
duly signed and public authorization from the Issuer. All<br />
disbursements from the Mint account are to be made to the single<br />
Currency Comptroller account identified by the authorization.<br />
<br />
From time to time, the Currency Comptroller may direct the<br />
Currency Manager to return digital assets to the Mint<br />
for the express purpose of reducing the float. Digital assets<br />
so delivered are to be deposited into the Mint account,<br />
thus reducing the float by that amount.<br />
</condition><br />
<br />
<condition name="privacy"><br />
The purchase, redemption and trading at Transactions.com normally<br />
are done on the basis of strong privacy. We will never release any of<br />
your information unless compelled by law.<br />
</condition><br />
<br />
<!-- KEYS --><br />
<br />
<key name="contract"><br />
- -----BEGIN CERTIFICATE-----<br />
MIICgjCCAeugAwIBAgIJAMaLd1ZsqDvKMA0GCSqGSIb3DQEBBQUAMHMxCzAJBgNV<br />
BAYTAlVTMREwDwYDVQQIEwhWaXJnaW5pYTEQMA4GA1UEBxMHRmFpcmZheDERMA8G<br />
A1UEChMIWm9yay5vcmcxGDAWBgNVBAsTD1NlcnZlciBEaXZpc2lvbjESMBAGA1UE<br />
AxMJU2VydmVyIENBMB4XDTEwMDkyOTAyNDMyN1oXDTIwMDkyNjAyNDMyN1owXjEL<br />
MAkGA1UEBhMCVVMxETAPBgNVBAgTCFZpcmdpbmlhMRAwDgYDVQQHEwdGYWlyZmF4<br />
MREwDwYDVQQKEwhab3JrLm9yZzEXMBUGA1UEAxMOc3BsYXQuem9yay5vcmcwgZ8w<br />
DQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOADov3TvgzuCxpSYs1lb9nKoDFIButv<br />
EJKFfT/EpPwrVuMP2vZ0ahy0BoVA4uH+FQwjLYJEBTIDO+IxuRc4Bxn42nUKCrBI<br />
QpitNlAMcv6PnNrCVyAn7GQ59bifHkV7NzWpLH0xFpLwa7GieCC4kz2GuhLDsaDq<br />
eS2K9WlWtpjzAgMBAAGjMzAxMAkGA1UdEwQCMAAwJAYDVR0RBB0wG4IOc3BsYXQu<br />
em9yay5vcmeCCWxvY2FsaG9zdDANBgkqhkiG9w0BAQUFAAOBgQBQ/NgyjFEtBWsF<br />
omfXVPX7aHKa4UkyHp6a2nCEEdSecNsAbe+s72yESpAwwc7KZCooBRvDX3P4O1bS<br />
bCzXFePdm7wisgV23DqycxmDAySbsn58dhKvRXf9Xy8l+mziYN6O+KAWXqvrO9W4<br />
KyHHBsoH+23N4dE7ho1sNBnrhvSmXw==<br />
- -----END CERTIFICATE-----<br />
</key><br />
<br />
<key name="certification"><br />
- -----BEGIN PGP PUBLIC KEY BLOCK-----<br />
Version: PGP Desktop 10.0.1 - not licensed for commercial use: www.pgp.com<br />
<br />
mQGiBDn6yYURBADM3qphMoDpvpp3Lk2KW0bpA+i1ne6Hwm24lW9w1dIJrw8CEc+S<br />
vAEhoGOAJNTO209NFYxcM+sA8XHp5aJpFHSbI536sfzbSVe3/MwdJ8JZXtbzcbHv<br />
ToBs1wScGTet2SGL6I9S3p7XUfprCYezBPRMCPOTxqR8pptotYOGXZoPZQCg/y0q<br />
CZjPJclqDY8Hf0X+DWnOMAkEAI4GnOpSq838/oElDAuZcLOvpTqTZ922pG1EJQmj<br />
Vh4P6br3ocrWnJSonkqFPLjihsVwGumO/hkyptrgqRV/vR9BmK1LKz901VaXbXPZ<br />
Lcns+XAg5sXxZcz87Dl4AduTF59ahHkc2bR7HqrvzRkXoQ/Q4ViLOifFISXXPKx8<br />
3OazA/9Ip4W+gr8e/oub7MQFJZcyOfcN1KDFIjnObVIabpIlKPcTeEHGvd/WUHOJ<br />
PQQr1+WGZY1W9UjLo171ssL2/x2bXaqJ4Ukgf4aQpRb5lUqekCKgine6eUA1XjTw<br />
J+a/J3xP54/iEuqdDZYGuX5j0/EJCqbY7gggPNkDNH82XdfQ+7QzUmFjaGVsIFdp<br />
bGxtZXIgW2NlcnRpZmljYXRpb25dIDxyYWNoZWxAd2lsbG1lci5vcmc+iE4EEBEC<br />
AA4FAjn6yYUECwMCAQIZAQAKCRC30ABpXpgYMFTFAJ0WqZwUXbD0H7YCGR7rI8jB<br />
Rh8E2wCePBrQBC1+shZrXCY0proYCkYfWdA=<br />
=UObU<br />
- -----END PGP PUBLIC KEY BLOCK-----<br />
</key><br />
<br />
<key name="serverCertification"><br />
- -----BEGIN PGP PUBLIC KEY BLOCK-----<br />
Version: PGP Desktop 10.0.1 - not licensed for commercial use: www.pgp.com<br />
<br />
mQGiBDmhGRERBAC9F7VF7ZNcwhffdFS2Sg0AcsF9gdhEEggZmBT1ezM5BYEO4lvN<br />
EJjezFilNxMLE3mP9E95mtRUEEtIx4ViyAGjVPwRBVQA2BNf+rbvCReBhhlJTFkN<br />
GOSHd65k4mDCflJAn7EX2OpST9tEAhpBs82w4OxlHIxmnav8iyD0O07sHwCgzYJI<br />
Xv3TEqERh0eDPEQ80MqGYEkD/Aj12tRhZYhYlVtEmJ4MrET9Ezuyhn8kQv89iBNK<br />
u2mN//LK4cqfJos1SJ3qXT16AHQQvfI0AUsI1ZQ+piq9pZ+sUMwpRnoQHM5SKux5<br />
UYcIM9aklW0zYAt+WjyrQBhN0eW0uzF40NVZHIH592dz/1RbNKf0hSDKBeCERTxk<br />
/zRDA/9rgvwyclIq4VTgA9AgwHC+JrKwbtJsawb4eYZPSbDe/pl2bQT9haTuLBKs<br />
Olz57Er5Vto6DWb1hs8gzb107u7CGYholr/tyjiPRhDvOcVQpZudkCE/1UXpawT/<br />
P4tPUvrBIVNK5SmHVRz6nsJxMxYm6Pr14+t8mgS1jrr/TxFTW7Q+U3lzdGVtaWNz<br />
IE9wZW5QR1AgU09YIFtvcGVyYXRvcl0gKGRzczEpIDxzZXJ2ZXJAc3lzdGVtaWNz<br />
LmNvbT6IVgQTEQIAFgUCOaEZEQQLCgQDAxUDAgMWAgECF4AACgkQKfOLUygtdArw<br />
3QCeJ8bEfVFS2etPkFus6esJfZ0+2OUAoK4AIIjFB+9CsoEkCn4dJBRTUKen<br />
=L806<br />
- -----END PGP PUBLIC KEY BLOCK-----<br />
</key><br />
-----BEGIN CONTRACT SIGNATURE-----<br />
Version: Open Transactions 0.45<br />
Comment: http://github.com/FellowTraveler/Open-Transactions/wiki<br />
<br />
sOL2sxu3GwwXb5NI9iFaproM+A0M+Unfkhflb6PjnB0wcGHAgc6I2XlYs8I9QGd3<br />
HFyr4zH/bnwgXkkWyYp0CG+T4plVX/cPxZi+Nxevo1sCXl8FGFkLagEPBIo6tCWu<br />
HSLsxfqizZtut+SI2aY/3ZcsTj3PQJocgTsBKrCbSIs=<br />
-----END CONTRACT SIGNATURE-----<br />
<br />
</pre></div>Cryptomanhttp://opentransactions.org/wiki/index.php?title=P2P_Protocol&diff=120P2P Protocol2013-06-12T17:06:47Z<p>Cryptoman: Created page with "IT is necessary for OT Clients, eventually to go PEER TO PEER. Why? 1) The OT peers must "compare notes" on the public minting files (for untraceable cash) in order to keep..."</p>
<hr />
<div>IT is necessary for OT Clients, eventually to go PEER TO PEER.<br />
<br />
Why? <br />
<br />
1) The OT peers must "compare notes" on the public minting files (for untraceable cash) in order to keep the server from secretly tracking them by substituting a different mint file for one of the users. The users thus have an incentive to compare notes on the mint file.<br />
<br />
2) The OT peers must communicate when they wish to negotiate key exchange, or to send each other a list of the server IDs and asset type IDs that each accepts. (Allowing their wallets to negotiate a mutually acceptable asset type, or otherwise satisfy any requests via other avenues such as Bitcoins, or Ripple.)<br />
<br />
3) The OT peers will implement some Ripple-like scheme, if not Ripple itself. The idea is for the peers to have rules about what percentage cut they charge for converting one asset type into another. This way, payments can "ripple" across the social web, the 6-degrees of separation from one party to another, and even changing asset type at each hop along the way, so that two people can pay each other even when they do not even deal in the same currency types.<br />
<br />
4) As Ripple is already p2p, so are Bitcoin nodes also p2p. Bitcoin is special because there is no central issuer. As a result, it will operate as a glue between OT servers, with users converting to BTC (on OT markets), taking the BTC to another server, and converting back again. Bitcoins are thus the "Universal Medium" and good wallet software for OT will probably have Bitcoin client software built it, along with the ability to convert in and out easily from real Bitcoins into OT accounts backed in BTC.<br />
<br />
Why would Bitcoin users do this? Instant finality of settlement, untraceability, and to gain access to OT instruments such as MARKETS (such things are already being built in the Bitcoin world anyway, to serve legitimate needs, so therefore OT is also of value in the same way.)<br />
<br />
-----------------------------------------<br />
<br />
Thus it is clear to me that OT has a p2p future on the client side, and federated on the server side (see FAQ for more discussion on this.)<br />
<br />
This leads me to... implementation of the p2p clients. Preferably this is not done within OT, although certain additions to the OT API may become necessary to support this functionality.<br />
<br />
Preferably some new component would do the job of making those OT API calls, in conjunction with calls to a P2P communications library (SUGGESTIONS?) -- this new component would be the core of the OT P2P universe, and preferably would be incorporated into many different actual client software implementations.<br />
<br />
Are there any P2P experts who might pitch in here with some thoughts?<br />
<br />
I think it would be cool to design it such that swapping out the transport layer is really easy. Like, for example, to use Speakeasy as the "p2p library" but to be able to swap it out for another lib with ease.</div>Cryptomanhttp://opentransactions.org/wiki/index.php?title=OTTP_URI_Format&diff=119OTTP URI Format2013-06-12T17:05:49Z<p>Cryptoman: Created page with "http://en.wikipedia.org/wiki/URI_scheme OTTP is a URI format that can be used in hyperlinks in web pages. This allows users to easily perform OT commands simply by embedd..."</p>
<hr />
<div>[[http://en.wikipedia.org/wiki/URI_scheme]]<br />
<br />
OTTP is a URI format that can be used in hyperlinks in web pages. This allows users to easily perform OT commands simply by embedding an OTTP link in the web page. The main advantage is that OTTP apps can be developed with regular web scripting, without much skills required such as Javascript, etc. All that is required is a knowledge of the system and the OTTP URI format.<br />
<br />
USE CASES:<br />
<br />
a link should be able to perform the following:<br />
<br />
1 Send a Nym a Message. ex. <code>OTTP://nym=123fae34sdfsd3rsfsd;msg=&quot;hello world!&quot;</code><br />
<br />
2 Transfer funds. ex. <code>OTTP://src=234jjk234kj234jk23l423;dst=34nnskfsdui923jkwekrjfsd;amt=234.344</code>. also supports 'default' accounts which are set in the GUI, so the web app does not have to specify what the src account is. This most likely is the most common usage. Web developers will want an easy way to trigger a payment from one account to another. In addition to initiating simple transfer functions, it can also pass in a message to the GUI to allow for more friendly CONTEXT SPECIFIC messaging to the GUI so the user feels more comfortable with the transfer. For instance the link will have another field, htmlmsg that has HTML data that displays nice graphics and confirms with the user to whom they are about to pay and for what reason. This HTML will appear IN THE OT GUI, and that is key for user confidence. There may also be other, simpler ways of performing messaging that do not require such verbose links. Similar formats can be developed for untraceable transfers and can easily be supported in the GUI.<br />
<br />
ex. <code>OTTP://src=SRCACCOUNT;dst=DSTACCOUNT;amt=123.44;msg=&lt;div&gt;&lt;h1&gt;You are about to pay FellowTraveller E-Banking Services&lt;/h1&gt;&lt;p&gt;please confirm&lt;/p&gt;&lt;img src=&quot;fellowtraveller-logo.gif&quot;&gt;&lt;/div&gt;</code><br />
<br />
= Account Number Deferral =<br />
<br />
The web server need not know the account number or Nym of the user. It's important to allow for this functionality in order to support anonymity, as web site owners can then link an account with a IP address and other identifiable information. Also it is possible to have a OTTP link that performs simple actions like payment or account transfer, without any prior knowledge about the user. The links themselves can refer to a NAME (discussed also in [[GUI Notes]]) , which is set in a variety of ways in the GUI (often times by default). Thus links do not have to contain specific Account numbers.<br />
<br />
ex. <code>OTTP://src=^MAINACCOUT;dst=23j324jjkuyoi23fsd;amt=1234.44</code><br />
<br />
this also exposes the user to IP tracing because the web site can simply correlate payments and web usage and link the records. Thus security features such as Tor and time-deferment of payment can be employed. NAMES can also be dependent on the REFERRER domain (the web site they live in) , as for instance the user may want a default account for one web site and a default account for another. It should be noted however, that in order to maintain security the''* Server and the Web Site should be different, unrelated parties''*.<br />
<br />
= E-Commerce =<br />
<br />
In order to facilitate E-Commerce, links that enable transfers must have an added feature- that of a linkback to a 'success' page. In other words, after the payment is processed, then the web application must have a way of responding to that. This pattern can be seen in a PayPal link found throughout the web.<br />
<br />
FILETYPES<br />
<br />
also, some file types in hyperlinks will trigger the gui. for instance, checks, cash, vouchers can be embedded as files in web pages(or attached to emails) and be picked up automatically when clicked. ie. The voucher will be downloaded as a file, the GUI will pick it up, prompt the user, and inform the user the voucher has been processed. This also suggests another important usage: Web Servers will be generating vouchers, checks, cash and other instruments so these functions need to be available to web scripting languages such as PHP.<br />
<br />
this means we need a special file type suffix and that suffix needs to be associated with the GUI application.</div>Cryptomanhttp://opentransactions.org/wiki/index.php?title=OT_Replaces_DNS&diff=118OT Replaces DNS2013-06-12T16:57:56Z<p>Cryptoman: Created page with "In the future, if the time comes that Open-Transactions becomes available in Firefox, in Chrome, etc, then it will be possible to use it as a replacement for the DNS system, w..."</p>
<hr />
<div>In the future, if the time comes that Open-Transactions becomes available in Firefox, in Chrome, etc, then it will be possible to use it as a replacement for the DNS system, without having to have some central DNS registry. The rub being, you have to allow for name conflicts on the network.<br />
<br />
Clearly there are always trade-offs in life, but I found this to be an interesting thought experiment. The obvious question is, &quot;Why would you eliminate DNS, just to end up stuck without any name resolution?&quot;<br />
<br />
Ah-ha! But I didn't say there wouldn't be any name resolution! I just said we had to allow for potential conflicts. But it's possible that such conflicts are not really a problem, and it's just in our heads, and that's worth exploring. After all, I2P has a globally secure, unique namespace, as does Freenet.<br />
<br />
Sure, those I2P &quot;names&quot; are, underneath it all, gibberish numbers (AS ARE IP ADDRESSES ALSO.) '''But people still somehow use names on I2P, don't they?''' They still refer to things by names, in person and in their eepsite URLs. How can this be when the only globally-unique namespace in i2p consists of gibberish numbers?<br />
<br />
Could it be that our need for DNS just a false dream?<br />
<br />
<br />
-----<br />
<br />
First, let's consider, what problems would this solve:<br />
<br />
# People could use whatever &quot;DNS name&quot; they want for their website. It will never be &quot;already taken&quot;. Obviously if you are violating trademarks or committing unfair business practices in the marketplace, yadda yadda then you are still subject to being dragged into court by McDonalds (or whoever), at least if you are in any way known and could be served.<br />
# DNS servers could be entirely eliminated. In this picture, they're replaced by a combination of Ricardian contracts (which are [[Sample Currency Contract|self-verifiable]]), and a distributed hash table (I nominate Namecoin), which is censorship-resistant, along with some hash verifications between p2p clients.<br />
# Ricardian contracts can '''eliminate CAs, aka certificate authorities.''' (A failed security model, yes? Does anyone seriously see CAs as anything more than a scam and hive of international espionage?)<br />
# Name conflicts while real, will be rare, harmless, and easily handled. They are &quot;part of the system&quot; and no big deal. (As they are already in I2P.) Meaning, 50 years from now, it could be considered entirely normal if there are hundreds of fake &quot;cia.gov&quot; contracts floating around, or whatever other website. Every schoolboy would nevertheless know which one was actually the C.I.A.'s ''real'' website, and easily verifiable links to the correct one would exist all over the Internet. Or consider the retailers. If there were a few dozen fake &quot;target.com&quot; websites that posed any threat to Target, trust me, the first few characters in Target's hashed key ID would quickly be turned into a catchy jingle, printed on receipts, printed on the side of their shopping bags, rotated endlessly on television commercials, etc. They'd put it on billboards next to their MySpace and Facebook links. It'd be like the same thing. Who can forge such a fingerprint?<br />
# Ricardian Contracts are able to '''unify the various protocols,''' since you can put as many different addresses as you want into your signed contract, including your '''.onion, your eepsite, your IP address, your &quot;last well-known&quot; DNS, Your Freenet public key, etc.''' These can all just be contract tags.<br />
# No more domain squatting. No more '''monopoly control over specific names.''' No more having to PAY for any name! No yearly registration fees, no ''ICANN fees.''<br />
# Yet, paradoxically, you can still build up value in a specific name, and you can still sell that name and website later.<br />
<br />
<br />
-----<br />
<br />
Here is how it would work, for example:<br />
<br />
-- Let's say I type a URL into my web-browser, such as this: ottp://freedombox.otc/<br />
<br />
-- The OT plugin would intercept this (due to the &quot;ottp&quot; or the &quot;otc&quot;) and would then try to lookup the &quot;freedombox.otc&quot; domain from a local signed list.<br />
<br />
-- It finds it in the list! (In this example so far...) The name resolves to a base62-encoded hash value from that list, so it now looks more like this: ottp://lkjsdf908q345kj.otc/<br />
<br />
-- That hash value is the actually the '''ID''' for a Ricardian contract. (And the ID is a hash of the contract itself.)<br />
<br />
-- The plugin loads up the contract using the ID as the filename (or local db key.)<br />
<br />
-- The contract is self-verifying. How? Because if you hash the contract yourself, you should get the same ID that you started with. (An attacker can't change the contract without also changing the ID.)<br />
<br />
-- Additionally, the public key for the signer of the contract appears IN the contract itself...<br />
<br />
-- ...And the contract is SIGNED with that key. So you can verify the signature as well. (The plugin does all this automatically when it loads up the contract.)<br />
<br />
THERE MIGHT BE A DOZEN DIFFERENT TRANSPORT PROTOCOLS IN THE CONTRACT...<br />
<br />
-- Once the plugin loads up the contract, there are multiple ways to actually connect to the signer's website. Let me show you what I mean. Notice in the sample contract below, there is an IP address, a DNS, an i2p, a Tor address, and a Freesite.<br />
<br />
<pre>-----BEGIN SIGNED CONTRACT-----<br />
Hash: SAMY<br />
<br />
&lt;?xml version=&quot;1.0&quot;?&gt;<br />
&lt;DomainNameContract version=&quot;1.0&quot;&gt;<br />
<br />
&lt;entity shortname=&quot;freedombox.otc&quot;<br />
longname=&quot;The Freedombox Website&quot;<br />
email=&quot;webadmin@freedombox.org&quot;/&gt;<br />
<br />
&lt;issue company=&quot;The Freedombox Foundation&quot;<br />
email=&quot;donate@freedombox.org&quot;/&gt;<br />
<br />
&lt;!-- CONNECTION TYPES --&gt;<br />
<br />
&lt;connection type=&quot;dns&quot;<br />
address=&quot;freedombox.org&quot; /&gt;<br />
<br />
&lt;connection type=&quot;ip&quot;<br />
address=&quot;189.432.12.56&quot; /&gt;<br />
<br />
&lt;connection type=&quot;i2p&quot;<br />
address=&quot;jsdf98345hj.i2p&quot; /&gt;<br />
<br />
&lt;connection type=&quot;tor&quot;<br />
address=&quot;8546jkhds9f8.onion&quot; /&gt;<br />
<br />
&lt;connection type=&quot;freenet&quot;<br />
address=&quot;SSK@GB3wuHmtxN2wLc7g4y1ZVydkK6sOT-DuOsUo-eHK35w,c63EzO7uBEN0piUbHPkMcJYW7i7cOvG42CM3YDduXDs,AQABAAE&quot; /&gt;<br />
<br />
&lt;!-- KEYS --&gt;<br />
<br />
&lt;key name=&quot;owner&quot;&gt;<br />
- -----BEGIN CERTIFICATE-----<br />
MIICZjCCAc+gAwIBAgIJAJWeuXi8XjVjMA0GCSqGSIb3DQEBBQUAMFcxCzAJBgNV<br />
BAYTAlVTMREwDwYDVQQIEwhWaXJnaW5pYTEQMA4GA1UEBxMHRmFpcmZheDERMA8G<br />
A1UEChMIWm9yay5vcmcxEDAOBgNVBAMTB1Jvb3QgQ0EwHhcNMTAwNzIyMjAxMTIx<br />
WhcNMTAwODIxMjAxMTIxWjBeMQswCQYDVQQGEwJVUzERMA8GA1UECBMIVmlyZ2lu<br />
aWExEDAOBgNVBAcTB0ZhaXJmYXgxETAPBgNVBAoTCFpvcmsub3JnMRcwFQYDVQQD<br />
Ew5zaGVsbC56b3JrLm9yZzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtiu6<br />
jU/R2Zm3AAo1jA4z/IVHyAnIFzp4kUNkLjEQ6bKG31PRaTcZTLPBkXsnQIFPx1Ky<br />
u9q8T9gjiKPAEurtPyoDdT99aWP1NREcg4/RJ2naWOEAXGh21PP22x31bvy6lOrv<br />
KqOSBfNTL43PEj0dKMIl0MNywzsVZGDqKXTStG0CAwEAAaMzMDEwCQYDVR0TBAIw<br />
ADAkBgNVHREEHTAbgg5zaGVsbC56b3JrLm9yZ4IJbG9jYWxob3N0MA0GCSqGSIb3<br />
DQEBBQUAA4GBAEhRt14Ys7jhUg0mDKMMgZLLs8cbDNFqwoJynLVNgJUdlvwo/nzZ<br />
Mk0wWVw8ucaDdpSBufUx4G3h6KkTTKOAbkvncRGdCiqywvOjKIbUczWMDdJ9uE5m<br />
5zGVZZ8C7EqaIIrv0OpW8WSryOCXvCFhLfKuZteELGmCCX2tQE9TqIsr<br />
- -----END CERTIFICATE-----<br />
&lt;/key&gt;<br />
<br />
&lt;key name=&quot;certification&quot;&gt;<br />
- -----BEGIN PGP PUBLIC KEY BLOCK-----<br />
Version: PGP Desktop 10.0.1 - not licensed for commercial use: www.pgp.com<br />
<br />
mQGiBDn6yYURBADM3qphMoDpvpp3Lk2KW0bpA+i1ne6Hwm24lW9w1dIJrw8CEc+S<br />
vAEhoGOAJNTO209NFYxcM+sA8XHp5aJpFHSbI536sfzbSVe3/MwdJ8JZXtbzcbHv<br />
ToBs1wScGTet2SGL6I9S3p7XUfprCYezBPRMCPOTxqR8pptotYOGXZoPZQCg/y0q<br />
CZjPJclqDY8Hf0X+DWnOMAkEAI4GnOpSq838/oElDAuZcLOvpTqTZ922pG1EJQmj<br />
Vh4P6br3ocrWnJSonkqFPLjihsVwGumO/hkyptrgqRV/vR9BmK1LKz901VaXbXPZ<br />
Lcns+XAg5sXxZcz87Dl4AduTF59ahHkc2bR7HqrvzRkXoQ/Q4ViLOifFISXXPKx8<br />
3OazA/9Ip4W+gr8e/oub7MQFJZcyOfcN1KDFIjnObVIabpIlKPcTeEHGvd/WUHOJ<br />
PQQr1+WGZY1W9UjLo171ssL2/x2bXaqJ4Ukgf4aQpRb5lUqekCKgine6eUA1XjTw<br />
J+a/J3xP54/iEuqdDZYGuX5j0/EJCqbY7gggPNkDNH82XdfQ+7QzUmFjaGVsIFdp<br />
bGxtZXIgW2NlcnRpZmljYXRpb25dIDxyYWNoZWxAd2lsbG1lci5vcmc+iE4EEBEC<br />
AA4FAjn6yYUECwMCAQIZAQAKCRC30ABpXpgYMFTFAJ0WqZwUXbD0H7YCGR7rI8jB<br />
Rh8E2wCePBrQBC1+shZrXCY0proYCkYfWdA=<br />
=UObU<br />
- -----END PGP PUBLIC KEY BLOCK-----<br />
&lt;/key&gt;<br />
<br />
&lt;key name=&quot;serverCertification&quot;&gt;<br />
- -----BEGIN PGP PUBLIC KEY BLOCK-----<br />
Version: PGP Desktop 10.0.1 - not licensed for commercial use: www.pgp.com<br />
<br />
mQGiBDmhGRERBAC9F7VF7ZNcwhffdFS2Sg0AcsF9gdhEEggZmBT1ezM5BYEO4lvN<br />
EJjezFilNxMLE3mP9E95mtRUEEtIx4ViyAGjVPwRBVQA2BNf+rbvCReBhhlJTFkN<br />
GOSHd65k4mDCflJAn7EX2OpST9tEAhpBs82w4OxlHIxmnav8iyD0O07sHwCgzYJI<br />
Xv3TEqERh0eDPEQ80MqGYEkD/Aj12tRhZYhYlVtEmJ4MrET9Ezuyhn8kQv89iBNK<br />
u2mN//LK4cqfJos1SJ3qXT16AHQQvfI0AUsI1ZQ+piq9pZ+sUMwpRnoQHM5SKux5<br />
UYcIM9aklW0zYAt+WjyrQBhN0eW0uzF40NVZHIH592dz/1RbNKf0hSDKBeCERTxk<br />
/zRDA/9rgvwyclIq4VTgA9AgwHC+JrKwbtJsawb4eYZPSbDe/pl2bQT9haTuLBKs<br />
Olz57Er5Vto6DWb1hs8gzb107u7CGYholr/tyjiPRhDvOcVQpZudkCE/1UXpawT/<br />
P4tPUvrBIVNK5SmHVRz6nsJxMxYm6Pr14+t8mgS1jrr/TxFTW7Q+U3lzdGVtaWNz<br />
IE9wZW5QR1AgU09YIFtvcGVyYXRvcl0gKGRzczEpIDxzZXJ2ZXJAc3lzdGVtaWNz<br />
LmNvbT6IVgQTEQIAFgUCOaEZEQQLCgQDAxUDAgMWAgECF4AACgkQKfOLUygtdArw<br />
3QCeJ8bEfVFS2etPkFus6esJfZ0+2OUAoK4AIIjFB+9CsoEkCn4dJBRTUKen<br />
=L806<br />
- -----END PGP PUBLIC KEY BLOCK-----<br />
&lt;/key&gt;<br />
<br />
&lt;/digitalAssetContract&gt;<br />
-----BEGIN SIGNATURE-----<br />
fm7l4FyMW7p0ayZcBwq2JHGnSzRIwS75tvkNxpEnrvcahwv68RKFmxDr7Hz8000u<br />
d9oOznZpjga17gwSlTS1AsiX3GAix5CLCZLenAV6dUUsgEBOK2kCnB/6gc8c5FVP<br />
QH0mF0ICfxDPSY2Y0/lXVww8URis0mmHz3F+NX9S9B4=<br />
-----END SIGNATURE-----</pre><br />
Notice also that the keys are in the contract, so there's no need for any &quot;certificate authorities&quot; anymore. '''They are all spy agencies anyway.'''<br />
<br />
<br />
-----<br />
<br />
WHAT IF I DON'T ALREADY HAVE THE CONTRACT? HOW DOES THE PLUGIN FIND IT?<br />
<br />
SHORT FORM: In most cases it already has the ID (in the URL), so it just downloads the contract based on that ID, via P2P or from a Distributed Hash Table. Then it verifies the contract based on the ID and the signature, and then it actually connects to the website and displays it, using one of the addresses inside the contract (whether via i2p, tor, freenet, ip, dns, etc. The contract supports as many as you wish.)<br />
<br />
<br />
-----<br />
<br />
WHAT IF IT NEEDS TO RESOLVE THE NAME FIRST, TO GET THAT ID?<br />
<br />
(That has to happen once, after which it is cached locally.)<br />
<br />
LONG FORM: In this example we actually have to resolve the name &quot;freedombox.otc&quot; and find the right contract.<br />
<br />
# The plugin can make a request via P2P. (Coming soon to Open-Transactions out of necessity for the digital cash, due to the nature of the minting files.) The plugin thus asks my peers to lookup the contract ID in their own local lists, and so I can find the contract via a &quot;web of trust&quot;.<br />
# Optionally, alternately, or additionally, my plugin may contact certain specialized &quot;search engines for contracts&quot;, which I predict will arise on darknets. This is only a matter of time. Thus, instead of searching Google for &quot;freedombox&quot; and getting a list of sites, there would be various darknet-based aggregator sites where I could type &quot;freedombox&quot; and get a list of contracts.<br />
# Whether the plugin uses p2p or search engine, or both, EITHER WAY, MULTIPLE CONTRACTS might come up for the SAME NAME!<br />
<br />
This is okay!!!!!! People automatically assume this is some big problem to be solved, but you can instead realize that IT'S NOT A PROBLEM AT ALL. The sun will still come up in the morning. The sky is not falling.<br />
<br />
<ol start="4" style="list-style-type: decimal;"><br />
<li><p>If such a name conflict happens, that's okay: just check the fingerprint and approve the correct one. You'll see the list of IDs, and you can click and view each contract. You probably got the site ID off of a business card, anyway. THIS IS JUST LIKE VERIFYING A FINGERPRINT FROM A BUSINESS CARD, OR VERIFYING A FINGERPRINT DURING OTR CHAT. (And you only do it once, in the rare event of a conflict.)</p></li><br />
<li><p>In most cases, THIS STEP ISN'T NECESSARY, since in most cases you will be clicking on a link, not typing the name by hand, and the link itself will ALREADY have the ID, (no need to resolve it from the name.)</p></li></ol><br />
<br />
Instead, the plugin IMMEDIATELY loads (or downloads) the appropriate contract based on its ID, then verifies its signature, and then connects to the website.<br />
<br />
<ol start="6" style="list-style-type: decimal;"><br />
<li><p>Also, remember once you enter the ID the FIRST TIME, then the name will work EVERY time after that. (Since the plugin can just look it up locally.)</p></li><br />
<li><p>You can even choose to import contracts that both claim the same name. (This will rarely or never happen.) When the plugin encounters such an ambiguity, it'll just pop up the list and ask you to choose one. No big deal!</p></li><br />
<li><p>The contracts themselves can be globally available in a DISTRIBUTED HASH TABLE. This way the owner can continually update the contract, everyone can see it, and it's censorship-resistant.</p></li><br />
<li><p>It's easy to update contracts in the DHT as necessary. Perhaps the &quot;main ID&quot; is just a DHT address where the &quot;current version ID&quot; can be found. This way you can change versions without changing your main ID. The DHT address can be a hashed public key, where the owner is the holder of the private key.</p></li></ol><br />
<br />
<br />
-----<br />
<br />
WHAT IF I AM EDITING AN HTML PAGE AND I WANT TO SEE THE ACTUAL NAMES IN THOSE LINKS, NOT THE UGLY BASE62-ENCODED HASHED IDs?<br />
<br />
-- You can probably just USE the names, and &quot;The HTML Editor of the Future&quot; will do the hard work of substituting the IDs when you save the file later. (Computers can do this for us!)<br />
<br />
-- In fact it will probably just add the IDs together WITH the names, for whichever tags where they don't already appear.<br />
<br />
-- Until such an editor exists, a very simple script would do this.<br />
<br />
<br />
-----<br />
<br />
WHAT PROBLEMS DOES THIS SOLVE?<br />
<br />
# People can use any &quot;DNS name&quot; they want for their website. It will never be &quot;already taken&quot;.<br />
# There is no central &quot;DNS server&quot;. No central authority.<br />
# Name conflicts are rare, and easily handled. Conflicts also naturally cause the user to choose the right one based on the FINGERPRINT. Isn't this a good direction?<br />
# Supports ALL PROTOCOLS. (Whichever addresses you put in your contracts... tor, i2p, ip, dns, freenet, etc.)<br />
# Eliminates the need for certificate authorities. (A FAILED SECURITY MODEL, YES?) You already have the site's public key from their contract, so your browser can just use that to encrypt a session key.<br />
# No more domain squatting. No more monopoly control over specific names. No more having to PAY for any name! No yearly registration fees, no ICANN fees, and no Namecoin purchase necessary. Your website also can't EXPIRE -- unless you put it in the contract that way, or unless we make it a feature of the system.<br />
# Yet, paradoxically, you can still build up value in a specific name, and you can still sell that name and website later.</div>Cryptomanhttp://opentransactions.org/wiki/index.php?title=Lucre_and_Denominations&diff=117Lucre and Denominations2013-06-12T16:50:36Z<p>Cryptoman: Created page with "[http://anoncvs.aldigital.co.uk/lucre/ Lucre] does not use a "Cut and Choose" protocol like I was expecting from my classical understanding of Chaum's work. My original under..."</p>
<hr />
<div>[http://anoncvs.aldigital.co.uk/lucre/ Lucre] does not use a "Cut and Choose" protocol like I was expecting from my classical understanding of Chaum's work.<br />
<br />
My original understanding was that the client sent N prototokens to the server, all with a different serial number, but the same face value. These tokens were blinded, so the server was forced to ask the client for the unblinding factors, one-by-one. The server thus opened and verified all of the tokens--except for one, which was signed and returned. Upon return, the client unblinds the last token. Now it is ready for spending, but the server has no idea what the serial number is.<br />
<br />
This is what I was expecting, so I actually designed the classes to support this. OTToken does not merely store its own state as a prototoken (before it is signed.) Rather, it stores its own state as a LIST of prototokens (before it is signed.) This list can be sent to the server as a single OTToken, so the server can receive it and execute the cut-and-choose protocol.<br />
<br />
This is where things broke down. I was originally going to code this so I could set the token up with ANY face amount, and then add denominations later for extra anonymity. But I realized there was no way to put the AMOUNT of the coin inside the signed portion. Only the Lucre data itself, of any digital cash note, is blinded, signed, unblinded, and verified. But face value of the note is not stored in the Lucre data itself. There was no way to put an amount inside the Lucre data. So there was no way to blind the amount.<br />
<br />
THEREFORE, I WAS FORCED to wrack my brains and google old archives, and eventually came to denominations as the solution.<br />
<br />
For any digital asset type, (that is, for any currency contract that is uploaded to the server by a user who is creating an issuer account or any basket currency), the server creates MULTIPLE keys--one for each denomination. If I upload a currency contract for Chuck-E-Cheese game tokens, a new asset type ID is created (as well as a new issuer account, if I am the signer on the contract). At the same time, a new and corresponding MINT is also created, with a different public/private minting key pair FOR EACH DENOMINATION. <br />
<br />
Actually, the mint is not created just then, because it would freeze the server up while the keys were being generated. (They take a long time.) So instead, I made a utility called "otcreatemint" that runs in the transaction/ folder and creates the mint for you. Try it, it's easy to use. You won't need to use it until you issue some new asset types.<br />
<br />
If you search the transaction/ code for "if (0)" you will find a section where you can comment one line, and uncomment another line, and the server will ITSELF create any new and needed minting keys whenever it boots up. But be warned: this can take a long time for each asset type. If 1000 currencies have just been issued, it's going to be a while, which is why I put it in a separate utility.<br />
<br />
A future version of the server will fire off the otcreatemint utility in a separate process. For now, it's just proof-of-concept , so you have to run it by hand.<br />
<br />
There are two versions of any mint, on the server side: mints/ASSET_TYPE_ID and mints/ASSET_TYPE_ID.public<br />
<br />
If a user wants to withdraw cash, his wallet must send a getMint message to the server first. The server will look up the public mint file based on the asset type ID, and return it in a response. The wallet saves the mint file on the client side. This contains the public keys for each of the denominations. Any withdrawal will consist of a purse of tokens, the least number of which, of the appropriate denominations, are necessary to fulfill the withdrawal request. (In the future, there will be some limit placed on the number of tokens allowed here. At some point, it's too expensive for the server to process, plus the message size can get out of hand.)<br />
<br />
So Chuck-E-Cheese game tokens would have its own mint file, stored in mints/ASSET_TYPE_ID, with a key pair for 1, for 5, for 10, for 25, 100, 500, 1000, 2000, 10000, 100000. That is, a penny, nickel, dime, quarter, dollar, 5 dollars, 10 dollars, 20 dollars, a hundred dollars, and a thousand dollars. In the future, these will be described in the currency contract by the issuer, and the server will simply obey the contract. But right now, for testing purposes, those specific denominations are HARD-CODED, and they are automatic for all asset types.<br />
<br />
If it weren't for denominations, you would literally have to pull 100,000 tokens out of the bank for a $1,000 withdrawal, which is not feasible. I also didn't bother with larger denominations or custom amounts after this, because I realized that the small denominations themselves add greatly to the anonymity of the total cash base.<br />
<br />
CUT AND CHOOSE -- NOT NECESSARY<br />
<br />
The server KNOWS the denomination of each coin, since that portion of the note is NOT BLINDED. The wallet had to use the appropriate public key for each denomination in order to generate the blinded request. The server therefore uses the CORRESPONDING KEY, from the private mint file, to sign that token, based on the appropriate denomination. Because of this, the server KNOWS that only the SAME KEY, of the right denomination, of the right asset type, can possibly verify the signature later. But the server still does not know the ID itself, of the token, since that portion WAS blinded safely in the Lucre data.<br />
<br />
So it turned out that denominations were necessary, but that cut-and-choose was not necessary. This means that the user must request the server for a copy of the mint before he can withdraw cash in any specific asset type (including basket currencies.)<br />
<br />
This also means that the server can have expiring and rotating Mint files, useful for expiring tokens and therefore keeping the spent token database manageable.<br />
<br />
This also means that the server can give different token keys to one user that it gives to another, thus breaking untraceability. ONE EASY VERIFICATION MECHANISM TO PREVENT THIS is for users to COMPARE the public mint files that they store in their wallets. This is the sort of client-side stuff that I haven't really explored deeply enough in thought (yet). If the wallets are also anonymous network nodes and/or clients, then it seems they are all connected anyway, so why wouldn't they share public mint files as a way of keeping the servers clean? The nodes would derive a benefit from this. Any user COULD do this himself, in fact. Just create multiple user accounts from multiple VPN locations, and compare the public minting keys.<br />
<br />
-----------------------<br />
<br />
''any chance you could write a sequence diagram for how this process works?''<br />
<br />
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.)<br />
<br />
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.)<br />
<br />
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.<br />
<br />
You can see the full progression of the blinding code if you look here:<br />
<br />
<br />
1) WITHDRAW (CREATE) PROTOTOKENS<br />
OTClient.cpp: <br />
else if (OTClient::notarizeWithdrawal == requestedCommand) // NOTARIZE WITHDRAWAL<br />
<br />
2) SIGN PROTOTOKENS<br />
OTServer.cpp: <br />
void OTServer::NotarizeWithdrawal(OTPseudonym & theNym, <br />
OTAccount theAccount, OTTransaction & tranIn, OTTransaction & tranOut)<br />
<br />
3) UNBLIND TOKENS<br />
OTClient.cpp: <br />
void OTClient::ProcessWithdrawalResponse(OTTransaction & theTransaction,<br />
OTServerConnection & theConnection, OTMessage & theReply)<br />
<br />
<br />
[The tokens are ready to spend now, and untraceable. Later, the client<br />
spends some tokens, by passing them to another wallet user. That payee<br />
deposits the tokens to verify them (perhaps immediately withdrawing<br />
again, if he just wants to exchange them for new ones.) The server has<br />
no way of knowing where the tokens came from, since they were blinded<br />
when they were issued. The server also has no way of knowing if the<br />
tokens represent a new payment to me from someone else, or if I am<br />
just exchanging and re-exchanging tokens that I already had, perhaps<br />
to fix an approaching expiration date. Below this point, that payee is<br />
now the client, since he now has the tokens...]<br />
<br />
<br />
4) DEPOSIT TOKENS (IN PURSE)<br />
OTClient.cpp: <br />
else if (OTClient::notarizePurse == requestedCommand) // NOTARIZE PURSE (deposit)<br />
<br />
5) VERIFY TOKENS<br />
OTServer.cpp: <br />
void OTServer::NotarizeDeposit(OTPseudonym & theNym, OTAccount & theAccount, <br />
OTTransaction & tranIn, OTTransaction & tranOut)<br />
<br />
''Also I suggest reading the OTToken and OTMint classes to see the actual <br />
Lucre calls being made.''</div>Cryptomanhttp://opentransactions.org/wiki/index.php?title=Sample_Mint&diff=116Sample Mint2013-06-12T16:48:33Z<p>Cryptoman: </p>
<hr />
<div>Mints now have series and expiration. See the [[Sample Cash|token page]] for more information on this.<br />
<br />
The Mint is uniquely identified by its [[Sample Currency Contract|Asset Type ID]], as well as its Series.<br />
<br />
Each token is signed with, and verified by, the Mint Private Key for a given AssetTypeID, for a given series, and a given [[Lucre and Denominations|denomination]].<br />
<br />
You may also find the [[Instruments|financial instruments]] chart interesting, including [[Sample-Cheque|cheques]].<br />
<br />
Sample Public Mint file:<br />
<br />
<pre><br />
-----BEGIN SIGNED CONTRACT-----<br />
Hash: SAMY<br />
<br />
&lt;?xml version=&quot;1.0&quot;?&gt;<br />
<br />
&lt;mint version=&quot;1.0&quot;<br />
serverID=&quot;44FmyPAgrmGu671RywGnhrt8aR6tzmNFn9WKQ92BXn&quot;<br />
assetTypeID=&quot;XUHBvdsWAEmErZMzHaRKaNPaAVsUvKwL4uLY4nOY2s4&quot;<br />
cashAcctID=&quot;khlj2LLL9EYxPimNR4yAYDDzO5QzSg7LSxxsGc1RpsP&quot;<br />
series=&quot;0&quot;<br />
expiration=&quot;1289641563&quot;<br />
validFrom=&quot;1281865563&quot;<br />
validTo=&quot;1297417563&quot; &gt;<br />
<br />
&lt;mintPublicKey&gt;<br />
LS0tLS1CRUdJTiBQVUJMSUMgS0VZLS0tLS0KTUlHZk1BMEdDU3FHU0liM0RRRUJB<br />
UVVBQTRHTkFEQ0JpUUtCZ1FDNVg2MGNib1BQVGVaQ2pRUE9qSHBaRERiYgpNOVl6<br />
UlcyV3EvUHJIbDE3alZIa3hLMVgvbHdhM3NTR0hFTUFvUlp3SDFNa2trbTViWEow<br />
ZUpQWit2RVh6S0ZwCmNCeEZFODVBbXNibEM4U280T3dVY01HelQ0OTljQWl1aWsz<br />
bkdTR3hJbTE4K0NpOUdCNG5GVnNudXJkRzIxakgKck5MeEwzbVVwaHc0VzdwVkl3<br />
SURBUUFCCi0tLS0tRU5EIFBVQkxJQyBLRVktLS0tLQo=<br />
&lt;/mintPublicKey&gt;<br />
<br />
&lt;mintPublicInfo denomination=&quot;1&quot;&gt;<br />
eJwVkSuSGEAIRKP3NAx/xApg4CCJSKUqYk3un1mDAV5D9+9P+fj6XOI2tcvL4lN2<br />
qfBim+CEMRMkyVU7VClpjB0gZeZnK2bW9+gykIe9ctBwhTi7M1IOX4AcXcm5WaDH<br />
TQOYlLrqsJ7XJOccCQe23lZOSC6ra3isRFN5+pZ0Mx8hndo4hYC5b8i3VCqqvCoL<br />
5xuFW1eE34H0aHTWiTW80hmhFvab5KlK0bMfX/9+/v3z69OuQmTuYgl4O4YfJb7p<br />
53pLc6+5h08XwciuI7eekETCQ7ShtXjekBYuzaFvm+D45CV+ojvOxSWh0FujoKhr<br />
zwqxTjQAKwC4ju0n5oVgbEuEiwO6qNiig0M7PY8acQbeNiabBNRluGF07zx6HRSJ<br />
pve0+IsPjUrtfa+ylyPtxH3CjttuntONHz/+A0jneKM=<br />
&lt;/mintPublicInfo&gt;<br />
<br />
&lt;mintPublicInfo denomination=&quot;5&quot;&gt;<br />
eJwVkTluGEAIAFP7NVzLUbhgOR6SFFGkFG7y/6w7hLhm+P15Pr4+F44VFKqDXIF7<br />
pKyYtJTJDbI7NwD8rLrDgVmujA5XPJy2WnfvK2zrMLIIyCSdTFcFPupDfg+/WBjd<br />
lzGkfIIdGU/wdTwiXbxsbze8pQIh7UnObEFXGyfSizKIi/l40FA7YN1jzEl1bkK+<br />
0R2nvvu8Aaf4zGsl45C882IXLQizqTtSbaB8P77+/fz759dnYCbbTWrcTptccHtW<br />
hHc3B0FGdQQfH0OKGx8862a09Xj5ZcejuWRSr9+nKIXz3mSREw8BTMcTYVcD72KE<br />
apzjtfJ8jHY3jcnY7DoTty88RwlUaM9W3qeOl4jntk9+S8DkiJ5SwRKV8VFy6IFv<br />
ViFpReEg6vMe8l6CUZgPtZ9pvJOlKvIOO/zx4z8HN3ew<br />
&lt;/mintPublicInfo&gt;<br />
<br />
&lt;mintPublicInfo denomination=&quot;10&quot;&gt;<br />
eJwVkTtuGEAIRFP7NHwWFgoXfA/iFFGkFG5y/2yERAXMvOHXp3x8fxrphnvqsBnb<br />
BhN1IZHtjkNC9uqMvX7HZ9hpp+IcbQvsWYUJldfORV4WNLLZqNEbIAP6Nvf2PXz4<br />
Sii/IdeSuCXzJBEXXN74eile466aVJzDmbQtTBLb2E80XGP42FuUdDi25JFcjONG<br />
MKw6dPfREDv6YPUEkR6C9dFOE31oZ3GtTF/lx/ffrz+/f37iBmRpEWcLnmC2UoAS<br />
v3kFHJD1wSKpkV8DfVcHAcRishLu1aNEjCQFJD2eh7v1GkZTgEJYPelOkQZ/aZ21<br />
zmocuaduHjT1U0ms/lwb6jNbUDYRL67Fzq22rVuFo2wuGU+8OVJlC/QhefJxzOKT<br />
HFLSpF0wa2Av/8Xr9z/YeV99egCdeSmfO/z48Q/7rXjd<br />
&lt;/mintPublicInfo&gt;<br />
<br />
&lt;mintPublicInfo denomination=&quot;25&quot;&gt;<br />
eJwVkTuSEEAIRI33NMDwDTYYYDjIGlhWGWzi/cWUhoZ+/PqUj+/P4YfddAQKB0LE<br />
rA8j+hTnC28pISd6yVnnoW4ZwC+dVkOPq3Myhh43MKiQTKBX3sy1Nqdw364LM5BG<br />
5O9qm7El3Zl6LS6Ajq1xQlgv33HByBPM0A23QCL0hZkfzSpYjabLV9r7ehpjRLmS<br />
X15Z50BQ13x4z85DscV1OIPTBP2sytGQ/Padj++/X39+//w0u/4wH6Q80rtObBbD<br />
0pKb4UFEiRZ2hJU5A0DHPHF27YP6UPpAUvviM1fz6AGt2wC1cCjWKq2rzgypBakm<br />
w3lMiHIAix16YyRSXJuNX3uEnmjKk8ta4dmVJQpeUdNxeOOtuG9jSLxX1Alvk8oK<br />
I3c34P+PFcwDOEeOdqAED8iiEaw0OEijHh8//gFfh3gw<br />
&lt;/mintPublicInfo&gt;<br />
<br />
&lt;mintPublicInfo denomination=&quot;100&quot;&gt;<br />
eJwdkTmOEDAMRannNHEcb8UUXg8CBUKioOH+eFCkKPpOnuyXn5/08edTqei8eAYZ<br />
u7D1dLkDBReO9PGcG/iwuDzqgeIAOvSb27NnljdIDFENlK9f8pbRzsl3gs/z8oua<br />
gWH11D1fXXAD7hilcOQUhOulZ3MnMvRUrN17U+Jrj6mKiYDwSvnJ7MM1Vmo6pawI<br />
OFm5pGifx2B+z43cRtSa0s7YeXnlCy1TLqbB90l8/Pn7/fevH58PykAkRZGUXWd0<br />
I6yQNKape5ZnxGkCATGP2Hs7lUrDvvh6upoq6j61ffo1ertiH7IEUOKiNTrx5Esp<br />
H163dasQqgi6gtbL3oYRPC2iE7rasUry/0icvMYFmWV/p3WODHKTaC0lZMbuESXE<br />
PLpsXsrpCeOyBqv1ccH0Qmm/i74GodlgKOR8fPsHQoN5fw==<br />
&lt;/mintPublicInfo&gt;<br />
<br />
&lt;mintPublicInfo denomination=&quot;500&quot;&gt;<br />
eJwVkTmOGCAMRVPPacDGWzGF14MkRRQpxTS5fzxCAmTJ/Mfz70/6+PqMl3ZGxcEU<br />
uOeOJt0Uy6ehB+pdm0YGo3fxosaWnOBYO0VgGTu3kaXQVhCH5OT0dgKfXQihqvaG<br />
Bp/Iq/cOYdaINT3gy+190jFVieOWHZXEC2fSrxXVxDt4DvGYB0bkzNVO6dR6haGV<br />
EGd5KZoXqWEMibUX94gz0cTeA4lwo5uNAdhIpiQ+vv79/Pvn1+fCHkE/Hbghdgsq<br />
gsIPFzjUwZeLVSpdeZ3y+aM9xlKdTcno1G7iF1h9BY6IBEqZLXDGserCgstqMEG+<br />
XNi4ILwPmVfA829PcGcQRe9TH8UVm7Be6LVAie23aMVsct+5oPTtTd+DcGmpSdab<br />
UyCcPR472gDzc7YPvO294oy4B14Y7pgVIsEnP378Bwj3eOQ=<br />
&lt;/mintPublicInfo&gt;<br />
<br />
&lt;mintPublicInfo denomination=&quot;1000&quot;&gt;<br />
eJwVkTtuGEAIRFP7NMtvgcIF34MkRRQphZvcP+sOidEM8/j9KR9fn31Tw69sXCjr<br />
Qc2qRJaB5os3csvg0iWr67lRgOlJ55SqoBjuTZtOaC32veYDtXOAdxfZCYy3MrpX<br />
Ym5EO4JT5gHw4bt1pCcJjiWvHx864SXmm8zeW2NyG5Gr2iwEuutsPvMJ4KIIwrEE<br />
3SAZLeETbGDo4FKbB6uBXC91xX0pqdJ6S5/G6ePr38+/f3596ogrC74qyiCx0G8/<br />
FwEK3HQqagOt/NztI/5dbQOec68/bEvzTeSSGgmehtEHhhoFSHNeg5g9hOo3681J<br />
Xu/wp6Nu28O8gKin8UKE5TZLCZWkrSe+TzjHTD7CdeC0gCZgcJic5pfFl0MDOZu4<br />
x0LX5jQVSd3zmjliiUbaMwMlAODHJl04ieHjx3+APnju<br />
&lt;/mintPublicInfo&gt;<br />
<br />
&lt;mintPublicInfo denomination=&quot;2000&quot;&gt;<br />
eJwVkTtuGEAIRFP7NHyWX+GCZeEgSRFFSuEm9w9uaNAwj5nfn/Lx9emoV6XcGZwT<br />
fbClLjHhtckpCJ8XfSrwaFwA9Zs50oeroXTlDl0jRO8JeRCrHTAUTJmi1hBI47kr<br />
USHkKHOPOecMwBRCnyERJCTFvWpyW9ruxGFAYQYaP10gUpzRWFOlymIhnB73TvbT<br />
VRDmN/d6FQ8eeO4oei5einie1l34iO7dr8yIXO7H17+ff//8+rQYyVeP/JKb6ll8<br />
TNJawxf3ofpAUmImNQXWFRV0LWkF9/tUvHbuFnKcoBHD8pluIntY+/Sbq14sT8I2<br />
5o53ZA6f5EWE96xlkc3CKZRgv2IwYhh75rD+OnVS5AEhCPJMxVx2T3J/0ANSY9fc<br />
IH1i093gtg7Z0tw4z71NLzfV7Xp7+eZbZJ4G/vjxH41PeBU=<br />
&lt;/mintPublicInfo&gt;<br />
<br />
&lt;mintPublicInfo denomination=&quot;10000&quot;&gt;<br />
eJwN0SmyHUAIBdDotxqmhkZ8wbiQRKRSFfFN9p82OLhw+P11Pt9fd4Uiuk2OMbKG<br />
hgnvHOyIe8ZG9Dr1lM9YW/jEhbBcFRcYn2oUzBSOVy9odpoTNk0hwfAGAeFeXkIA<br />
RqvyJWJGQExXhXR6QbHMQkorUCJvFYlIzSRfpgzodfRpnL6QYnfKarzco5iMZxgE<br />
R6svkloYTC3iQeW9fratT4Q4VSbLXNoSYvt8//v598+vr2srKw7zzp7F6nMnHErv<br />
Y8g8Haunn4X5ixI1xHgdGsCTR9XrKlw8TsKAztivBfXYkDwkF8sXeQWe2tZGQdtu<br />
UeTaXXQlerTJaVfflmehzL3rTeirSXfWD5t5abicTkTt5ZY4FnHI4spLV7Yn8ryL<br />
IefVo5h7twGcrZ9jzlOw2ocn/eLoTXjP+Pz4D543ePg=<br />
&lt;/mintPublicInfo&gt;<br />
<br />
&lt;mintPublicInfo denomination=&quot;100000&quot;&gt;<br />
eJwNkTuuHUAIQ1Pf1QwM3+IVMMBCkiKKlOI12X9o4cjY5vcXf76/IqnfrTCOvu5i<br />
eLkvxOs4wyB9b542pqOS6YwnkPAhDPANa3EyCwXQ4of1KL09MNlKTyUHAEiagHW3<br />
apuQ8VGdkJCaxaVJV9QqmH0ySQT4Oc5TPO6VETxYtmjcwrx9bsGwU+0gH1RncaBW<br />
r3ex9IpY3N9hwjk14iPjpKmx0/QkfevO+LF+vv/9/Pvn1xcZXFNCR+7I65sdGxeF<br />
BkMclbppidWMfUvUZUXsMV8xJ4HeItrUzDbOsXh4r1zgGI98JyWyD1iZoZsoZuna<br />
Himu9XkCKAWDqcn7LpuxOS4RuAi/apgX0FQbRq8OTGyLZ4+CZ8I+CJlId3WKwgAM<br />
grrUVrzIkV6O44JQiQo4S2cQ00DaWHx+/AdnIXhp<br />
&lt;/mintPublicInfo&gt;<br />
<br />
&lt;/mint&gt;<br />
-----BEGIN CONTRACT SIGNATURE-----<br />
hLl+yVFoiI9JQlHwhRFMP95kCJ3clvRkIu4vRjOjWNil1LyncwFSysGvMayBjAHJ<br />
0X/BV03xjrtKGk1clB2C551uy0SXUL65C6IIjDKv+eREMZ31jNCDHhWCLUSb3OgZ<br />
4CcLgj+da5M8VrdtFjKSyOMqH47wl9awRiLqNKjX7n4=<br />
-----END CONTRACT SIGNATURE-----<br />
</pre><br />
The above is a '''Public Mint File''' which the wallet will download every time a new series is released. The wallet uses the public keys to generate prototokens (for cash withdrawals). The '''Private Mint File''' is stored on the server side, and it also contains the private minting keys. These are used to sign the tokens (while they are blinded), as well as to verify them later when they are spent by the recipient (after being unblinded by the wallet.)</div>Cryptomanhttp://opentransactions.org/wiki/index.php?title=Low_level_Use_Cases&diff=115Low level Use Cases2013-06-12T16:47:02Z<p>Cryptoman: Created page with "Experts only! Since the high-level API was introduced, the low-level API is now wrapped by the high-level API, instead of being touched directly by the programmatic user. Ma..."</p>
<hr />
<div>Experts only!<br />
<br />
Since the high-level API was introduced, the low-level API is now wrapped by the high-level API, instead of being touched directly by the programmatic user.<br />
<br />
Many details which were forced on everyday programmers have since been hidden behind that veil. These details are still important: to programmers tweaking the APIs themselves. But otherwise they needed to be moved away from the higher-level API pages, because they introduce unnecessary confusion to everyday programmers to whom they are entirely irrelevant.<br />
<br />
<br />
-----<br />
<br />
'''SERVER MESSAGES'''<br />
<br />
'''The ''Request Number''''' <br />
When you message the server, your request number needs to be in sync. Normally it will stay in sync and everything works perfectly. But if the number goes out of sync, your messages will all fail! Just call <code>OT_API_getRequest()</code> to put it back into sync again. You will probably do this once when you first connect to the server, and then never need to do it again. Since the request number must increment for each message, it is impossible for an attacker to intercept and replay an old message, (since the request number on the old message is no longer any good.)<br />
<br />
<br />
-----<br />
<br />
'''Create a new Asset Account''' Clear the reply buffer: Call <code>OT_API_FlushMessageBuffer</code>. Wallet sends message to server: <code>OT_API_createAssetAccount()</code> Server replies with FAILURE/SUCCESS, and the new account is automatically stored in your wallet (if applicable.) Use <code>OT_API_PopMessageBuffer()</code> to peer inside the server reply. Call <code>OT_API_Message_GetCommand</code> to find out the command (there are many commands possible in an OT message.) Print the command out onto the screen, so you can see what it looks like. That! is the string you want to compare for in your project's code, to make sure you are looking at the correct reply. There may be multiple replies in the buffer, but probably not, since we FLUSHED it before sending the message... Call <code>OT_API_Message_GetSuccess</code> to find out if the reply was SUCCESS or FAILURE. 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.<br />
<br />
<br />
-----<br />
<br />
'''the ''Transaction Number''''' <br>Make sure your wallet always has a supply of transaction numbers. Call <code>OT_API_GetNym_TransactionNumCount()</code> to see how many transaction numbers are currently in your wallet. Call <code>OT_API_getTransactionNumber()</code> to get more numbers when you are running low. (All transactions require a transaction number that was specifically issued to you by an OT Server.) (Your transaction numbers remain outstanding to you until you close out their actual transactions.) You don't have to juggle these transaction numbers--OT does it automatically in your wallet--but you ''do'' need to make sure you have some available, and replenish when they're getting low. I recommend just requesting 10 more of them whenever you have less than 5 available. (OT auto-receives all new #s in reply from the server, and stores them in your wallet.)<br />
<br />
'''Make sure you have the latest intermediary files before doing a transaction:''' <br>All transactions, in addition to requiring a transaction number, also require a ''balance agreement''. (The wallet performs this behind the scenes when you request any transaction.)<br />
<br />
IMPORTANT: 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.)<br />
<br />
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. Really, only the account and inbox will change &quot;behind your back&quot; (that is, on the server side), but you still need to grab the outbox at least once: when you first create an account, before the first transaction. Your balance agreements will succeed as long as you have the latest copies of these files. To retrieve them from the server, call these functions: <br />
<br><code>OT_API_getAccount()</code> <br />
<br><code>OT_API_getOutbox()</code> <br />
<br><code>OT_API_getInbox()</code><br />
<br />
'''You might ask: ''&quot;But what if I download my account, or my outbox, and the server has maliciously inserted data into them?&quot;''' 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>.<br />
<br />
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!'''<br />
<br />
<br />
-----<br />
<br />
'''Deposit cash''' Alice calls <code>OT_API_FlushMessageBuffer</code>. <br>Alice sends message to server requesting deposit: <code>OT_API_notarizeDeposit()</code> <br>Server replies success or failure. <br>Call <code>OT_API_PopMessageBuffer()</code> to get the server reply out of the buffer. Since you just flushed the buffer (above), we already know what kind of message we're expecting to find (it's a &quot;<code>notarizeTransactions&quot; message containing an &quot;atDeposit&quot; transaction.) <br>Call </code>OT_API_Message_GetCommand<code> if you want to see the exact command you're holding, just to make sure you're looking at the right message (See [https://github.com/FellowTraveler/Open-Transactions/blob/master/OTLib/OTMessage.cpp OTMessage.cpp] for all the different commands, if you're curious to see them all + their data!) <br>Call </code>OT_API_Message_GetSuccess@ (and pass it the server reply) to find out if the message was a SUCCESS or FAILURE. <br>'''WARNING: Just because a MESSAGE was successful, does NOT mean that the TRANSACTION INSIDE THAT MESSAGE was also successful!''' The message may have processed normally, yet the server may have still refused the ''transaction inside that message'' for whatever reason (expired, etc.) You might have a perfectly valid message informing you that your cheque deposit ''failed'' due to a bounced cheque.<br />
<br />
FYI, not all messages contain transactions, but deposit cash DOES. You will find this useful:<br />
<br />
If any Message FAILS, it's possible that your Request Number got out of sync. Just call <code>OT_API_getRequest()</code> and then try the message again.<br />
<br />
FOR TRANSACTIONS: If the Message SUCCEEDS, next check to see if the BALANCE AGREEMENT was also successful. (All Transactions must include a balance agreement, which the server will verify before signing, and which will form part of your receipt.)<br />
<br />
To verify the balance agreement, <code>OT_API_Message_GetBalanceAgreementSuccess()</code> will prove useful to you. (Even a perfectly valid transaction will be automatically rejected by the server if the balance agreement is wrong. So you need to check the server's reply and see if your balance agreement was a success.)<br />
<br />
If your balance agreement is failing, it could be because a cron item has expired (payment plan, market offer, etc) and the transaction number has come off of your list (you just don't know it yet.) To fix this, call <code>OT_API_getNymbox()</code> to download any notices of this nature, wait a few MS, '''and then try again.'''<br />
<br />
If your balance agreement is a SUCCESS, then verify the transaction itself to see if it succeeded. To verify a transaction, use <code>OT_API_Message_GetTransactionSuccess()</code> or <code>OT_API_Transaction_GetSuccess()</code>. When this verifies, it means your withdrawal, or deposit, or whatever, actually went through, and you now have a receipt.<br />
<br />
The receipt will be saved automatically into your receipts folder, whether success or fail. The next time you download your inbox, you'll want to call <code>OT_API_VerifyAccountReceipt()</code>, which uses that last receipt to make sure the server isn't screwing you.<br />
<br />
AGAIN: Whenever you download the latest copy of your account balance, or your inbox, or any other such intermediary files, how do you know the server isn't screwing you over by getting you to sign a new balance agreement based on some WRONG balance? Because, you are ALWAYS able to VERIFY those intermediary files against your LAST SIGNED RECEIPT, by calling <code>OT_API_VerifyAccountReceipt()</code>. Do you understand how important that is? It should be performed anytime those intermediary files have been downloaded from the server. This receipt is what protects the client from getting SCREWED. (Do you know what it feels like to get screwed?)<br />
<br />
<br />
-----<br />
<br />
BOX RECEIPTS: Any of the ledger boxes (Nymbox, Inbox, Outbox) now only contain ''abbreviated'' versions of their contents, instead of the full receipts. ''(At some point the boxes had gotten too large to download as a single file, so the contents were separated out into individual files.)''<br />
<br />
Thus, once you download the ledger itself, iterate through it and use <code>OT_API_DoesBoxReceiptExist</code> for each receipt in it. If it doesn't then use <code>OT_API_getBoxReceipt</code> to download it from the server. (Using the normal flush/call/pop pattern to check for success.)<br />
<br />
<br />
-----<br />
<br />
'''NOTE: The new &quot;Ultra-High-Level API&quot; manages all of this complexity for you! See the scripts/samples folder, as well as the Java code for the Moneychanger test GUI, to see examples of it in action. All of the above gets reduced down to a couple of lines of code!'''<br />
<br />
<br />
-----<br />
<br />
'''Account-to-Account Transfer''' <br>Call <code>OT_API_notarizeTransfer()</code> to send a transfer from one asset account to another. (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.)<br />
<br />
<br />
-----<br />
<br />
'''Withdraw Voucher''' A voucher is like a &quot;money order&quot; or &quot;cashier's cheque&quot;. 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.<br />
<br />
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!<br />
<br />
Call <code>OT_API_FlushMessageBuffer</code> <br />
Call <code>OT_API_withdrawVoucher()</code> to send the request to the server.<br />
Then, call <code>OT_API_PopMessageBuffer()</code> to retrieve any server reply.<br />
<br />
If there is a message from the server in reply, then call <code>OT_API_Message_GetCommand()</code> to verify that it's a reply to the message that you sent, and then call <code>OT_API_Message_GetSuccess()</code> to verify whether the message successful.<br />
<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 />
<br />
If it was all a success, next call <code>OT_API_Message_GetLedger()</code> to retrieve the actual &quot;reply ledger&quot; from the server.<br />
<br />
Penultimately, call <code>OT_API_Ledger_GetTransactionByID()</code> and then, finally, call <code>OT_API_Transaction_GetVoucher()</code> in order to retrieve the voucher cheque itself from the transaction.<br />
<br />
<br />
-----<br />
<br />
'''BASKET CURRENCIES'''<br />
<br />
'''Create a new Basket Currency''' <br>First, invent the basket in your head. Give it name: ''&quot;Clams.&quot;'' Next, give it a ratio in terms of other existing currencies: ''&quot;10 Clams equals a basket of 5 dollars, 3 Euro, and 20 Bitcoin&quot;'' Call <code>OT_API_GenerateBasketCreation()</code> to begin creating the basket. The ''&quot;10 Clams&quot;'' 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 ''&quot;5 dollars&quot;'' the ''&quot;3 Euro&quot;'' and the ''&quot;20 Bitcoin&quot;'' 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.)<br />
<br />
'''Exchange Digital Assets in/out of a Basket Currency (from your Asset Accounts)''' <br>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 &quot;transfer multiple&quot; in that call. What's the transfer multiple? Remember the ratio above: &quot;10 Clams equals a basket of 5 dollars, 3 Euro, and 20 Bitcoin&quot;<br />
<br />
Here are examples of the transfer multiple: <br />
<br>&quot;10 Clams == 5 USD, 3 EUR, 20 BIT&quot; (Transfer multiple: 1) <br>&quot;20 Clams == 10 USD, 6 EUR, 40 BIT&quot; (Transfer multiple: 2) <br>&quot;30 Clams == 15 USD, 9 EUR, 60 BIT&quot; (Transfer multiple: 3) <br>&quot;40 Clams == 20 USD, 12 EUR, 80 BIT&quot; (Transfer multiple: 4) <br>&quot;50 Clams == 25 USD, 15 EUR, 100 BIT&quot; (Transfer multiple: 5)<br />
<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.<br />
<br />
Now that it's all set up, call <code>OT_API_exchangeBasket()</code> to actually message the server and perform the exchange.<br />
<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 />
<br />
'''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!<br />
<br />
<br />
-----<br />
<br />
'''PROCESSING YOUR INBOX'''<br />
<br />
'''Process the Receipts and Pending Transfers in your Inbox''' <br>Call <code>OT_API_FlushMessageBuffer</code> <br>Call <code>OT_API_getInbox()</code> to grab the latest inbox from the server. <br>Then, call <code>OT_API_PopMessageBuffer()</code> to retrieve any server reply.<br />
<br />
You will also probably want to call <code>OT_API_getAccount</code> as well as <code>OT_API_getOutbox</code>, using the above method, since you need to have the latest versions of those files, or your balance agreement will be calculated wrong, causing your transaction to fail. NOTE: You only have to getOutbox for a brand new account. After that, OT will keep it in sync automatically. But the Account and the Inbox need to be downloaded all the time, since they change on server side occasionally.<br />
<br />
Then call <code>OT_API_LoadInbox()</code> to load the inbox ledger from local storage.<br />
<br />
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 &quot;Process Inbox&quot; and then you do this:<br />
<br />
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. <br>Use that count to LOOP through them... 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.<br />
<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 />
<br />
<br />
-----<br />
<br />
'''MARKETS and PAYMENT PLANS'''<br />
<br />
'''Setup a Payment Plan''' <br />
<br>The Merchant draws up the Payment Plan using <code>OT_API_ProposePaymentPlan</code> <br />
<br>Then he sends it to the Customer, who calls <code>OT_API_ConfirmPaymentPlan</code> <br />
<br>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.) <br />
<br>Use OT_API_cancelCronItem() to cancel any payment plan (or market offer.)<br />
<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 />
<br />
'''Issue a [[Markets|Market]] Offer'''<br />
<br />
Clear the reply buffer: <br />
<br>Call <code>OT_API_FlushMessageBuffer</code>. <br />
<br>Call this function: <code>OT_API_issueMarketOffer()</code> <br />
<br>Server replies with FAILURE/SUCCESS... <br />
<br>Use <code>OT_API_PopMessageBuffer()</code> to grab a copy of the server reply. <br />
<br>Call <code>OT_API_Message_GetCommand</code> to verify it's the correct one. (There may be multiple replies in the buffer, but probably not, since we FLUSHED it before sending the message...) <br />
<br>Call <code>OT_API_Message_GetSuccess</code> to find out if the message was a SUCCESS or FAILURE. 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 />
<br />
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.<br />
<br />
'''Cancel a Market Offer''' <br>Use <code>OT_API_cancelNymMarketOffer</code> to remove an offer from a market. Use Flush / Pop / GetSuccess as above, to see if your call was a success. <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 />
<br />
'''Retrieving Market Data from OT Server:''' <br><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: <code>if (otapi.Exists(&quot;markets&quot;, serverID, &quot;market_data.bin&quot;)) bFoundFile = true;</code><br />
<br />
Here is some Java code that reads the market list object from local storage, assuming bFoundFile is true:<br />
<br />
<pre> MarketList marketList = null;<br />
Storable storable = null;<br />
<br />
if (otapi.Exists(&quot;markets&quot;, serverID, &quot;market_data.bin&quot;)) <br />
{<br />
storable =<br />
otapi.QueryObject(StoredObjectType.STORED_OBJ_MARKET_LIST,<br />
&quot;markets&quot;, serverID, &quot;market_data.bin&quot;);<br />
if (storable==null)<br />
return null;<br />
marketList = MarketList.ot_dynamic_cast(storable);<br />
}</pre><br />
Once you have the market list, here is some sample Java code to read the details of an individual market from that list:<br />
<br />
<pre>public static Object getMarketDetails(String marketID)<br />
{<br />
MarketList marketList = Utility.getMarketList();<br />
<br />
if (marketList == null) <br />
{<br />
return null;<br />
}<br />
<br />
for (int i=0; i &lt; marketList.GetMarketDataCount(); i++)<br />
{<br />
MarketData marketData = marketList.GetMarketData(i);<br />
<br />
if (marketData == null)<br />
continue;<br />
<br />
String [] row = new String[2];<br />
<br />
if (marketID.equals(marketData.getMarket_id())) <br />
{<br />
String[] data = new String[2];<br />
marketData.getLast_sale_price();<br />
marketData.getCurrent_ask();<br />
<br />
// Etc!! This is where you get the market details.<br />
}<br />
}<br />
<br />
// return custom object here (row/data or whatever), or null if failure..<br />
return null;<br />
}<br />
</pre><br />
<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><br />
<br />
(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.)<br />
<br />
<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><br />
<br />
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><br />
<br />
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> <br>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.) <br>As before, the appropriate data object can be found in testwallet/OTAPI.i along with all the others.<br />
<br />
<br />
-----<br />
<br />
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.<br />
<br />
See also: <br />
<br>[[API|The OT API]]<br />
<br>[[Installation]] <br />
<br>[[Test Wallet commands]]<br />
<br />
<br>[[List of Classes|The OT C++ class library]]<br />
<br />
'''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).</div>Cryptomanhttp://opentransactions.org/wiki/index.php?title=GUI_Notes&diff=114GUI Notes2013-06-12T16:13:00Z<p>Cryptoman: Created page with "the GUI will have several levels 1 THE SHELL. This is similar to the current test wallet. It will be a Python (maybe Java) shell that allows users to interface with OT func..."</p>
<hr />
<div>the GUI will have several levels<br />
<br />
1 THE SHELL. This is similar to the current test wallet. It will be a Python (maybe Java) shell that allows users to interface with OT functionality in a PROGRAMMATIC way. All GUI actions trigger off shell actions which can be viewed, reissued, and logged. Also scripts can be written in Python that can automate actions in the GUI. These scripts can be used to automate the installation and setup of various financial environments. Also there is BeanShell [[http://www.beanshell.org/manual/contents.html]], as well as JPython (but I don't think that offers us much, I want the install cradle to be as small as possible).<br />
<br />
2 EXPERT GUI. For people who understand underlying concepts like Nyms, Server Contracts, etc. Allows people to view Nyms, Server Contracts, Asset Contracts, and just about anything that shows up in the OT API. Most of these things are too confusing for the average person who simply wants to trade tokens, make simple payments, etc. thus we have the BASIC GUI. Many things will be set as defaults on installation that can be changed at the EXPERT level, for instance the default Nym and the default Account. Accounts have names which can be referenced in OTTP links by keyword. These ACCOUNT - to - NAME relationships can be set at this level. For most users, these settings will not change.<br />
<br />
3 BASIC GUI. Supports easy to use features like Payment, Account Management, etc. many aspects of OT are predetermined at this level and these controls are designed for very simple users. It supports simple notions of Account Balance, Payment, Voucher and Check Acceptance. It models on the assumption that the user thinks he has one identity and one account on one server (even though the GUI supports many). Can issue checks and vouchers either by C&P or creates files in the file system which then can be posted to a Web App, or sent in email, etc. This is the GUI that is most visible, the EXPERT and SHELL levels are a few clicks away.<br />
<br />
<br />
JAVA seems like an attractive platform, but Python is also attractive. Fact is that to distribute you need C++ compilation for the OT files so a Java GUI doesn't buy you instant platform independence.</div>Cryptomanhttp://opentransactions.org/wiki/index.php?title=Test_Wallet_commands&diff=113Test Wallet commands2013-06-12T16:11:04Z<p>Cryptoman: Created page with "''You probably will prefer the high-level CLI which, like the high-level APIis much more easy to use, and basically automates all of the complexi..."</p>
<hr />
<div>''You probably will prefer the [[Opentxs | high-level CLI]] which, like the [[Use Cases | high-level API]]is much more easy to use, and basically automates all of the complexity of OT. Whereas the low-level CLI described on this page, similar to the [[API | low-level API]], is &quot;experts only&quot; and you probably don't even want to mess with it at all.''<br />
<br />
Warning: The below notes are not relevant to you unless you plan on doing low-level OT work! Otherwise use the high-level command-line interface, [[Opentxs | opentxs]]. The [https://github.com/FellowTraveler/Open-Transactions/tree/master/scripts/samples sample scripts] are particularly good.<br />
<br />
If you prefer a GUI client, check out [https://github.com/FellowTraveler/Moneychanger/wiki Moneychanger].<br />
<br />
============================================================<br />
<br />
'''NOTE: The below command line instructions are probably too low-level for your tastes.'''<br />
<br />
'''Instead, recommend you start with the higher-level''' [https://github.com/FellowTraveler/Open-Transactions/tree/master/scripts/samples/ sample scripts].<br />
<br />
'''This OT CLI is the command-line equivalent of the OT LOW LEVEL API. It includes no built-in synchronization, retries, timeouts, downloads, etc. Experts only!'''<br />
<br />
<pre>OT CLI Usage: <br />
<br />
ot --stat (Prints the wallet contents) ot --prompt (Enter the OT prompt)<br />
ot [-h|-?|--help] (Prints this help) ot --script (assumes script until eof)<br />
The '|' symbol means use --balance or -b, use --withdraw or -w, etc.<br />
The brackets '[]' show required arguments, where default values are<br />
normally expected to be found in: ~/.ot/command-line-ot.opt<br />
ot --balance | -b [--myacct &lt;acct_id&gt;] (Display account balance)<br />
ot --withdraw | -w &lt;amount&gt; [--myacct &lt;acct_id&gt;] (Withdraw as CASH)<br />
ot --transfer | -t &lt;amount&gt; [--myacct &lt;acct_id&gt;] [--hisacct &lt;acct_id&gt;]<br />
ot --cheque | -c &lt;amount&gt; [--myacct &lt;acct_id&gt;] [--hisnym &lt;nym_id&gt; ]<br />
ot --voucher | -v &lt;amount&gt; [--myacct &lt;acct_id&gt;] [--hisnym &lt;nym_id&gt; ]<br />
ot --depositcheque [--myacct &lt;acct_id&gt;] (Deposit a cheque.)<br />
ot --depositpurse [--myacct &lt;acct_id&gt;] (Deposit a cash purse.)<br />
ot --deposittokens [--myacct &lt;acct_id&gt;] (Deposit individual cash tokens.)<br />
ot --inbox | -i [--myacct &lt;acct_id&gt;] (Display the inbox.)<br />
ot --sign | -s [--mynym &lt;nym_id&gt; ] (Sign a contract.)<br />
ot --verify [--mynym &lt;nym_id&gt; ] (Verify a signature.)<br />
ot --purse | -p &lt;arguments&gt; (Display a purse.)<br />
Arguments: [--mynym &lt;nym_id&gt; ] [--mypurse &lt;asset_type_id&gt;]<br />
ot --refresh | -r [--myacct &lt;acct_id&gt;] (Download account files from server.)<br />
ot --refreshnym [--mynym &lt;nym_id&gt; ] (Download nym files from server.)<br />
ot --marketoffer [--mynym &lt;nym_id&gt; ] (Place an offer on a market.)<br />
Also, [--server &lt;server_id&gt;] will work with all of the above.<br />
<br />
Recurring payments:<br />
ot --proposeplan &lt;arguments&gt; (Merchant)<br />
Arguments: [--mynym &lt;nym_id&gt; ] [--myacct &lt;acct_id&gt;] (continued.)<br />
Continued: [--hisnym &lt;nym_id&gt; ] [--hisacct &lt;acct_id&gt; ]<br />
ot --confirmplan &lt;arguments&gt; (Customer)<br />
ot --activateplan &lt;arguments&gt; (Customer again)<br />
Arguments: [--mynym &lt;nym_id&gt; ] [--myacct &lt;acct_id&gt;]</pre><br />
<br />
-----<br />
<br />
(Type <code>ot --prompt</code> to enter the prompt.)<br />
<br />
'''THE OT PROMPT COMMANDS'''<br />
<br />
Command-line testwallet <br />
<br>'''stat''' - Display wallet contents.<br />
<br />
(Yes, that's just a 'c' by itself down there.)<br />
<br />
'''c''' - Sends a checkServerID command. This is OTLib's &quot;Ping&quot;. It's the wallet pinging the notary, and verifying to both sides that each can encrypt/verify with the other.<br />
<br />
'''r''' - Register a new user account (using first Nym in wallet.) (Register will fail for you because I already registered with this Nym. So you can just START USING IT, since it's already registered. Ignore this command, in other words.)<br />
<br />
'''u''' - Sends a checkUser command (retrieves public key based on userID)<br />
<br />
'''s''' - Encrypts a message and drops it into another user's nymbox.<br />
<br />
'''g''' - Ask the server to send me the current request number. If you get errors that the request number is wrong, use this and then try again. (It must always be in sync. This command is what re-syncs it.)<br />
<br />
'''issue''' - Issue new currency. (It will ask for the currency contract.) The wallet will ask you for the currency contract and then create an issuer account. The public key in the currency contract must be the same as the Nym's public key, AND the signature on the contract must verify with that same key.<br />
<br />
(I already uploaded the silver contract, which is why you see it in your wallet as though you are the issuer of that currency -- because you are.)<br />
<br />
'''getcontract''' - Get server's copy of any currency contract, by asset type ID.<br />
<br />
'''getmint''' - Get the server's copy of the public Mint file (contains public keys for each asset type. This is needed in order to make withdrawal requests for any given asset type.) If the public mint file doesn't yet exist on the server side, then this will fail. To create a new mint, go to the transaction/data_folder and run ./createmint.exe (the OT server, long term, will need to execute that program as a separate process, whenever a new asset type is issued. Otherwise the entire server would grind to a halt as the new keys were being generated for the mint.)<br />
<br />
'''a''' - create asset account. (Of any type, including any Basket Type ID, which is used like another asset type ID.)<br />
<br />
'''get''' - Get latest copy of one of my asset accounts (by account ID). This also causes the testwallet to get the outbox and inbox.<br />
<br />
'''n''' - Ask the server to send me a new transaction number. (If you ever get an error related to being out of transaction numbers, just use this. Sometimes you just run out of them, and you need more from the server.) As a utility tool, if you append a long integer as the first parameter, then OT will add that number to the Nym as if it were a signed-for transaction number.<br />
<br />
'''y''' - After you ask for a few more transaction numbers, you will need to download your Nymbox so you can get them and sign for them.<br />
<br />
'''py''' - Usually whenever downloading your Nymbox, you want to just do this one next. (It will process all the nymbox items, which is necessary in order to accept and sign-for new transaction numbers.)<br />
<br />
'''t''' - Initiate transfer from my account into another account's inbox (with a pending notice being put into my outbox).<br />
<br />
'''i''' - getInbox from the server so I can decide what to do with it. (There will be pending notices, cheque receipts, etc. I need to go through them all and accept or reject them.)<br />
<br />
'''pi''' - After getInbox, use this to just accept everything in your inbox.<br />
<br />
NOTE: Obviously a real GUI client would merely display the inbox to the user, where the user could choose whether or not to accept the items individually. The API offers faculties for doing this.<br />
<br />
'''o''' - getOutbox from the server so my balance statements don't fail. (All transactions now require a signed balance receipt, which includes data on the inbox items, the outbox items, the current account balance, and the current list of transaction numbers that are signed out to me. Your outbox should never change on the server side, but if you ever need to re-download a copy of it, you will be able to verify it against the last signed receipt.)<br />
<br />
'''w''' - Withdraw cash and save to a purse. (It will ask for Account ID and amount.)<br />
<br />
Note on token format: the individual notes are stored with the internal Lucre data '''encrypted''' to the user's Nym. So even if the tokens were stolen in plaintext, they still could not be used--because the internal Lucre data member is still encrypted. As long as you keep backups of your financial data, they cannot be lost, nor can they be stolen simply by the files becoming compromised.<br />
<br />
'''v''' - Withdraw voucher. (This is like a cashier's cheque. The server removes funds from your account, then issues you a cheque drawn on one of the server's accounts.)<br />
<br />
'''q''' - Deposit cheque. (You can also deposit vouchers here.)<br />
<br />
'''d''' - Deposit cash. (Will ask for Account ID and Cash Note.)<br />
<br />
NOTE: When making a deposit, the test client automatically re-encrypts the Lucre data (internal to the token) to the SERVER's nym, so that the server will be able to process the tokens. Similarly, if you wanted to give some tokens to a friend, using a nice GUI, you would simply drag the gold over to his name, and then your wallet would re-encrypt the internal Lucre Data of each token to his public key, and then send the tokens to him. Future options include exporting to a passphrase, or in the clear.<br />
<br />
'''p''' - Deposit a purse full of cash. (It will ask for the Account ID and and Purse.)<br />
<br />
'''cheque''' - Write a cheque. You can do this offline but you need to have at least one transaction number laying around to write it with.<br />
<br />
'''basket''' - Create a basket currency. (It will ask for the basket details, and lead you through the process.)<br />
<br />
NOTE: The wallet will ask for the number of asset types in the basket, then the '''minimum transfer amount''' for the basket itself, then it will ask for each asset type ID followed by the minimum transfer amount for that asset type. For example: I might create a new basket currency called the Rand, defined as, 10 Rand = [$50, 2 gold g, and 10 silver oz]. Those numbers would serve as the '''minimum transfer amount''' for each asset type, with all transfers being a multiple of those numbers.<br />
<br />
Normally when you issue a currency, you are given an issuer account by the server. This account is allowed to go negative, and you can transfer to whoever you wish based on the terms of your currency contract. And with a basket currency, an issuer account is also created. But.. instead of handing control of that issuer account over to the user who defined the basket, the server manages it internally. Each basket account has its own internal asset accounts to store the reserves for the basket. Whenever users exchange in or out of a basket, the various assets are moved in or out of those internal asset accounts. After this point, an asset account storing a basket currency is no different than any other asset account, as far as the server is concerned. It's just another asset type ID. Due to this, baskets also support infinite nesting yet with no additional system resource usage.<br />
<br />
'''exchange''' - Exchange from asset accounts, in and out of basket accounts. This is where the magic happens.<br />
<br />
Any exchange in or out is based on a multiple of the minimum transfer amount. So I could transfer into 10 Rand, or 20, or 30, or 40, etc. Any multiple of 10, since 10 is the minimum amount. I would have to trade ($50, 2 gold, and 10 silver) times 1, or 2, or 3, etc for the exchange. Once the user has Rands in his Rand asset account, he can trade it with other Rand asset accounts in any amount he wishes, with no minimum amount. The minimum amount is only for exchanging in and out of the basket.<br />
<br />
'''payment''' - Create a payment plan (like WRITING a cheque). ''plan'' - Activate a payment plan (like DEPOSITING a cheque).<br />
<br />
'''offer''' - Put an Offer onto a Market.<br />
<br />
'''setnymname''' - Set a Nym's name (merely a client-side label.)<br />
<br />
'''setaccountname''' - Set an Asset Account's name (merely a client-side label.)<br />
<br />
'''signcontract''' - Allows you to input a contract and sign it with the current Nym.<br />
<br />
'''decode''' - Decodes base64-encoded data at the command line. <br />
<br />
'''encode''' - Base64-encodes data at the command line.<br />
<br />
'''decrypt''' - If you have already loaded your Nym, you can use this to decrypt messages at the command line.<br />
<br />
'''clear''' - Clears all of the transaction numbers from a Nym. Low-level tool!<br />
<br />
'''clearreq''' - Clears all the request numbers from a Nym. Low-level tool!<br />
<br />
Deprecated: (happens automatically now) <br />
<br />
'''load''' -- Load wallet.xml from the data_folder. (Do this first.)<br />
<br />
NOTE: The below commands are for TCP / SSL mode only. (You can '''IGNORE''' them.)<br />
<br />
'''connect''' - Connect to the first server on the wallet's list.<br />
<br />
# - Sends a type 1 header command to the server, with no payload. <br />
# - Sends a deliberately-malformed command to the server. <br />
# - Sends a signed XML message in the payload, but with no XML requests.</div>Cryptomanhttp://opentransactions.org/wiki/index.php?title=Future_Direction&diff=112Future Direction2013-06-12T15:49:31Z<p>Cryptoman: 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 ..."</p>
<hr />
<div>'''''Every camera phone is a potential customer!'''''<br />
<br>'''''Every computer monitor is a potential cash register!'''''<br />
<br />
How can this be? It's actually pretty simple:<br />
<br />
'''2D Barcodes'''<br />
<br />
STEP ONE: <br />
<br>1) The cashier, Alice, rings up Bob's purchase. His total is: 98 Clams. <br />
<br>2) The &quot;cash register&quot; (Alice's computer, running OT) creates an invoice with a total of 98 Clams. <br />
<br>3) The &quot;cash register&quot; posts the invoice at a url:<nowiki> https://AliceStore.com/invoices/kd893734j</nowiki> <br />
<br>4) The &quot;cash register&quot; generates a '''[https://encrypted.google.com/search?hl=en&amp;source=hp&amp;q=2d+barcodes|2D barcode]''' which contains the URL, and ''displays it on the screen''.<br />
<br />
STEP TWO: <br />
<br>1) Bob pulls out his camera phone, running an OT wallet... '''with a software barcode reader'''... <br />
<br>2) '''Beep'''. Bob's phone scans the barcode on the screen, reads the URL from it, and downloads the invoice. <br />
<br>3) Bob's phone displays: &quot;AliceStore, 98 Clams&quot;. <br />
<br>4) Bob clicks &quot;accept purchase&quot;, and his wallet runs the invoice through his account.<br />
<br />
Purchase complete! With receipts on both sides.<br />
<br />
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!<br />
<br />
<br />
-----<br />
<br />
'''''Future (planned or potential) types of financial instruments that should be added to Open Transactions:'''''<br />
<br />
'''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 &quot;name on the books&quot; is allowed to be changed.<br />
<br />
'''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.<br />
<br />
'''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.<br />
<br />
'''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.<br />
<br />
'''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 &quot;X out of Y&quot; rules defined about the authorization needed for transactions on a given account.<br />
<br />
'''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.<br />
<br />
From there we'd want to add: <br />
* Signing an escrow contract in advance that allows custom terms. <br />
* Configuration of which parties are adding assets, and which parties are allowed to view the assets. <br />
* Configuration of how many parties must sign off on closing the transaction (X out of Y algorithm.) <br />
* Many contracts may be self-closing (by putting terms into the contract so the server can process them.)<br />
<br />
<br />
-----<br />
<br />
New thoughts (voting groups, and group control of funds):<br />
<br />
* I realized that OT is the ideal library to add classes for voting protocols.<br />
* ...Using existing asset accounts (for share ownership of stocks), OT is capable of weighted voting.<br />
* ...Using the existing mint and token classes, OT is capable of secret ballots. (Using chaumian blinding...)<br />
* ...Using existing inboxes, ballots could be sent to relevant Nyms.<br />
* Then I realized that a class could be written, a VOTING GROUP, maybe &quot;OTVoterGroup&quot;, 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.<br />
* 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.<br />
* Then I realized that a &quot;political body&quot; 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.<br />
* 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 &quot;dictator&quot; (CEO).<br />
* 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.<br />
* 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.<br />
* The board just selects the dictator of the top &quot;department&quot; (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)<br />
* This is all possible from only adding a couple of classes: voting group, ballot, political body, and department.<br />
* 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.<br />
* 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.<br />
* A corporation itself would be an actual &quot;articles of incorporation&quot; filed as a contract (probably a SMART CONTRACT)<br />
* 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.<br />
<br />
Think of how powerful that could be, just from adding a few extra classes!! Most of it uses pieces that are already working.<br />
<br />
<br />
-----<br />
<br />
.....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.'''<br />
<br />
.....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.'''<br />
<br />
.....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.''<br />
<br />
.....Android client, Windows client, iPhone client, iPad client, Java client, Mac OSX client...<br />
<br />
.....High-level interfaces for developers. '''Build this library into a multitude of different software apps.'''<br />
<br />
.....Integrate with popular Wordpress payment processing plugins. '''So the Internet can become digital-cash enabled overnight...'''<br />
<br />
.....Integrate with Anonymous Remailers, Nym Servers, and other projects that would benefit.<br />
<br />
.....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.'''<br />
<br />
<br />
-----<br />
<br />
'''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).<br />
<br />
WHAT IS '''&quot;Open Transactions&quot;''' ? <br />
* It's a solid, [[Use Cases|easy-to-use]], '''FINANCIAL CRYPTO''' and '''[[Sample Cash|DIGITAL CASH]]''' [[List of Classes|LIBRARY]]. <br />
* Including an operational '''[[API]]''', '''SERVER''' and [[Test Wallet commands|CLIENT]].<br />
<br />
Featuring: <br />
* '''Untraceable Digital Cash''' (real blinded tokens). <br />
* '''Pseudonymous User Accounts''' (&quot;user account&quot; == PGP key). <br />
* Many '''[[Instruments|Financial Instruments]]''' ([[Sample-Cheque|cheques]], [[Sample Cash|cash]], vouchers, invoices, transfers, etc). <br />
* '''Anyone An Issuer''' ([[Sample Currency Contract|Ricardian-style Contracts]]) <br />
* '''[[Triple-Signed Receipts]]''' (&quot;asset account&quot; == the receipt). <br />
* '''Basket Currencies''' <br />
* NEW! '''[[Markets]] with Trades''' <br />
* NEW! '''Payment Plans''' <br />
* NEW! '''Native [[API]]''' now available in '''Java, Ruby, Python, PHP, Perl, C, C++, Objective-C, C#, Tcl, and LISP.''' <br />
* NEW! Open Transactions as a '''Web Service''' (''XmlRpc'' / ''HTTP'' [[Messaging|transport]] now available.) <br />
* [[Future Direction|Soon]]: Stocks that pay dividends, Bonds that pay interest, and Collateralized Debt Obligations. <br />
* [[Future Direction|Soon]]: '''2-D Barcodes''' to make possible '''&quot;Any screen a cash register&quot;''' and '''&quot;Any camera phone a customer.&quot;''' <br />
* [[Future Direction|Soon]]: Multi-signer Escrow<br />
<br />
Please see the '''[[Use Cases]]''', '''[[FAQ]]''', '''[[Business Cases]]''', '''[[Installation|Install Notes]]''' and the '''[[Release Notes]]'''</div>Cryptomanhttp://opentransactions.org/wiki/index.php?title=Data_models&diff=111Data models2013-06-12T13:53:10Z<p>Cryptoman: Created page with "This page is about clarifying the Data Model WALLETS HAVE: any number of NYMS (Pseudonyms) any number of SERVER CONTRACTS (transaction servers) any number of ASSET CONTRACTS ..."</p>
<hr />
<div>This page is about clarifying the Data Model<br />
<br />
WALLETS HAVE: any number of NYMS (Pseudonyms) any number of SERVER CONTRACTS (transaction servers) any number of ASSET CONTRACTS (asset types) any number of ASSET ACCOUNTS (where funds go) a CASH PURSE for each ASSET TYPE<br />
<br />
A NYM may be registered at any SERVER, and will have the same NYM ID (and public key) on every server.<br />
<br />
An ASSET CONTRACT may be registered at any SERVER, and will have the same ASSET TYPE ID on every server.<br />
<br />
A NYM may create many ASSET ACCOUNTS on any SERVER. An Asset Account lives on a single server. (A &quot;smart wallet&quot; will abstract a single &quot;account&quot; in the user's interface across an actual LIST of accounts that reside on multiple servers.)<br />
<br />
Each ASSET ACCOUNT has 1 ASSET TYPE (the currency contract), 1 SERVER (the server contract), and 1 Nym (the owner/signer). Even BASKET CURRENCIES have 1 ASSET TYPE: the basket contract. Within that basket contract, multiple asset types are listed, with their IDs and their ratios, based on the formula:<br />(x * Basket_Currency) == (y * Member_CurrencyA) + (z * Member_CurrencyB) + ...<br />
<br />
<br />
-----<br />
<br />
A LEDGER stores a list of TRANSACTIONS.<br />
<br />
A TRANSACTION stores a list of TRANSACTION ITEMS. Currently any transaction has two items: the transaction's main item (deposit item, withdrawal item, etc), as well as the &quot;balance agreement&quot; item (The balance agreement must be successful, otherwise the transaction will be rejected by the server.)<br />
<br />
The server includes a copy of your request in its receipt. (Whether success or fail.) As long as you keep that last signed receipt, then you don't have to store any other transaction history, and the receipt will prove your current account balance, as well as prove ''which instruments are authorized'', and ''which transactions have closed''. (This is also what prevents the server from forging transactions, or changing balances, without permission.)<br />
<br />
In practice, whenever you download a copy of your intermediary files, a &quot;smart wallet&quot; will verify them against the last receipt and make sure none of them are invalid (which would disable the wallet's ability to submit any new transactions, since of course it wouldn't sign any false balance agreements, and would set up a dispute with the server.) The current &quot;Moneychanger&quot; test GUI has a &quot;Verify&quot; button, if you want to test calling the API function for verifying the last receipt. (Note: this function always fails until the first transaction has been performed, since ''a new account has no receipts''.)<br />
<br />
<br />
-----<br />
<br />
The INBOX is a LEDGER. (Used for receiving INCOMING TRANSFERS, as well as RECEIPTS.) The OUTBOX is a LEDGER. (Used for storing my PENDING OUTGOING TRANSFERS, as they await signed acceptance by the recipient.) The NYMBOX is a LEDGER. (Used for receiving MESSAGES and for receiving NEW TRANSACTION NUMBERS, which must be signed for.)<br />
<br />
Ledger objects are also used inside the OT messages, whenever you need to signal acceptance or rejection of specific transactions that are sitting in your inbox. Transactions are always stored as a list, inside a ledger.<br />
<br />
<br />
-----<br />
<br />
A PURSE contains a specified amount of cash, stored as a list of TOKENS of various denominations.<br />
<br />
<br />
-----<br />
<br />
If you want to deposit some cash, your MESSAGE (a &quot;deposit&quot; transaction request message) will contain a LEDGER, which will contain a &quot;DEPOSIT&quot; TRANSACTION, which contains a &quot;BALANCE AGREEMENT&quot; TRANSACTION ITEM as well as the actual &quot;DEPOSIT&quot; TRANSACTION ITEM, which contains a PURSE, which contains the list of TOKENS.<br />
<br />
<br />
-----<br />
<br />
A NYM has a list of REQUEST NUMBERS. (ONE for EACH SERVER that the Nym is registered at.) These request numbers must stay in sync, and they increment with each message sent. Normally, they stay in sync automatically. If they go out of sync, your messages to that server will start to fail (there is an API call that will re-sync them.) This prevents replay attacks (where an attacker intercepts the message and sends it multiple times.)<br />
<br />
FOR EACH SERVER A NYM IS REGISTERED AT: A NYM has a list of TRANSACTION NUMBERS '''available''', as well as a list of TRANSACTION NUMBERS '''still responsible for'''. (Two lists for each server.) A Nym must &quot;sign out&quot; specific transaction numbers beforehand, and store a supply of them, and attach one to each transaction request.<br />
<br />
For example, if I'm responsible for transaction #14, then I have to sign for it ''in every balance agreement''. So Transaction #14 will appear on my AVAILABLE list, as well as my RESPONSIBLE FOR list, ON EVERY &quot;balance agreement&quot; thereafter...<br />
<br />
But once I actually write a cheque using #14, my wallet will remove #14 from my AVAILABLE list. (It's still in my RESPONSIBLE FOR list.) Then once the cheque is deposited by the recipient, the OT Server will also remove #14 from my AVAILABLE list. (It's still on my RESPONSIBLE FOR list on the server side at this point as well.)<br />
<br />
Once I process my inbox and accept the CHEQUE RECEIPT for #14 (accepting the new balance), then the server will remove #14 from my RESPONSIBLE FOR list (I no longer have to sign for that number, as far as the server is concerned) Once my wallet receives the SUCCESS server reply regarding this, my wallet will then also remove #14 from my RESPONSIBLE FOR list (now I'm free of it; I will no longer sign for that number on any future balance agreements.)<br />
<br />
<br />
-----</div>Cryptomanhttp://opentransactions.org/wiki/index.php?title=Config_files&diff=110Config files2013-06-12T13:48:09Z<p>Cryptoman: Created page with "'''.ini file:''' When either the OT Server (transaction.exe), or the OT command-line test client (testwallet.exe) starts up, it tries to read from the ini file. The '''locati..."</p>
<hr />
<div>'''.ini file:'''<br />
<br />
When either the OT Server (transaction.exe), or the OT command-line test client (testwallet.exe) starts up, it tries to read from the ini file. The '''location of the ini file''' is subject to change but for now, it is: <code>C:\ot.ini</code> (Windows systems) <code>~/.ot_ini</code> (Non-Windows)<br />
<br />
If the ini file fails opening, then OT will assuming the data_folder path is: <code>./data_folder</code><br />
<br />
The ini file currently only stores the DEFAULT PATHS for the data_folder. Here's the ini file on my system (located at <code>~/.ot_ini</code>):<br />
<br />
<pre><br />
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;<br />
;; Open-Transactions ini file<br />
<br />
[paths]<br />
client_path=/Users/au/Projects/Open-Transactions/testwallet/data_folder<br />
server_path=/Users/au/Projects/Open-Transactions/transaction/data_folder<br />
</pre><br />
(You don't ''have'' to use the .ini file, it's just a convenience. You'll otherwise have to provide these paths explicitly, whenever you start OT.)<br />
<br />
'''Eventually the ini file will store all sorts of things. Suggestions?'''<br />
<br />
<br />
-----<br />
<br />
'''Config Files'''<br />
<br />
While the ini files are per-user, the config files are per-application. When Open-Transactions starts up, the server and client will each try to read from their respective config files.<br />
<br />
The config file is located relative to the data_folder location. When OT starts up, the initial data_folder path is read either A. from your ini file, or B. passed in on the command line, or C. set by a call to OT_API_Init(const char * szPath).<br />
<br />
Continuing the above example, this &quot;main path&quot; aka &quot;data_folder path&quot; would be: <code>/Users/au/Projects/Open-Transactions/testwallet/data_folder</code><br />
<br />
From there, an OT client will assume that its configuration file is named &quot;ot_client.cfg&quot;, and that it can be found in that folder, but ONE LEVEL UP. That is, <code>/Users/au/Projects/Open-Transactions/testwallet/data_folder/../ot_client.cfg</code> (Meaning, it's actually looking here: <code>/Users/au/Projects/Open-Transactions/testwallet/ot_client.cfg</code>)<br />
<br />
For the OT server, the config file would similarly be located at: <code>/Users/au/Projects/Open-Transactions/transaction/data_folder/../ot_server.cfg</code> aka: <code>/Users/au/Projects/Open-Transactions/transaction/ot_server.cfg</code><br />
<br />
(The location is one level up, SO THAT you can swap out your data_folder indiscriminately, yet without losing your config file each time.)<br />
<br />
Here are the contents of my ot_client.cfg file (located at <code>Open-Transactions/testwallet/ot_client.cfg</code>):<br />
<br />
<pre><br />
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;<br />
;; Open-Transactions client-side config file.<br />
<br />
[logging]<br />
logfile_path=/Users/au/Projects/Open-Transactions/testwallet/ot.log<br />
log_level=3<br />
</pre><br />
'''LOGFILE'''<br />
<br />
If the above <code>logfile_path</code> is set (as above), then the OT API will log to that file. Otherwise all of the logs are outputted to stderr.<br />
<br />
(OT no longer logs to stdout, in preparation for upcoming command-line utilities. )<br />
<br />
The <code>log_level</code> ranges from -1 (no output) to 5 (very verbose / debugging). Use 5 to see many logs. 2 or 3 should be plenty high enough for most people, with 0 and 1 preferred.<br />
<br />
'''What kinds of values would YOU like to see in the config file? Let me know!'''</div>Cryptomanhttp://opentransactions.org/wiki/index.php?title=Installation&diff=109Installation2013-06-12T13:47:16Z<p>Cryptoman: </p>
<hr />
<div>New: We have a preliminary '''apt-get''' install of OT working on 64-bit Ubuntu 12.04. [http://www.reddit.com/r/Agorism/comments/19p6oa/how_to_issue_your_own_currency_using/ Instructions here]<br />
<br />
-----<br />
<br />
BUILDING OPEN-TRANSACTIONS<br />
<br />
We have AUTOMAKE (and Visual Studio for Windows) now! For the latest instructions to build OT, click one of these links:<br />
<br />
[https://github.com/FellowTraveler/Open-Transactions/blob/master/docs/INSTALL-OSX-Homebrew.txt Mac OSX] / [https://github.com/FellowTraveler/Open-Transactions/blob/master/docs/INSTALL-Debian_Ubuntu.txt LINUX Debian Ubuntu] / [https://github.com/FellowTraveler/Open-Transactions/blob/master/docs/INSTALL-Fedora.txt LINUX Fedora] / [https://github.com/FellowTraveler/Open-Transactions/blob/master/docs/INSTALL-Windows.txt Windows]<br />
<br />
Please check out the documentation on the [[config files]]</div>Cryptomanhttp://opentransactions.org/wiki/index.php?title=Installation&diff=108Installation2013-06-12T13:46:11Z<p>Cryptoman: </p>
<hr />
<div>New: We have a preliminary '''apt-get''' install of OT working on 64-bit Ubuntu 12.04. [http://www.reddit.com/r/Agorism/comments/19p6oa/how_to_issue_your_own_currency_using/ Instructions here]<br />
<br />
-----<br />
<br />
BUILDING OPEN-TRANSACTIONS<br />
<br />
We have AUTOMAKE (and Visual Studio for Windows) now! For the latest instructions to build OT, click one of these links:<br />
<br />
[https://github.com/FellowTraveler/Open-Transactions/blob/master/docs/INSTALL-OSX-Homebrew.txt Mac OSX] / [https://github.com/FellowTraveler/Open-Transactions/blob/master/docs/INSTALL-Debian_Ubuntu.txt LINUX Debian Ubuntu] / [https://github.com/FellowTraveler/Open-Transactions/blob/master/docs/INSTALL-Fedora.txt LINUX Fedora] / [https://github.com/FellowTraveler/Open-Transactions/blob/master/docs/INSTALL-Windows.txt Windows]<br />
<br />
Please check out the documentation on the [[config file]]</div>Cryptomanhttp://opentransactions.org/wiki/index.php?title=Auditing&diff=107Auditing2013-06-12T13:40:19Z<p>Cryptoman: Created page with " ----- OUTLINE: ----- '''Scenario:''' Issuer has gold in his warehouse, and he is also operating the transaction server. '''Scenario:''' Issuer has gold in his warehouse,..."</p>
<hr />
<div><br />
-----<br />
<br />
OUTLINE:<br />
<br />
<br />
-----<br />
<br />
'''Scenario:''' Issuer has gold in his warehouse, and he is also operating the transaction server.<br />
<br />
'''Scenario:''' Issuer has gold in his warehouse, but a '''separate entity''' operates the transaction server.<br />
<br />
'''A. Do the issuer and transaction server actually have the incentive to collude?'''<br />
<br />
'''B. Do the issuer and transaction server have the ABILITY to collude?''' (regardless of incentive.)<br />
<br />
'''Scenario:''' Issuer has '''Bitcoin''' in his cold wallet, and he is ''also'' operating the transaction server.<br />
<br />
'''Scenario:''' Issuer has Bitcoin in his cold wallet, but a '''separate entity''' operates the transaction server.<br />
<br />
Thoughts on THE AUDITING PROTOCOL (for GOLD issuers)<br />
<br />
THE AUDITING PROTOCOL (for BITCOIN VOTING POOL)<br />
<br />
'''Scenario:''' The ''Issuer'' is actually a '''Voting Pool''' of transaction servers, with '''Bitcoin''' stored in the pool (on the blockchain.)<br />
<br />
THE LAST SHIELD: Distribution of Risk.<br />
<br />
IN SUMMARY<br />
<br />
PROTOCOL EXAMPLE DETAILS<br />
<br />
CONSEQUENCES<br />
<br />
<br />
-----<br />
<br />
CONTENTS:<br />
<br />
<br />
-----<br />
<br />
'''Scenario:''' Issuer has gold in his warehouse, and he is also operating the transaction server.<br />
<br />
In this case, we are concerned about four things:<br />
<br />
# Does the Issuer actually have the gold in his warehouse? ''(Only a physical audit can tell...)''<br />
# Is the Transaction Server (operated by the Issuer) able to lie on my receipt? ''(No, not even if malicious.)''<br />
# Does the total of ''all'' the receipts, match the amount on the issuer's receipt? ''(This is where inflation occurs. Our auditing protocol needs to verify this.)''<br />
# Does the amount of the issuer's receipt, match or exceed the amount from the physical audit? ''(The result from the physical audit must be compared to the result from the OT receipt audit.)''<br />
<br />
VULNERABILITY: Ultimately even if the physical audits are clean, the issuer COULD one day just ''disappear'' with the gold itself. (That risk always exists as long as the issuer has physical possession.) The best reduction of this risk is based on good governance: being choosy about issuers, based on: separation of powers, auditing protocols, gold storage policies, insurance, bonding, jurisdiction, etc. As well as employing a distribution of risk across multiple issuers (basket currencies, etc.)<br />
<br />
INCENTIVE: An issuer could potentially have a perverse incentive, both to inflate the currency on the receipts, as well as to misreport the amount of physical gold in the warehouse. The issuer also has good incentives (transaction and storage fees, trust being of value in the marketplace, etc.)<br />
<br />
SUMMARY: As long as the gold is physically audited, and there is a secure auditing protocol for OT receipts, ''and'' as long as OT's crypto is secure, then the only vulnerability is the disappearance of the physical gold. Only client-side distribution of risk across multiple issuers can reduce this further.<br />
<br />
<br />
-----<br />
<br />
'''Scenario:''' Issuer has gold in his warehouse, but a '''separate entity''' operates the transaction server.<br />
<br />
Potential dangers:<br />
<br />
# Does the Issuer actually have the gold in his warehouse? ''(Only a physical audit can tell...)''<br />
# Is the Transaction Server able to lie on my receipt? ''(No, not even if malicious.)''<br />
# Does the total of ''all'' the receipts (for that currency) on the transaction server, match the amount on the issuer's last signed receipt? ''(This is where inflation occurs. Our auditing protocol needs to verify this.)''<br />
# Does the amount of the issuer's last signed receipt, match or exceed the amount of the physical audit of the gold held by the issuer? ''(The result from the physical audit must be compared to the result from the OT receipt audit.)''<br />
<br />
VULNERABILITY: The same vulnerability exists as above (that the issuer has physical possession of the gold.)<br />
<br />
INCENTIVE: The issuer has an incentive to earn storage fees. The issuer also has a perverse incentive to disappear with the gold.<br />
<br />
The transaction server, meanwhile, ''does'' have an incentive to continue earning transaction fees. (Note that since many different currencies can be issued on a single transaction server, his fees from ''all currencies'' can come into jeopardy if he loses trust based on a failed audit for only ''one of those currencies.)''<br />
<br />
The transaction server does NOT have a perverse incentive to steal the gold, because he is not holding any of the gold.<br />
<br />
INFLATION<br />
<br />
The transaction server DOES have a perverse incentive to inflate the currency (which auditing is supposed to prevent.) This is because he can spend it even without physical possession of the gold.<br />
<br />
The issuer therefore DOES have an incentive to audit the transaction server. This is because the transaction server '''solely benefits''' from inflation, whereas the issuer solely ends up stuck with the bill.<br />
<br />
<br />
-----<br />
<br />
COLLUSION<br />
<br />
Amiller has proposed that the issuer and transaction server: '''(A) Have incentive to collude''' and '''(B) have the ability to defraud users''' (through their collusion.)<br />
<br />
Let's examine these a bit closer:<br />
<br />
'''A. Do the issuer and transaction server actually have the incentive to collude?'''<br />
<br />
Consider the scenario:<br />
<br />
If Issuer Ivan issues 100,000 grams of gold onto Server Sarah's transaction server, then he is normally supposed to have 100,000 physical grams of gold in his warehouse, as backing for those 100,000 units. Users must trust (and verify) that he does; they have an incentive to be choosy about issuers based on this.<br />
<br />
Let's say that Server Sarah is malicious, and '''she inflates an additional 50,000 grams of gold''' (that don't really exist.) So now, even though Issuer Ivan only has 100,000 physical grams of gold in his warehouse, he is on the hook for receipts totaling 150,000 grams of gold -- 50,000 grams of which ''don't even exist.'' But he owes them, and his ability to attract customers is purely based on their confidence in their ability to someday retrieve their gold from him in physical form.<br />
<br />
Normally, Issuer Ivan's incentive is not to be ''&quot;on the hook&quot;'' for ''gold he doesn't have.'' Especially if Server Sarah is the one ''benefiting'' from this fraud, instead of him. Why should Ivan be on the hook for that money, if he doesn't even get to spend it?<br />
<br />
To tempt him, and based on Amiller's advice, Server Sarah offers '''half the inflated loot''' to Issuer Ivan. ''&quot;We'll split it!&quot;'' she purrs seductively.<br />
<br />
The result of their union? What did each of the two benefit?<br />
<br />
# Server Sarah gets to spend 25,000 grams of inflated gold she did not earn.<br />
# Issuer Ivan is now on the hook for 150,000 grams of gold, including the 25K grams he got from Sarah (as payoff for ignoring the dirty audit.) Yet he only has 100,000 grams of gold in his warehouse.<br />
# Both must permanently avoid audits in the future. This scheme assumes that no other entities have access or incentive to audit those same receipts.<br />
<br />
Did they really ''split'' anything at all? Did Issuer Ivan benefit? He is still on the hook for the full 150,000--not only the 25,000 that he received as loot, but also the 25,000 that Sarah spent as well.<br />
<br />
Issuer Ivan has now taken on an additional 50,000 grams of debt, in order to spend 25,000. Why? And he only has 100,000 grams in his warehouse, not the 150,000 he actually owes. Meaning he is at risk also to lose trust on the market, and thus lose all his yearly storage fees that an issuer would normally earn. (Server Sarah has this same risk, except with ''all'' of her issuers, not just one.) Ivan also would be considered guilty of a crime, since Sarah's inflation is not even possible without Ivan's collusion.<br />
<br />
…All so that Server Sarah gets to go and spend her own 25,000 grams of gold that she did not earn, and does not own, and that Issuer Ivan is now on the hook for. Of course, Ivan got to spend 25,000 grams too, but he is also now legally on the hook for them (as well as Sarah's.)<br />
<br />
Therefore I must ask: What is the incentive for the issuer to collude? He is ''already'' holding all of the gold! Why give any to Sarah at all--why not just disappear with the gold directly? I see this scenario as actually just '''a direct transfer of 25,000 grams of gold, from Issuer Ivan to Server Sarah for absolutely nothing in return!''' Except more debt to Issuer Ivan, and potential loss of all his future income as well, as well as potential for criminal charges. (I say criminal charges because unlike with Bitcoin, Ivan has to store ''physical gold'' and thus he is probably a legal entity in some jurisdiction.)<br />
<br />
So my question is: Are we so SURE that Issuer Ivan really has an incentive to collude with Server Sarah?<br />
<br />
The user already must trust the issuer who holds his gold--he already must ''&quot;buyer beware&quot;'' when it comes to issuers in general. A well-designed wallet ''cough'' should even distribute risk across multiple issuers automatically. But I don't see how the separation of powers here (of the issuer and transaction server into ''two separate entities)'' creates any incentive for the ''issuer'' to collude with the transaction server.<br />
<br />
The transaction server ''does'' have incentive to inflate, which is what auditing should prevent, but I just don't see that the issuer has any incentive to collude with him in doing so but rather, has the ''opposite incentive:'' to ''prevent'' him from doing so.<br />
<br />
(Please show me if I'm missing something here.)<br />
<br />
(This picture shifts slightly with Bitcoin, as I will address towards the bottom.)<br />
<br />
<br />
-----<br />
<br />
'''B. Do the issuer and transaction server have the ABILITY to collude?''' (regardless of incentive.)<br />
<br />
* We already know that the transaction server cannot lie on the receipt of any legitimate user. ''(This is because the user must sign the receipt and the server cannot forge the user's signature.)'' For the same reason, the server cannot lie on the issuer's receipt.<br />
* However, the transaction server ''could'' lie on the receipt of a dummy account. (Where he controls both sides.) ''This is what the auditing protocol is meant to prevent.''<br />
* The transaction server can keep the dummy receipts hidden, but ''he cannot spend the inflated funds without having them flow into a normal account, where they instantly become visible to auditing.'' (Therefore auditing works ''even'' if the dummy account itself remains hidden to the audit.)<br />
* Since the Issuer has an incentive to audit the transaction server, the transaction server has a perverse incentive to collude with the issuer, since this would enable the transaction server to inflate the currency. The issuer could just '''lie,''' pretending there was no inflation, even when an audit clearly shows inflation.<br />
<br />
''(No other crime is possible, anyway: colluders cannot prevent inflated funds from flowing into other accounts, and they cannot pick-and-choose between receipts, since the overall total cannot change without failing the audit. And colluders cannot forge the signatures of any legitimate users. Therefore inflation is the only crime left, absent just freezing the entire directory--which would cause all the user wallets to fail when trying to use that server. And even inflation is still only possible if there are'' '''no other auditors.)'''<br />
<br />
BUT IT '''IS''' PHYSICALLY POSSIBLE: Clearly there ''is'' still at least the ''possibility'' that the issuer ''(whether he operates the transaction server or not)'' could lie and pretend the OT receipt audit was clean, when it actually was not. This means that ''preventing such a possibility mandates having third-party auditors'' who have both ''access'' to the receipts ''and incentive'' to audit them, as amiller has pointed out.<br />
<br />
NO INCENTIVE: I believe '''there is no incentive for the issuer to collude in the first place,''' as explained in the previous section, since he is ''&quot;on the hook&quot;'' for the total of all the receipts. He is the one stuck unable to produce the gold.<br />
<br />
PREVENTION: ...but '''physically preventing him from doing so,''' would necessitate that the receipts not only be shared between the issuer and transaction server, but that ''other auditors must have access to audit those receipts as well.''<br />
<br />
Furthermore, as Amiller has pointed out, others must have an ''incentive'' to audit those receipts, or no one actually will. (I believe I've shown above that the issuer DOES have an incentive to audit the receipts, and furthermore DOES NOT have any incentive to collude with the transaction server, but if we want to prevent the very ''possibility'' of collusion, then we must have other auditors with access and incentive to audit those receipts.)<br />
<br />
<br />
-----<br />
<br />
'''Scenario:''' Issuer has '''Bitcoin''' in his cold wallet, and he is ''also'' operating the transaction server.<br />
<br />
'''Scenario:''' Issuer has Bitcoin in his cold wallet, but a '''separate entity''' operates the transaction server. ''(This scenario will likely never actually happen! See explanation below.)''<br />
<br />
These Bitcoin scenarios are similar to the previous two gold scenarios, with one important distinction:<br />
<br />
While the physical gold audit requires offline governance, '''the &quot;physical&quot; audit of the Bitcoins on the blockchain can be performed programmatically.''' This is a significant advantage over physical gold, but it doesn't change the fact that the issuer ultimately still has to be trusted not to steal those coins.<br />
<br />
Otherwise the incentives are the same:<br />
<br />
# The transaction server has an incentive to maintain trust and earn transaction fees, not just from one issuer but from all issuers.<br />
# The transaction server, if there is a separate issuer, also has a perverse incentive to inflate the currency. ''(Which would be caught on an audit, and so he has an incentive not to get caught--therefore this perverse incentive gets smaller, the more other currencies are issued on that server. For example, if there are 300 currencies issued there, he has less incentive to risk his reputation than if there is only 1.)''<br />
# The transaction server is '''not capable of committing any other crime''' except inflation, and that crime is only possible with collusion from the issuer, whom we already know we must trust (to hold our Bitcoins.)<br />
# The issuer has no incentive to collude with the transaction server to commit inflation (the only possible crime.)<br />
<br />
ANOTHER IMPORTANT DIFFERENCE: The ''gold issuer'' normally has an incentive to maintain trust, to earn storage fees. But a Bitcoin issuer ''cannot'' earn storage fees, since for storage, people will just store their BTC directly on the blockchain. '''He cannot offer storage value,''' only risk. (Whereas physical gold actually has to be stored somewhere and guarded, which is a service of real value.)<br />
<br />
THEREFORE: There will not actually be any BTC issuers on OT, except those who operate their own server! And those will do it for the ''transaction fees,'' not for storage fees.<br />
<br />
THIS MEANS that the ''first'' BTC scenario WILL happen, but that the ''second'' BTC scenario will NOT ever happen.<br />
<br />
This means that so far, the only realistic scenario for issuing BTC on an OT server is: ''A server operator who issues his own BTC-based currency in order to earn transaction fees. He cannot lie on any of his receipts (i.e. the total amount he owes to everybody) but he CAN commit inflation, and he will get away with it unless others are willing/able to audit his receipts. But he cannot lie about the actual amount of BTC stored on the blockchain, since that is visible to all, programmatically.''<br />
<br />
But I believe that '''this scenario will cease to exist as well,''' once voting pools are operational, because voting pools solve everything with a neat bow-tie, as I will explain.<br />
<br />
<br />
-----<br />
<br />
Thoughts on...<br />
<br />
THE AUDITING PROTOCOL (for GOLD issuers)<br />
<br />
# We already know that whenever the server performs a transaction, he must give the user a receipt. This is because the user's wallet will not be able to perform its next transaction unless it is able to verify its intermediary files against the ''last signed receipt.'' Another way of saying this is that the receipt IS the transaction. Furthermore, the receipt IS the account as well.<br />
# I propose that if the users have to get their receipt from a '''specific place,''' and if the auditor has access to that ''same place,'' then inflated funds cannot be spent into any normal user account without those funds appearing on an audit.<br />
# All the auditor has to do is, watch that '''specific place,''' preferably in real time, and ''make sure that all the receipts, including the issuer's receipt, balance to 0.'' And he only ever has to do that with a &quot;current snapshot&quot; of the '''latest receipts''' (not needing any historical receipts for the users.) He could also do a running count (in real time), which is even more preferable. Either way, if the receipts ever fail to balance, the server is summarily dumped and the receipts in the snapshot are just re-issued onto a new transaction server.<br />
# This '''specific place''' (for receipt exchange) doesn't have to be secure like a blockchain, since '''the security is provided by the signatures on the receipts, and not by the storage place itself.''' The transaction server, AND the auditor--even in collusion--cannot forge the receipts of normal users, and even if they could, the grand total would be wrong unless they could forge them all. They also cannot replace a receipt with an older version of itself, since its request number would visibly go backwards. Also, they must keep the receipts current, or the wallets will stop working. They could try to freeze the &quot;public face&quot; of a receipt (continuing to show some older receipt, even when a newer one is now available.) But this would cause the related wallet to fail -- and in order for the grand total to balance, colluders would thus have to freeze ''all'' receipts (they could not pick-and-choose, so ''all'' wallets would thus stop working.)<br />
# This '''specific place''' for receipt exchange doesn't have to store a ''complete history'' like a blockchain does. We only need these receipts around for ''&quot;just long enough.&quot;'' For transactional purposes, any given receipt only needs to be there just long enough for the user to retrieve it. For auditing purposes, it needs to be there long enough for a &quot;snapshot audit&quot; of the receipts, and then it can be erased. (This audit can happen in real time.) The transaction server, also, while it doesn't need to store all receipts, DOES need to store &quot;the last signed receipt&quot; for all users, just to cover its own ass. (Meaning the server cannot ''ever'' destroy its own copy of this &quot;last signed receipt&quot; ''until a new one exists to replace it with.)''<br />
# The &quot;specific place&quot; for receipt exchange could be a network-attached folder at a specific URL, listed in the server contract. (Or listed in the asset contract.) Preferably this place would be a key-value DHT, but it wouldn't have to be. However, I believe a DHT is Voucher-Safe's solution, so it merits attention. Also, since the security is provided by the receipts themselves, it seems that malicious DHT nodes could only potentially disrupt/prevent an audit from succeeding ''(as opposed to fraudulently causing a dirty audit to succeed.)'' The same is true if the receipts are stored in a simple folder--a lying transaction server could freeze the receipts (thus freezing all the wallets) or he could disappear, but both of those actions would just cause the audit to fail. He could ''not'' falsify receipts.<br />
# Transaction receipts can be stored in one folder per currency, and with sequential numbering. Note that OT already stores transaction receipts by receipt hash in a single folder, so this is a modification of that. This '''sequence number''' is something new (not a request number or a transaction number, but a number specifically for each currency's receipts, sequential to the order that they are created.) This sequence number makes it very easy for any interested parties to keep tabs on all the receipts for a given currency, to make sure they have seen them all without gaps, and to see the order that they are created. The transaction server cannot forge the receipts (each containing user-signed portions, with request numbers and transaction numbers) and it cannot freeze receipts without freezing the advancement of the sequence number and thus also freezing all the wallets.<br />
# This sequence number could be included in the server-signed portion of the receipt. Beware that the server has the ability to sign a different version of the same receipt but with a different sequence number, since it would not appear in the user-signed portion of the receipt but rather, in the server-signed portion of the reply, but this is also incriminating for a malicious server since the server would have to sign both versions in order to do this, and if both copies were to ever surface, the crime would be obvious. (Versus individual receipts which are only clean or dirty based on whether the OVERALL TOTAL proves inflation, whereas in this case, if the two of those receipts were to appear at ''any time,'' they would be incriminating, regardless of the total of all the other receipts from some snapshot.) In the case of Bitcoin this would be a problem: which receipt of the two is the correct one? Do we have ''&quot;double spending&quot;?'' But on OT it doesn't matter: the server has failed the audit. Dump it and re-issue the last valid snapshot onto a new server. You cannot really have double-spending on OT, since all parties have signed all transactions. The worst you can have is inflation.<br />
# Chain the receipts: The '''hash of the previous receipt for the same currency''' could also be included in the server-signed portion of the receipt, along with the sequence number. The server could, as in note (8), create a separate, false version of the receipt, since that hash would only appear in the server-signed portion of the receipt, not the user-signed portion. But since changing a hash, changes the contents of the next receipt (since it contains a hash of the current one), then it would necessarily change the hash of ''that'' receipt as well, and thus change the contents of the receipt with the next higher sequence number, and thus change its hash, and so on all the way up through the entire sequence... the server would be forced to falsify the entire chain. The whole point is to force a single fraud, by design, to become a global fraud in detectability.<br />
# Also, reverse chain: Building on (8) and (9), each user can include the sequence number of his LAST successful transaction receipt--as well as its hash--in his '''next request.''' So that the USER-SIGNED portion of the next receipt, '''which is unforgeable,''' for each successful transaction contains the sequence ID and hash of the ''previous one.'' Again, the idea is to make it impossible to forge one receipt without having to forge all the others, and in this case, in places where forging is not even possible, since the user's private key is unknown, and the reverse chain is stored in the ''user-signed portion'' of the receipt.<br />
# Remember, this isn't some permanent chain, we only need these receipts for specific processes, and then we can discard them. (That's the whole idea of OT.) On the blockchain, you can sign to transfer funds to one address, and then you can falsely double-spend the same funds to another address, and ultimately one transfer is not any more &quot;right&quot; than the other (other than the one that counts: the one with the longest chain.) But in OT, all you have is your last signed receipt. You can sign to transfer funds, but the thing you are signing includes the new balance, and in fact will become your new &quot;last signed receipt.&quot; On OT you cannot double-spend, you can only inflate.<br />
# Ideally all the user wallets who care about a given currency, will participate in a DHT where the receipts can be posted temporarily for exchange. The receipts cannot be forged. Malicious nodes might be able to disrupt access or freeze, but they cannot falsify the audit. And ultimately any auditor can ask a server directly for the contents of receipts X, Y, Z... (the next expected sequential numbers) and if the receipts fail to be produced, then have all transactions stopped? This is why I say it's probably fine just for the servers to make the receipts available as a read-only filesystem, which the users and auditors have access to. But I still like the idea of some sort of DHT...<br />
<br />
(Not finished.)<br />
<br />
<br />
-----<br />
<br />
Thoughts on...<br />
<br />
THE AUDITING PROTOCOL (for BITCOIN VOTING POOL)<br />
<br />
'''Scenario:''' The ''Issuer'' is actually a '''Voting Pool''' of transaction servers, with '''Bitcoin''' stored in the pool (on the blockchain.)<br />
<br />
HOW VOTING POOLS WORK<br />
<br />
# Alice bails 100 BTC onto an OT server. But instead of sending the BTC to the server directly, she sends them to all the BTC addresses of the servers in the pool. (Such that only a blockchain-based vote of those same servers, X-out-of-Y, can get any coins out of the pool.)<br />
# Once the OT server sees Alice's bailment on the pool, she is issued BTC-units inside the server. From here, she can use them normally. For example, she can send a cheque to Bob.<br />
# At some later time, Bob decides to pull his BTC out of the server. He has 5 BTC in his account. He sends the bailout request to his own server, who countersigns it, and then both send a copy to the other members of the pool.<br />
# The other pool members, who audit the OT server, then verify the signatures on the receipt, and vote on the blockchain to authorize Bob's out-bailment. (Then Bob receives his coins at his personal BTC address.)<br />
<br />
''In one capacity, each pool member acts as a transaction server, in competition with the others--yet in another capacity, each acts as a BTC-unit issuer, based on his allotment of the common pool, which he is concerned to protect from the others--yet in another capacity, each is subject to third-party auditing from all the others.''<br />
<br />
INCENTIVE TO AUDIT<br />
<br />
All pool members have an incentive to audit the others (to prevent other pool members from inflating), since otherwise the inflaters would be enabled to bail-out real BTC from the pool--coins that they didn't actually own--and even get a vote in their favor to do it. (If they don't actually own the coins they are taking, that means those coins are actually coming out of YOUR portion instead -- which is why you, as another pool member, have an incentive to prevent it through auditing.)<br />
<br />
These pool members could collude. For example, 20-out-of-30 pool members could fraudulently vote on the blockchain to transfer themselves coins they don't really own, just as 51% of the mining power could be used to steal everyone's BTC on the blockchain itself. (Nothing's perfect.)<br />
<br />
Since they share a common interest in the integrity of the pool (the protection for each of his own assets), and since they are in the business of trust (membership in the pool providing a greater degree of trust and safety for the BTC-units issued by any pool member) then ''it could be foolish to approach their business competitors to propose collusion.'' If they could convince 20, it would be one thing, but anything less, and they are merely exposed as fraudsters by their own business competitors, who are acting in their own interests to protect their own assets.<br />
<br />
Assuming that the receipts are publicly available, the other pool members may not even have the option to &quot;allow&quot; inflation by one of their members, even if they had 20 colluders, since this information could be discovered by other entities such as one of their users. The pool members have an incentive to continue earning transaction fees, not only from the Bitcoins being traded in their pool, but from all the other currencies as well. There could be dozens of other currencies issued onto those transaction servers, currencies which the Bitcoins are presumably trading against.<br />
<br />
NOTE: the unique combination of properties that this scenario provides... The &quot;physical BTC&quot; is programmatically verifiable on the blockchain. (No need for a real-world physical audit.) No single pool member can steal the coins, or even get to his own coins, without an X-out-of-Y vote to get to them. No crime other than inflation is possible, and even that isn't possible without keeping the receipts hidden from all other entities. And instead of ''one'' issuer with an incentive to audit a given transaction server, you have ''30 issuers'' (the other pool members) with that same incentive to audit it. And the pool members are normally in business competition with each other--business competition where trust is the market, and any of them can benefit by catching a competitor lying.<br />
<br />
For pool members to vote falsely in favor of your fraudulent out-bailment, they would have to do so by raiding their own allotments of the pool--robbing themselves to pay a fraudster who receives the sole benefit. And they would do so with the full knowledge that absent collusion, if you vote wrong, you will be the ''only'' pool member who voted wrong, impotently--with 29 others going in the opposite direction. Unless their calculations for their own votes were wrong, they will want to know why you are lying in your vote.<br />
<br />
<br />
-----<br />
<br />
The other pool members COULD still collude, and vote themselves coins from the pool. Even if they cannot forge an OT receipt, they can still use X-out-of-Y on the blockchain to directly take coins from the pool. So you have, say, 20 pool members who vote the wrong way...<br />
<br />
...Just as the blockchain itself could &quot;vote&quot; 51% the wrong way.<br />
<br />
...Just as an issuer could collude, against his own interests, with a transaction server to turn a blind eye to inflation, sticking himself with the bill. (Assuming the receipts are not made publicly available.)<br />
<br />
'''The last, best protection for a user against those potentialities is to have a wallet that distributes his risk across multiple pools.''' The philosophy of Open-Transactions comes down to this: a user-centric distribution of risk. Federated servers, basket currencies, these tools are all used for the distribution of risk.<br />
<br />
One last thought: '''Hiding amounts homomorphically.''' It may be possible to use homomorphic cryptography to hide the amounts on the receipts (protecting the privacy of the users), while still publicly posting those receipts for audit. Another work-around here is to use cash-only instruments (this is like what Voucher-Safe does.) This way, even if the receipts are public, they are useful for auditing yet ''without'' revealing transaction amounts or account balances.<br />
<br />
<br />
-----<br />
<br />
IN SUMMARY<br />
<br />
<br />
-----<br />
<br />
'''Scenario:''' Issuer has gold in his warehouse, and he is also operating the transaction server.<br />
<br />
===&gt; In this scenario, you must be choosy about the issuer based on ''physical audits of the gold,'' and based on other governance issues such as insurance, jurisdiction, etc. The issuer cannot lie on your receipt, and he can only commit inflation if all receipts are kept hidden permanently thereafter (otherwise he can get caught, since he cannot inflate without also having to sign it, and the new funds are always detectable unless/until they are removed again from circulation.)<br />
<br />
<br />
-----<br />
<br />
'''Scenario:''' Issuer has gold in his warehouse, but a '''separate entity''' operates the transaction server.<br />
<br />
===&gt; In this scenario, the transaction server may have 50 other issuers using his server, and the issuer likewise may have issued his currency onto other transaction servers.<br />
<br />
===&gt; The transaction server may have a perverse incentive to inflate a currency, but this would be permanently detectable, and would thus require the secrecy of all receipts, and would require collusion from the issuer to &quot;turn a blind eye&quot; to his own audits.<br />
<br />
===&gt; The issuer does ''not'' have an incentive to collude, ''and'' the issuer ''does'' have an incentive to audit the transaction server.<br />
<br />
<br />
-----<br />
<br />
'''A. Do the issuer and transaction server actually have the incentive to collude?'''<br />
<br />
===&gt; I argue no. This appears purely as a wealth transfer from Issuer Ivan to Server Sarah, with great potential costs to both.<br />
<br />
===&gt; Basically: If Issuer Ivan issues 100,000 grams onto Server Sarah, then he is the one who owes the 100,000 grams and must be able to produce the physical gold. If Sarah inflates an additional 50,000 grams, then ''she is the one who benefits, while Ivan is the one who pays.'' And even if she splits it with him, he is still the one stuck with the total bill, while she gets to spend half, and he will be on the hook for that, too.<br />
<br />
===&gt; So in effect ''it's nothing more than a wealth transfer from Ivan to Sarah for no reason,'' and at great risk to both of them, in terms of future transaction and storage fees--from other currencies as well, and not just the one in question.<br />
<br />
<br />
-----<br />
<br />
'''B. Do the issuer and transaction server have the ABILITY to collude?''' (regardless of incentive.)<br />
<br />
===&gt; They cannot collude to do ''&quot;anything they want,&quot;'' but they ''can'' collude to INFLATE.<br />
<br />
===&gt; But even this is only possible if they keep the receipts secret, and if there are no other entities with the ability or incentive to perform a spot audit. Inflation is permanently detectable, since the funds would have to be taken back out of circulation in order to hide the crime from any future audit.<br />
<br />
===&gt; Any other attempted crimes (outside of inflation) are not possible and would only result in failing an audit or freezing all the user wallets. Receipts cannot be forged, even with collusion.<br />
<br />
<br />
-----<br />
<br />
'''Scenario:''' Issuer has '''Bitcoin''' in his cold wallet, and he is ''also'' operating the transaction server.<br />
<br />
===&gt; This scenario has the benefits that the reserves are publicly auditable (on the blockchain) and that the issuer cannot lie on your receipt.<br />
<br />
===&gt; But it still requires you to trust the server operator with your Bitcoins, which is &quot;buyer beware&quot; and which I believe will cease to exist once voting pools are available.<br />
<br />
<br />
-----<br />
<br />
'''Scenario:''' Issuer has Bitcoin in his cold wallet, but a '''separate entity''' operates the transaction server.<br />
<br />
===&gt; This scenario will likely never actually happen! The reason is because the issuer adds no value in the case of Bitcoin storage, since a user can just store it directly on the blockchain without any fee, so there is no reason to pay an issuer a storage fee.<br />
<br />
===&gt; In contrast, the storage and guarding of physical gold is a real value-add, which must be paid for.<br />
<br />
Therefore BTC-based currencies will only ever be issued either through an issuer who operates his own transaction server, or through a voting pool, in my opinion. (The voting pool being the long-term winner.) We will not see successful scenarios where a trusted BTC issuer has issued his currency onto a transaction server operated by some separate entity. At first, some BTC issuers will be successful by operating their own transaction server, but then these will be overtaken by voting pools in the long-term, for obvious reasons.<br />
<br />
<br />
-----<br />
<br />
Thoughts on THE AUDITING PROTOCOL (for GOLD issuers)<br />
<br />
===&gt; We can make it impossible to escape an audit, easy to get caught in violation of one, and extremely difficult to try.<br />
<br />
===&gt; The only possible crime is inflation, and even that is not possible if there are other entities with the incentive to audit the receipts. Inflation is permanently detectable and all receipts would have to be kept secret to prevent an outside audit. (Note that users all have their own receipts, so that sort of secrecy is impossible.)<br />
<br />
===&gt; All that is necessary is to have a place where users can retrieve their receipts, even if only a network-attached, read-only folder hosted by the server itself. (If a DHT were used, that would be cool, too.) Malicious DHT nodes or fileservers could disrupt services, but could not falsify results, and disrupted services could be simply moved.<br />
<br />
===&gt; UPON FURTHER THOUGHT AND REFLECTION, the &quot;network-attached&quot; folder itself may not even be necessary! Currently, users just receive their receipts directly from the transaction server, in reply to their requests. We could just maintain that system. Then on top of that, allow any &quot;interested parties&quot; to subscribe to real-time broadcasts of the same receipts (in sequential order.) This will require more thought...<br />
<br />
<br />
-----<br />
<br />
THE AUDITING PROTOCOL (for BITCOIN VOTING POOL)<br />
<br />
'''Scenario:''' The ''Issuer'' is actually a '''Voting Pool''' of transaction servers, with '''Bitcoin''' stored in the pool (on the blockchain.)<br />
<br />
===&gt; Just as a transaction server cannot commit inflation without collusion from the ''issuer'' for that currency (who has no incentive to do so, and who in fact would get stuck with the bill, and has an opposite incentive to audit the transaction server), much in the same way, a pool member cannot commit inflation without the collusion of the ''other pool members,'' who would stand to lose their own Bitcoins as a result. '''One auditor gets turned into thirty auditors.'''<br />
<br />
===&gt; Amiller's requirement that the server be subject to audits from third-parties--with incentive--is met by the other pool members. The transaction server would be subject to audits from all of the pool members, each doing so to protect their own BTC and each in competition with the others.<br />
<br />
===&gt; It's true that a majority of the servers in the pool could still collude--that if they were able to get enough voters together, they could steal your BTC directly off of the blockchain. (Even then, they could not falsify your OT receipt!)<br />
<br />
===&gt; But so what? '''It's also possible for a 51% attack''' to steal your coins...but there are also other incentives, other forces, working in the opposite direction, such that the blockchain still provides pretty good security. And I would say that it's actually the same forces that are at play with the voting pool--perhaps not as secure as the blockchain itself but still considerably more secure than trusting a single server operator with your coins -- '''which means it is what people will ''use'' instead of trusting a single server with their coins.'''<br />
<br />
<br />
-----<br />
<br />
THE LAST SHIELD: Distribution of Risk.<br />
<br />
===&gt; Ultimately the last line of defense is a wallet that, from a user-centric perspective, distributes risk across multiple pools, multiple asset types, multiple transaction servers, etc. There is never a complete elimination of risk, in any system or blockchain. There are only strategies for managing it and reducing its impact. Ultimately a smart wallet must provide this for its user.<br />
<br />
===&gt; All of the various strategies above are different angles of that same philosophy--different problems being attacked in their own specific domains from the perspective of reduction and distribution of risk. With OT we are &quot;going meta&quot; because we are using any-and-all of them wherever we can gain any benefit, ''from a user-centric perspective.''<br />
<br />
<br />
-----<br />
<br />
PROTOCOL EXAMPLE DETAILS<br />
<br />
# All users directly receive their receipt in each server reply. This receipt has a sequence number on the server-signed portion, for that currency. All wallets normally verify this receipt against the account balance (an intermediary file) before performing any transaction. This is because each receipt must contain a signed balance agreement.<br />
# The account balances for any given currency are stored in the accounts folder. The receipts for a given currency will be stored sequentially in a folder and automatically erased after 30 days. The receipts could be stored '''in the clear,''' or they could be stored '''in the clear but with homomorphically blinded amounts,''' or they could be stored '''encrypted in an RSA envelope to multiple keys''' (the USER and AUDITOR keys for example.)<br />
# The same receipts could also be broadcasted in real time via ZMQ to any subscribers. (E.g. auditors.)<br />
# The same receipts could also be queried at any time from the server (within the 30 day period) based on the currency ID combined with the sequence number. (We should also allow this query based on the hashed receipt ID.)<br />
# (Optional) Just to be really overzealous, the user wallets could be coded to automatically randomly send one receipt out of every hundred, or out of every thousand, directly to the issuer, to a location described in the currency contract. Why? Because if the transaction server cannot hide funds flowing from dummy accounts into normal accounts, then he might try to just hide normal accounts. This would be quite a juggling act for him, but it becomes impossible with this step in place since he cannot prevent all the thousands of user wallets from randomly occasionally directly showing the auditor their receipt (with the server's signature on it)--which proves the existence of their account, and gives the auditor examples to verify.<br />
# An auditor starts by loading up all of the receipts for a given currency, at a given snapshot in time. There should be only one account with a below-negative balance, and all the others should have a 0 or higher balance. If you add all of the balances together, they should equal zero. All of them should contain user-signed requests enclosed in server-signed responses. All of them should verify (for example a balance agreement inside a receipt should not contain inbox records that change the account balance based on a specific transaction number, unless that transaction number is also shown as signed-out to that user, on the same receipt.) We probably have the ability here to verify a lot deeper than we will need.<br />
# From here, if the auditor is subscribed to the ZMQ broadcast, then he will see each next receipt in sequence order, and process them in order thereafter, in real-time. For example, if receipt #455 is the latest one in the snapshot, he will want to process #456 next, and then #457, etc. Each should move funds from one account to another, and thus result in a 0 balance overall. And each receipt should involve only accounts which actually appear in the accounts folder, according to the snapshot. (i.e. the auditor is specifically looking to catch receipts which do not have a corresponding account balance file in the account folder.)<br />
# If a dummy account sends inflated funds to a real account, the real account will have to sign to accept them, and his receipt will show up on the audit. The auditor will see (from that receipt) that the real account is signing to accept funds from an account that apparently doesn't exist. (At this point the transaction server has failed the audit.)<br />
# In addition to listening to the broadcast, the auditor can also compare notes with other subscribers, as well as compare notes against random receipts sent to him by users (optional.) He can also randomly create accounts and send &quot;ping&quot; transactions through, to see the sequence number incrementing and to compare it against the sequence number that appears in the receipt folder, and that is retrieved via server query. The result of the query can be hashed to see if the receipt hash matches the expected one for that sequence number. The auditor can also query the previous receipt in the sequence, AND the previous receipt for THAT USER, and compare the sequence numbers and hashes to make sure none of them have been changed. For example, if a user randomly sends receipt #367 to the auditor, and it has a certain hash, then the auditor can expect that when he saw that same receipt, or when he queries the server for a copy of it, that it will have the same hash. (Again, we can probably verify deeper here than we will actually end up having to.)<br />
# Remember, one falsification is permanently detectable, and it only takes one for the transaction server to be dumped. As long as the balance always equals zero, and the accounts are all known from the snapshot, and the balance agreements verify with the user's signature, then inflation cannot happen. (Amiller asks: what are the consequences if inflation is discovered? More on this below...)<br />
# Let's assume the transaction server is hosting the receipt folder. Thus, the auditor can't be guaranteed to be able to put a signed warning in that folder, because the (potentially malicious) transaction server is the one hosting it, and he might just block it, or erase it, so the users never see the warning.<br />
# But if the auditor is expected to put a ''signed &quot;A-Okay&quot;'' into a sibling folder on a ''regular basis,'' then it is automatically suspicious if that receipt fails to materialize. The schedule can be described in the currency contract, and the user wallets can verify their own receipts for themselves, based on that schedule.<br />
# It's also automatically suspicious if you straight-out ask the server for the latest signed audit receipt, yet he is unable to produce one according to the terms expecting from the currency contract. It would be easy to have a an OT wallet that regularly and automatically verifies its own receipts' audit status, according to the terms described in the currency contract, by simply asking the transaction server to produce the auditor's signed copy. In fact, the auditor's &quot;last signed A-Okay&quot; could be automatically attached to all server replies. That way it's immediately obvious to any wallet if something's fishy, even before any transaction is performed.<br />
# On one hand, the currency contract might describe a real-time audit, with a user wallet expecting to be able to verify its own receipts' audit status in near real-time.<br />
# On the other hand, the currency contract could instead describe, say, a ''daily audit,'' and/or a day or two delay on out-bailments, with mandatory daily limits on how many units the issuer will redeem to any one user. This way no one can ever GET AWAY with inflation, before the time of the next audit.<br />
<br />
CONSEQUENCES<br />
<br />
Amiller asks: what are the consequences when the audit fails? Is the transaction server arrested? Is he forced to make a public apology?<br />
<br />
# In the case of a BTC voting pool, each transaction server is audited by each pool member. If the transaction server fails an audit (and thus every audit thereafter), that pool member will thus vote against any bailments out of the pool for that transaction server. So the first consequence is '''loss of access to the coins in the pool.'''<br />
# Secondly, if the auditors have not posted their notice (which the potentially malicious transaction server can be responsible to host and provide upon demand) according to the schedule expected from the currency contract, then the user wallets can be programmed to distrust the transaction server and notify the issuer when this happens, and request their '''funds be re-issued onto a different transaction server.'''<br />
# In the case of a voting pool, a vote can be held by the other pool members (they are the &quot;issuer&quot; in that case), in order to recover the coins from the malicious server's pool allotment and into the pool allotment of a valid transaction server, so the related units can be re-issued back to the user.<br />
# Thus another consequence to the transaction server is the near-immediate '''loss of all users of that currency,''' and '''loss of all future revenues from transaction fees''' denominated in that currency, and potentially (likely) loss of ''all'' future revenues from ''all other currencies.''<br />
# As long as the audit is in real-time, or as long as the out-bailments are limited and the audits are nightly, then the transaction server cannot get away with anything, he can only get caught and then lose all future revenues.<br />
<br />
SIDE EFFECTS<br />
<br />
Receipts having to be public means others can see them. Which means we need to delve deeper into homomorphic crypto.<br />
<br />
But then again with a voting pool, it might only be necessary that receipts are auditable by the pool members, since the BTC stored in the pool are already publicly auditable via the blockchain itself.<br />
<br />
<br />
-----</div>Cryptomanhttp://opentransactions.org/wiki/index.php?title=About&diff=106About2013-06-12T13:33:19Z<p>Cryptoman: </p>
<hr />
<div>'''What is OPEN-TRANSACTIONS?'''<br />
<br />
* Open-Transactions is an [[Use Cases|easy-to-use]], financial crypto, [[Sample Cash|digital cash]] and transaction [[List of Classes|library]].<br />
* Open-Transactions includes a '''[[API|client API]]''', a working '''[[OT-Server|server]]''', a '''[[TestGUI|GUI test wallet]]''' (in Java) and a [[opentxs|command-line]] wallet utility.<br />
* Open-Transactions features: a large variety of financial instruments, markets, basket currencies, unforgeable account balances, '''untraceable digital cash,''' destruction of account history, [http://iang.org/papers/ricardian_contract.html Ricardian contracts], Smart Contracts (scriptable clauses), and more.<br />
<br />
'''WHAT DOES IT DO?'''<br />
<br />
* '''Open-Transactions allows users to issue and manipulate digital assets.'''<br />
* Any issuer can sign and distribute new [[Sample Currency Contract|currency contracts]] in order to create new digital asset types.<br />
* Users may create many ''pseudonyms'' (public keys), each of which may own ''asset accounts'' of various types, on OT servers.<br />
* Users can operate '''&quot;cash-only&quot;''' ''(without accounts)'' for maximum anonymity, using '''[[Sample Cash|untraceable digital cash]]'''.<br />
<br />
-----<br />
<br />
'''NEW: GUI Mock-Ups! (first draft)'''<br />
<br />
[https://www.fluidui.com/editor/live/preview/p_8ZN0r9Pbp2XzPC7yL3lDFw5lW2L7vEye.1343824445082 standard mode]<br />
<br />
[https://www.fluidui.com/editor/live/preview/p_XcN9TmQ5FItuPr5QctxES2XfAhinsVPp.1343659566990 advanced mode]<br />
<br />
[http://www.reddit.com/r/Agorism/comments/19p6oa/how_to_issue_your_own_currency_using/ Install via apt-get (click here)]<br />
<br />
-----<br />
<br />
'''Radio Interview'''<br />
<br />
[http://agoristradio.com/?p=234 Part 1, courtesy of AgoristRadio]<br />
<br />
[http://agoristradio.com/?p=246 Part 2, courtesy of AgoristRadio]<br />
<br />
Bitcoin donation address: 1NtTPVVjDsUfDWybS4BwvHpG2pdS9RnYyQ<br />
<br />
IRC: #opentransactions at irc.freenode.net<br />
<br />
-----<br />
<br />
'''Video Walkthru''' <br />
<br />
[http://vimeo.com/28141679 Video 1 posted by J. Orlin Grabbe]<br />
<br />
[http://vimeo.com/28142096 Video 2 posted by J. Orlin Grabbe]<br />
<br />
[http://open-transactions.github.io/tv/ New videos!]<br />
<br />
-----<br />
<br />
'''FINANCIAL INSTRUMENTS'''<br />
<br />
* Users can transfer digital assets ''securely and provably'', with [[Triple-Signed Receipts|receipts]] signed by all parties.<br />
* '''Even an OT server cannot change balances, or forge transactions--since it cannot forge your signature on your receipt.'''<br />
* Open-Transactions supports a range of '''[[Instruments|financial instruments]]''' such as account transfer, '''[[Sample-Cheque|cheques]]''' and vouchers (aka &quot;cashier's cheques&quot; or &quot;banker's cheques&quot;), in addition to cash.<br />
* 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.<br />
<br />
-----<br />
<br />
'''Diagrams:'''<br />
<br />
[http://billstclair.com/ot/ot-diagram.jpg Architecture Overview]<br />
<br />
[http://billstclair.com/ot/OT-Anon-CashOnly.jpg Fully-Anonymous (cash only)]<br />
<br />
[http://billstclair.com/ot/OT-Pseudonym-Instruments.jpg Pseudo-Anonymous (using accounts)]<br />
<br />
-----<br />
<br />
'''MARKETS, BASKET CURRENCIES, and SMART CONTRACTS'''<br />
<br />
* Open-Transactions also implements higher-level, '''contract-based transactions''' such as '''payment plans''' and '''markets with trades'''.<br />
* 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.<br />
* '''Basket currencies''' are also supported, as well as payment plans (recurring payments.)<br />
* [[Smart contracts]]: Multi-party agreements with scriptable clauses... including hooks, callbacks, internal state, etc.<br />
* [[Client-side scripting]]: <code>!/usr/bin/env ot</code> The entire (mostly) high and low level OT API is available within your scripts.<br />
<br />
-----<br />
<br />
'''TRIPLE SIGNED RECEIPTS'''<br />
<br />
* 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'''.<br />
* Without the special mechanism that makes this possible, ''all parties would otherwise be forced to store all receipts forever''.<br />
* Nyms and Asset Types have consistent IDs across all OT servers, since the ID is formed by hashing the relevant contract or public key.<br />
<br />
-----<br />
<br />
The real beauty of Open-Transactions is the as-yet-unwritten future of ''new ideas'' that you can build with it, and the future liberty and security of your children that you can help to protect by doing so--in a very real and tangible way.<br />
<br />
-----<br />
<br />
'''IS Open-Transactions [[CENTRALIZED]]?'''<br />
<br />
'''The vision is not of a central server that you must trust.''' '''Rather, the vision is of federated servers you don't have to trust.'''<br />
<br />
-----<br />
<br />
'''Mailing list''': open-transactions-subscribe@rayservers.com<br />
<br />
'''[[FAQ]]'''<br />
<br />
'''[[Components and GNU Licensing|Components]]'''<br />
<br />
'''[[Installation|Install Notes]]'''<br />
<br />
'''[[Use Cases]]'''<br />
<br />
'''[[API]]'''<br />
<br />
'''[[Business Cases]]'''<br />
<br />
'''[[Release Notes]]'''<br />
<br />
-----<br />
<br />
The server itself is a [[Transactions|transaction processor]] in the cypherpunk tradition. In more detail:<br />
<br />
* Many '''financial instruments''' are supported: Users can write '''cheques''', purchase '''cashier's cheques''' (&quot;vouchers&quot;), and withdraw in '''[[Sample Cash|untraceable digital cash]]'''. The software uses Chaumian-style, blinded tokens courtesy of the [http://anoncvs.aldigital.co.uk/lucre/ Lucre] library by Ben Laurie.<br />
* 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.<br />
* 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''.<br />
* '''Any user can issue new digital currencies''' and digital asset types, by uploading the new [currency contract] to the server. (This functionality is comparable to [http://www.systemics.com/docs/sox/overview.html Ricardo] by [http://financialcryptography.com/ Ian Grigg].)<br />
* '''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 Chkeroff.)<br />
* [[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].)<br />
* 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'''.<br />
* 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'''.)<br />
* [[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].<br />
* [[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><br />
* 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.)<br />
* '''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.<br />
* 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.<br />
* 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.<br />
* '''All communications are secured with OpenSSL.''' All messages are also signed and encrypted. All transactions require signatures from relevant parties including the server.<br />
* 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.)<br />
* The software is fully '''cross-platform''': '''Linux, Mac OS X, FreeBSD, Android, and Windows''' are supported with makefiles, project files, and instructions.<br />
* 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.'''<br />
* [[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.<br />
* OT currently supports '''MsgPack''' and '''protobuf''' for data packing, though new packers can be added by subclassing OTDB::Packer.<br />
<br />
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>Cryptomanhttp://opentransactions.org/wiki/index.php?title=API&diff=105API2013-06-12T13:21:53Z<p>Cryptoman: </p>
<hr />
<div>THE LATEST SCOOP<br />
<br />
* OT now has a high-level API for all languages! (Via SWIG.) 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].<br />
<br />
* OT's high-level API is also available in OT [https://github.com/FellowTraveler/Open-Transactions/wiki/Client-side-scripting client-side scripts]<br />
<br />
* 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.'''<br />
<br />
* 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/Moneychanger otapiJ].<br />
<br />
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.<br />
<br />
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.)<br />
<br />
------------------------------------------<br />
<br />
'''USE CASES for the OT API, described on this page:'''<br />
<br />
* '''(Client software starts up.)''' Initialize the library and load the wallet.<br />
* Display for user: '''Server Contracts, Nyms, Accounts, and Asset Types.'''<br />
* Change the wallet's ''display label'' for any server, asset type, account, or nym.<br />
* Import a server contract (or asset contract) to the wallet.<br />
* Create a new '''Pseudonym''' (public/private key pair).<br />
* Register a public key (a ''"Nym"'') at an OT server.<br />
* '''Issue a new digital Asset Type'''. (Uploading an asset contract.)<br />
* Retrieve Currency Contract (by ID).<br />
* '''Create a new Asset Account'''.<br />
* '''Write a cheque''' (or invoice)<br />
* '''Send a Message''' to another user (via the server, encrypted to the recipient's public key.)<br />
* '''Deposit a cheque'''<br />
* '''Withdraw cash''' . . . . <==== UNTRACEABLE DIGITAL CASH!!<br />
* '''Deposit cash'''<br />
* Withdraw Voucher<br />
* '''Account-to-Account Transfer'''<br />
* Create a new '''Basket Currency'''<br />
* '''Exchange''' Digital Assets '''in and out of Baskets''' (from your Asset Accounts)<br />
* '''Process your Inbox''' (Receipts and pending transfers)<br />
* Set up a '''Payment Plan'''<br />
* Issue a '''Market Offer'''<br />
<br />
<br />
-------<br />
<br />
'''USE CASES for the OT API'''<br />
<br />
'''Initialize the library and Load your Wallet'''<br />
<br />
(The user starts up the wallet software.)<br />
<br />
Call '''OT_API_Init()'''<br />
<br />
Then call '''OT_API_LoadWallet()'''<br />
<br />
<br />
(NOTE: these above 2 steps are not necessary in OT-script, only Java and other languages.)<br />
<br />
'''Display the current list of server contracts on the screen'''<br />
<br />
Call '''OT_API_GetServerCount()''', which returns the number of server contracts in your wallet.<br />
<br />
For each one, call '''OT_API_GetServer_ID()''' to get the Server ID (which is a hash of the contract.)<br />
<br />
Also for each, call '''OT_API_GetServer_Name()''' to get the Display Name from the contract.<br />
<br />
In your GUI, display the name on the screen, but use the ID behind the scenes (for your messages to the server.)<br />
<br />
'''Do the same thing for Nyms, Accounts, and Asset Types.'''<br />
<br />
You can read about them on the [[API]] page, but here are the basic functions:<br />
<br />
OT_API_GetNymCount(void);<br />
<br />
OT_API_GetServerCount(void);<br />
<br />
OT_API_GetAssetTypeCount(void);<br />
<br />
OT_API_GetAccountCount(void);<br />
<br />
OT_API_GetNym_ID() and OT_API_GetNym_Name()<br />
<br />
OT_API_GetServer_ID() and OT_API_GetServer_Name()<br />
<br />
OT_API_GetAssetType_ID() and OT_API_GetAssetType_Name()<br />
<br />
OT_API_GetAccountWallet_ID() and OT_API_GetAccountWallet_Name()<br />
<br />
Also: <br />
<br />
OT_API_GetAccountWallet_Balance()<br />
<br />
OT_API_GetAccountWallet_Type()<br />
<br />
OT_API_GetAccountWallet_AssetTypeID()<br />
<br />
<br />
'''Add a new server contract (or asset contract) to the wallet'''<br />
<br />
Call '''OT_API_AddServerContract()''' <br />
<br />
or '''OT_API_AddAssetContract()'''.<br />
<br />
<br />
'''Create a new Pseudonym'''<br />
<br />
(Each user's wallet may contain many pseudonyms. Each Nym consists of a public and a private key, aka a "key pair".)<br />
<br />
Call '''OT_API_CreateNym()'''<br />
<br />
This creates a new key pair _("Nym")_ in your wallet, which you can use for communications with an OT server.<br />
<br />
(That is, for opening asset accounts and performing various other transactions. A Nym is a "user account".)<br />
<br />
(You can create as many of these pseudonyms as you want.)<br />
<br />
(You can register the same nyms at multiple servers.)<br />
<br />
(The same Nym will have the same Nym ID and public key on every server.)<br />
<br />
Example <br />
<br />
<pre><br />
def details_create_nym(nKeybits, strName)<br />
{<br />
var madeEasy = OT_ME() <br />
var strNymID = madeEasy.create_pseudonym(nKeybits, "", "") // returns new Nym ID<br />
<br />
if (!VerifyStringVal(strNymID))<br />
{<br />
OT_API_Output(0, "details_create_nym: Failed in OT_ME::create_pseudonym(keybits == " + nKeybits.to_string() + ")\n")<br />
return (0)<br />
}<br />
OT_API_Output(0, "Success creating! " + nKeybits.to_string() + " keybits, new ID: ") // stderr<br />
print(strNymID) // stdout<br />
OT_API_Output(0, "\n") //stderr<br />
// -------------------<br />
var bSetName = OT_API_SetNym_Name(strNymID, // subject<br />
strNymID, // signer<br />
strName)<br />
if (!bSetName)<br />
{<br />
OT_API_Output(0, "Failed in OT_API_SetNym_Name(name == " + strName + ")\n")<br />
return (0)<br />
}<br />
// ------------------- <br />
OT_API_Output(0, "Success setting name to: " + strName + "\n\n") // stderr<br />
return 1<br />
}<br />
</pre><br />
<br />
'''Register a public key (aka "Nym") at an OT server'''<br />
<br />
<pre><br />
var madeEasy = OT_ME()<br />
if (VerifyExists("Server") && VerifyExists("MyNym"))<br />
{ <br />
var strResponse = madeEasy.register_nym(Server, MyNym)<br />
var nSuccess = VerifyMessageSuccess(strResponse)<br />
switch(nSuccess)<br />
{<br />
case (1)<br />
{<br />
OT_API_Output(0, "\n\n SUCCESS in register_nym! Server response:\n\n");<br />
print(strResponse) // stdout<br />
break<br />
}<br />
default<br />
{<br />
OT_API_Output(0, "\n\n Failure or Error in register_nym!\n")<br />
<br />
if (VerifyStringVal(strResponse))<br />
{<br />
OT_API_Output(0, "Server response:\n\n");<br />
print(strResponse) // stdout<br />
}<br />
break<br />
}<br />
}<br />
</pre><br />
<br />
'''Change the wallet's label for any server/asset type/account/nym'''<br />
<br />
(This is only a client-side label, for display purposes only.)<br />
<br />
'''OT_API_SetNym_Name()'''<br />
<br />
'''OT_API_SetAccountWallet_Name()'''<br />
<br />
'''OT_API_SetAssetType_Name()'''<br />
<br />
'''OT_API_SetServer_Name()'''<br />
<br />
----------------------------<br />
<br />
'''Issue a new digital Asset Type'''<br />
<br />
User uploads a new currency contract to the server, so users can create asset accounts based on that asset type.<br />
<br />
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.)<br />
<br />
High-level API version (in OT script):<br />
<br />
<pre><br />
var madeEasy = OT_ME()<br />
OT_API_Output(0, "Please paste a currency contract, followed by an EOF or a ~ by itself on a blank line:\n\n")<br />
var strContract = OT_CLI_ReadUntilEOF() <br />
var strResponse = madeEasy.issue_asset_type(Server, MyNym, strContract)<br />
var nStatus = VerifyMessageSuccess(strResponse)<br />
<br />
switch(nStatus)<br />
{<br />
case (1)<br />
{<br />
OT_API_Output(0, "\n\n SUCCESS in issue_asset! Server response:\n\n");<br />
print(strResponse) // stdout<br />
break<br />
}<br />
default<br />
{<br />
OT_API_Output(0, "\n\n Failure or error in issue_asset. nStatus: "+nStatus.to_string()+"\n")<br />
if (VerifyStringVal(strResponse))<br />
{<br />
OT_API_Output(0, "Server response:\n\n");<br />
print(strResponse) // stdout<br />
}<br />
break<br />
}<br />
}<br />
</pre><br />
<br />
'''Retrieve Currency Contract (by ID)'''<br />
<br />
User wants to download a currency contract from the server (for a given asset type ID.)<br />
<br />
(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.)<br />
<br />
High-level API version (in OT script):<br />
<br />
<pre><br />
var madeEasy = OT_ME()<br />
var strRetrieved = madeEasy.retrieve_contract(Server, MyNym, strContractID)<br />
var nRetrieved = VerifyMessageSuccess(strRetrieved) <br />
var strSuccess = "ERROR"<br />
if (1 == nRetrieved)<br />
{ strSuccess = "SUCCESS" }<br />
else if (0 == nRetrieved)<br />
{ strSuccess = "FAILED" }<br />
OT_API_Output(0, "\n\n " + strSuccess + " retrieving contract: "+strContractID+"\n\n")<br />
</pre><br />
<br />
'''Create a new Asset Account'''<br />
<br />
Example in OT Script, from the "sample scripts":https://github.com/FellowTraveler/Open-Transactions/tree/master/scripts/samples folder:<br />
<br />
<pre><br />
def OT_ME::create_asset_acct(SERVER_ID, NYM_ID, ASSET_TYPE_ID) <br />
{<br />
var ot_Msg := OTAPI_Func()<br />
// -------------------------<br />
var theRequest := OTAPI_Func(ot_Msg.CREATE_ASSET_ACCT, SERVER_ID, NYM_ID, ASSET_TYPE_ID)<br />
var strResponse = theRequest.SendRequest(theRequest, "CREATE_ASSET_ACCT")<br />
<br />
return strResponse<br />
}<br />
</pre><br />
<br />
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.<br />
<br />
(You can also use the "decode" command in the test wallet anytime you want to base64-decode something.)<br />
<br />
--------------------------<br />
<br />
'''TRANSACTIONS'''<br />
<br />
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.)<br />
<br />
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.<br />
<br />
'''You might ask: ''"But what if I download my account, or my outbox, and the server has maliciously inserted data into them?"'' '''<br />
''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()'''. <br />
<br />
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!'''<br />
<br />
------------------<br />
<br />
'''Write a Cheque'''<br />
<br />
Alice writes a cheque (offline): Call '''OT_API_WriteCheque()'''<br />
<br />
Alice then gives cheque to Bob (offline), _or_ online if she prefers via '''OT_API_sendUserMessage()''' function.<br />
<br />
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.<br />
<br />
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.) <br />
<br />
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!) <br />
<br />
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.<br />
<br />
'''Deposit a cheque'''<br />
<br />
(A voucher is also a cheque, so you may deposit a voucher here the same as any other cheque.)<br />
<br />
Bob sends message to server requesting deposit: <br />
<br />
'''(High level API version, in Java.)'''<br />
<br />
<pre><br />
public boolean depositCheque(String serverID, String nymID, String accountID, String cheque) {<br />
<br />
System.out.println("In depositCheque serverID:" + serverID + " nymID:" + nymID + " acount ID:" + accountID);<br />
<br />
// ---------------------------------------------------<br />
OTAPI_Func theRequest = new OTAPI_Func(OTAPI_Func.FT.DEPOSIT_CHEQUE, serverID, nymID, accountID, cheque);<br />
String strResponse = OTAPI_Func.SendTransaction(theRequest, "DEPOSIT_CHEQUE"); // <========================<br />
<br />
if (null == strResponse) {<br />
System.out.println("OTAPI_Func.SendTransaction() failed, in depositCheque.");<br />
return false;<br />
}<br />
// -------------------------------------------------------------------------------------- <br />
<br />
return true;<br />
}<br />
</pre><br />
<br />
'''Withdraw cash'''<br />
<br />
Alice's wallet first makes sure she has the latest public mint file, by calling '''OT_API_getMint()'''.<br />
<br />
(Note: if the mint she already has is within its valid date range, there's no need to do this.)<br />
<br />
(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.)<br />
<br />
Alice then withdraws from her asset account, by messaging server: '''OT_API_notarizeWithdrawal()'''<br />
<br />
Server replies with untraceable cash, which is stored in the purse folder in local storage.<br />
<br />
Here is the full Java implementation of Withdraw Cash:<br />
<br />
<pre><br />
public boolean withdrawCash(String serverID, String nymID, String accountID, String amount) <br />
{<br />
String serverResponseMessage = null;<br />
System.out.println("In withdrawCash serverID:" + serverID + " nymID:" + nymID + " acount ID:" + accountID);<br />
String assetID = otapi.OT_API_GetAccountWallet_AssetTypeID(accountID);<br />
<br />
// ---------------------------------------- <br />
// Make sure we have the proper asset contract for the withdrawal.<br />
//<br />
String assetContract = otapi.OT_API_LoadAssetContract(assetID);<br />
if (assetContract == null) {<br />
OTAPI_Func theRequest = new OTAPI_Func(OTAPI_Func.FT.GET_CONTRACT, serverID, nymID, assetID);<br />
String strResponse = OTAPI_Func.SendRequest(theRequest, "GET_CONTRACT");<br />
<br />
if (null == strResponse) {<br />
System.out.println("IN withdrawCash: OTAPI_Func.SendRequest(GET_CONTRACT) failed. (I give up.) (Unable to find asset contract.)");<br />
return false;<br />
}<br />
// ----------------------------------------<br />
assetContract = otapi.OT_API_LoadAssetContract(assetID);<br />
if (assetContract == null) {<br />
System.out.println("OT_API_LoadAssetContract returned null even after OT_API_getContract (Unable to find asset contract.)");<br />
return false;<br />
}<br />
}<br />
// ---------------------------------------------------------<br />
// Download the public mintfile if it's not there, or if it's expired.<br />
// Also load it up into memory as a string (just to make sure it works.)<br />
// Then we can actually send the withdrawal transaction request. (Until<br />
// then, why bother?)<br />
//<br />
String mintFile;<br />
<br />
// expired or missing.<br />
if (1 != otapi.OT_API_Mint_IsStillGood(serverID, assetID)) <br />
{<br />
// ----------------------------------------<br />
OTAPI_Func theRequest = new OTAPI_Func(OTAPI_Func.FT.GET_MINT, serverID, nymID, assetID);<br />
String strResponse = OTAPI_Func.SendRequest(theRequest, "GET_MINT");<br />
<br />
if (null == strResponse) {<br />
System.out.println("IN withdrawCash: OTAPI_Func.SendRequest(GET_MINT) failed. (I give up.) (Unable to get mint.)");<br />
return false;<br />
}<br />
// ----------------------------------------<br />
mintFile = otapi.OT_API_LoadMint(serverID, assetID);<br />
if (mintFile == null) {<br />
System.out.println("OT_API_LoadMint returned null even after OT_API_getMint (I give up.) (Unable to find mint.)");<br />
return false;<br />
}<br />
}<br />
else // current mint IS available already on local storage (and not expired.)<br />
{<br />
mintFile = otapi.OT_API_LoadMint(serverID, assetID);<br />
if (mintFile == null) {<br />
System.out.println("OT_API_LoadMint returned null even after successful OT_API_Mint_IsStillGood (I give up.) (Unable to find mint.)");<br />
return false;<br />
}<br />
} <br />
// ---------------------------------------------------<br />
// By this point, the mintfile is DEFINITELY good (available, not null, <br />
// not expired, and loaded up.) Now we know for a fact that when the API<br />
// call is made to withdraw cash, that it will find the mint properly.<br />
//<br />
OTAPI_Func theRequest = new OTAPI_Func(OTAPI_Func.FT.WITHDRAW_CASH, serverID, nymID, accountID, amount);<br />
String strResponse = OTAPI_Func.SendTransaction(theRequest, "WITHDRAW_CASH"); // <========================<br />
<br />
if (null == strResponse) {<br />
System.out.println("OTAPI_Func.SendTransaction() failed, in withdrawCash.");<br />
return false;<br />
}<br />
// --------------------------------------------------------------------------------------<br />
<br />
return true;<br />
}<br />
</pre><br />
<br />
'''Deposit cash'''<br />
<br />
Here is the complete Java implementation for Deposit Cash:<br />
<br />
<pre><br />
public boolean depositCash(String serverID, String nymID, String accountID, String purse, boolean isToken) {<br />
<br />
System.out.println("In depositCash serverID:" + serverID + " nymID:" + nymID + " acount ID:" + accountID + " isToken:" + isToken);<br />
Utility.setOtDepositCash(null);<br />
String oldPurse = purse;<br />
if (isToken) {<br />
purse = getNewPurse(purse, serverID, nymID, accountID);<br />
System.out.println("purse after getting from push purse:" + purse);<br />
if (purse == null) {<br />
Utility.setOtDepositCash(oldPurse);<br />
return false;<br />
}<br />
}<br />
// ----------------------------------------<br />
OTAPI_Func theRequest = new OTAPI_Func(OTAPI_Func.FT.DEPOSIT_CASH, serverID, nymID, accountID, purse);<br />
String strResponse = OTAPI_Func.SendTransaction(theRequest, "DEPOSIT_CASH"); // <========================<br />
<br />
if (null == strResponse) {<br />
System.out.println("IN depositCash: OTAPI_Func.SendTransaction(() failed. (I give up.) ");<br />
<br />
if (isToken) {<br />
System.out.println("IN depositCash, failed action for single token");<br />
String assetID = otapi.OT_API_GetAccountWallet_AssetTypeID(accountID);<br />
boolean importStatus = otapi.OT_API_Wallet_ImportPurse(serverID, assetID, nymID, purse) == 1 ? true : false;<br />
System.out.println("Since failure of depositCashPurse, OT_API_Wallet_ImportPurse called, status of import:" + importStatus);<br />
if (!importStatus) {<br />
Utility.setOtDepositCash(purse);<br />
}<br />
}<br />
<br />
return false;<br />
}<br />
// ----------------------------------------<br />
return true;<br />
}<br />
</pre><br />
<br />
--------------------------------------<br />
<br />
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.<br />
<br />
--------------------------------------<br />
<br />
<br />
'''Account-to-Account Transfer'''<br />
<br />
A _pending transfer_ will go into your outbox, and the recipient's inbox, pending acceptance by the recipient.<br />
<br />
FYI, every asset account has its own inbox and outbox for handling pending transactions, as well as receipts.<br />
<br />
FYI, every Nym similarly has its own Nymbox, used for receiving messages from other users, and for receiving new transaction numbers from the server.<br />
<br />
Here is the OT Script implementation of Send Transfer, from the "sample scripts":https://github.com/FellowTraveler/Open-Transactions/tree/master/scripts/samples folder:<br />
<br />
<pre><br />
def OT_ME::send_transfer(SERVER_ID, NYM_ID, ACCT_FROM, ACCT_TO, AMOUNT, NOTE) <br />
{<br />
var ot_Msg := OTAPI_Func()<br />
// -------------------------<br />
var theRequest := OTAPI_Func(ot_Msg.SEND_TRANSFER, SERVER_ID, NYM_ID, ACCT_FROM, ACCT_TO, AMOUNT, NOTE)<br />
var strResponse = theRequest.SendTransaction(theRequest, "SEND_TRANSFER")<br />
<br />
return strResponse<br />
}<br />
</pre><br />
<br />
'''Withdraw Voucher'''<br />
<br />
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.<br />
<br />
Withdrawing in voucher form is similar to withdrawing in cash: the server debits your asset account, and then gives you an official cheque.<br />
<br />
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!<br />
<br />
Here is the complete Java code to perform Withdraw Voucher:<br />
<br />
<pre><br />
public String withdrawVoucher(String serverID, String nymID, String accountID, String amount, String chequeMemo, String recepientNymID) {<br />
<br />
System.out.println("In withdrawVoucher serverID:" + serverID + " nymID:" + nymID + " acount ID:" + accountID);<br />
<br />
// ---------------------------------------------------<br />
OTAPI_Func theRequest = new OTAPI_Func(OTAPI_Func.FT.WITHDRAW_VOUCHER, serverID, nymID, accountID, recepientNymID, chequeMemo, amount);<br />
String strResponse = OTAPI_Func.SendTransaction(theRequest, "WITHDRAW_VOUCHER"); // <========================<br />
<br />
if (null == strResponse) {<br />
System.out.println("OTAPI_Func.SendTransaction() failed, in withdrawVoucher.");<br />
return null;<br />
}<br />
// ---------------------------------------------------------<br />
String ledger = otapi.OT_API_Message_GetLedger(strResponse);<br />
if (ledger == null) {<br />
System.out.println(" ledger is null, returned by OT_API_Message_GetLedger, serverResponseMessage passed as argument");<br />
return null;<br />
}<br />
String transaction = otapi.OT_API_Ledger_GetTransactionByIndex(serverID, nymID, accountID, ledger, 0);<br />
if (transaction == null) {<br />
System.out.println("withdrawVoucher: transaction is null, returned by OT_API_Ledger_GetTransactionByIndex, argument passed, index 0 and ledger :" + ledger);<br />
return null;<br />
}<br />
// ---------------------------------------------------------<br />
String output = otapi.OT_API_Transaction_GetVoucher(serverID, nymID, accountID, transaction);<br />
System.out.println("output returned by OT_API_Transaction_GetVoucher:" + output);<br />
<br />
return output;<br />
}<br />
</pre><br />
<br />
<br />
---------------<br />
<br />
'''BASKET CURRENCIES'''<br />
<br />
'''Create a new Basket Currency'''<br />
<br />
First, invent the basket in your head. Give it name: _"Clams."_<br />
<br />
Next, give it a ratio in terms of other existing currencies: _"10 Clams equals a basket of 5 dollars, 3 Euro, and 20 Bitcoin"_<br />
<br />
Call '''OT_API_GenerateBasketCreation()''' to begin creating the basket. The _"10 Clams"_ from above is set here.<br />
<br />
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.<br />
<br />
Now that the basket has been defined, call '''OT_API_issueBasket()''' to actually create the basket currency on the server.<br />
<br />
(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.)<br />
<br />
<br />
'''Exchange Digital Assets in/out of a Basket Currency (from your Asset Accounts)'''<br />
<br />
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. <br />
<br />
What's the transfer multiple? Remember the ratio above: "10 Clams equals a basket of 5 dollars, 3 Euro, and 20 Bitcoin" <br />
<br />
Here are examples of the transfer multiple:<br />
<br />
"10 Clams == 5 USD, 3 EUR, 20 BIT" (Transfer multiple: 1)<br />
<br />
"20 Clams == 10 USD, 6 EUR, 40 BIT" (Transfer multiple: 2)<br />
<br />
"30 Clams == 15 USD, 9 EUR, 60 BIT" (Transfer multiple: 3)<br />
<br />
"40 Clams == 20 USD, 12 EUR, 80 BIT" (Transfer multiple: 4)<br />
<br />
"50 Clams == 25 USD, 15 EUR, 100 BIT" (Transfer multiple: 5)<br />
<br />
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.)<br />
<br />
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.<br />
<br />
Now that it's all set up, call '''OT_API_exchangeBasket()''' to actually message the server and perform the exchange.<br />
<br />
'''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!<br />
<br />
------------------------<br />
<br />
'''PROCESSING YOUR INBOX'''<br />
<br />
'''Process the Receipts and Pending Transfers in your Inbox'''<br />
<br />
If you wish, call '''OT_API_getInbox()''' to grab the latest inbox from the server. <br />
<br />
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.<br />
<br />
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:<br />
<br />
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.<br />
<br />
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...<br />
<br />
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...) <br />
<br />
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.<br />
<br />
Next, call '''OT_API_Ledger_FinalizeResponse()''' which will create a _Balance Agreement_ for the ledger.<br />
<br />
Finally, call '''OT_API_processInbox()''' to send your message to the server and process the various items.<br />
<br />
(See the accept_inbox.ot script.)<br />
<br />
If the message was successful, then use '''OT_API_Message_GetBalanceAgreementSuccess()''' and '''OT_API_Message_GetTransactionSuccess()''' to see just _how_ successful.<br />
<br />
---------------------------------<br />
<br />
'''MARKETS and PAYMENT PLANS'''<br />
<br />
'''Setup a Payment Plan'''<br />
<br />
The Merchant draws up the Payment Plan using '''OT_API_ProposePaymentPlan'''<br />
<br />
Then he sends it to the Customer, who calls '''OT_API_ConfirmPaymentPlan'''<br />
<br />
The Customer's wallet activates the payment plan by sending it to the server using this function: '''OT_API_depositPaymentPlan()'''<br />
<br />
(Receipts will process into the respective parties' inboxes.)<br />
<br />
Use OT_API_cancelCronItem() to cancel any payment plan (or market offer.)<br />
<br />
If the message was successful, then use '''OT_API_Message_GetBalanceAgreementSuccess()''' and '''OT_API_Message_GetTransactionSuccess()''' as described above in the _deposit cash_ instructions.<br />
<br />
'''Issue a [[Markets|Market]] Offer'''<br />
<br />
Call this function: '''OT_API_issueMarketOffer()'''<br />
<br />
(That's the low-level one. See create_offer.ot script for the high-level version.)<br />
<br />
Call '''OT_API_Message_GetSuccess''' to find out if the message was a SUCCESS or FAILURE.<br />
<br />
If the message was successful, then use '''OT_API_Message_GetBalanceAgreementSuccess()''' and '''OT_API_Message_GetTransactionSuccess()''' as described above in the _deposit cash_ instructions.<br />
See the OTScript and Java versions of these calls.<br />
<br />
Once an offer goes onto the market, multiple trades may occur between it and the other offers on the market.<br />
<br />
(According to the rules in the offers.) Receipts will process into the respective parties' inboxes after each trade.<br />
<br />
'''Cancel a Market Offer'''<br />
<br />
Use '''OT_API_cancelNymMarketOffer''' to remove an offer from a market.<br />
<br />
If the message was successful, then use '''OT_API_Message_GetBalanceAgreementSuccess()''' and '''OT_API_Message_GetTransactionSuccess()'''<br />
<br />
'''Retrieving Market Data from OT Server:'''<br />
<br />
'''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'''<br />
<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 />
<br />
'''if (otapi.Exists("markets", serverID, "market_data.bin")) bFoundFile = true;'''<br />
<br />
Here is some Java code that reads the market list object from local storage, assuming bFoundFile is true:<br />
<br />
<pre><br />
MarketList marketList = null;<br />
Storable storable = null;<br />
<br />
if (otapi.Exists("markets", serverID, "market_data.bin")) <br />
{<br />
storable =<br />
otapi.QueryObject(StoredObjectType.STORED_OBJ_MARKET_LIST,<br />
"markets", serverID, "market_data.bin");<br />
if (storable==null)<br />
return null;<br />
marketList = MarketList.ot_dynamic_cast(storable);<br />
}<br />
</pre><br />
<br />
Once you have the market list, here is some sample Java code to read the details of an individual market from that list:<br />
<br />
<pre><br />
public static Object getMarketDetails(String marketID)<br />
{<br />
MarketList marketList = Utility.getMarketList();<br />
<br />
if (marketList == null) <br />
{<br />
return null;<br />
}<br />
<br />
for (int i=0; i < marketList.GetMarketDataCount(); i++)<br />
{<br />
MarketData marketData = marketList.GetMarketData(i);<br />
<br />
if (marketData == null)<br />
continue;<br />
<br />
String [] row = new String[2];<br />
<br />
if (marketID.equals(marketData.getMarket_id())) <br />
{<br />
String[] data = new String[2];<br />
marketData.getLast_sale_price();<br />
marketData.getCurrent_ask();<br />
<br />
// Etc!! This is where you get the market details.<br />
}<br />
}<br />
<br />
// return custom object here (row/data or whatever), or null if failure..<br />
return null;<br />
}<br />
</pre><br />
<br />
'''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'''<br />
<br />
(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.)<br />
<br />
'''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'''<br />
<br />
To retrieve the offers that a specific Nym has out on the market, use: '''OT_API_getNym_MarketOffers'''<br />
<br />
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. <br />
<br />
After a successful retrieval, you can load the data from this location: '''nyms/SERVER_ID/offers/NYM_ID.bin'''<br />
<br />
If you want to see the Nym's private list of his ''completed trades'', the path to load it from is here:<br />
<br />
'''nyms/trades/SERVER_ID/NYM_ID'''<br />
<br />
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.)<br />
<br />
As before, the appropriate data object can be found in testwallet/OTAPI.i along with all the others.<br />
<br />
----------------------<br />
<br />
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.<br />
<br />
See also:<br />
<br />
[[API|The OT low-level API]]<br />
<br />
[[Installation]]<br />
<br />
[[Opentxs | opentxs command-line tool]]<br />
<br />
[[List of Classes | The OT C++ class library]]<br />
<br />
'''Diagrams:'''<br />
* [http://billstclair.com/ot/ot-diagram.jpg Architecture Overview]<br />
* [http://billstclair.com/ot/OT-Anon-CashOnly.jpg Fully-Anonymous] (cash only)<br />
* [http://billstclair.com/ot/OT-Pseudonym-Instruments.jpg Pseudo-Anonymous] (using accounts).</div>Cryptomanhttp://opentransactions.org/wiki/index.php?title=About&diff=104About2013-06-12T13:13:40Z<p>Cryptoman: </p>
<hr />
<div>'''What is OPEN-TRANSACTIONS?'''<br />
<br />
* Open-Transactions is an [[Use Cases|easy-to-use]], financial crypto, [[Sample Cash|digital cash]] and transaction [[List of Classes|library]].<br />
* Open-Transactions includes a '''[[API|client API]]''', a working '''[[OT-Server|server]]''', a '''[[TestGUI|GUI test wallet]]''' (in Java) and a [[opentxs|command-line]] wallet utility.<br />
* Open-Transactions features: a large variety of financial instruments, markets, basket currencies, unforgeable account balances, '''untraceable digital cash,''' destruction of account history, [http://iang.org/papers/ricardian_contract.html Ricardian contracts], Smart Contracts (scriptable clauses), and more.<br />
<br />
'''WHAT DOES IT DO?'''<br />
<br />
* '''Open-Transactions allows users to issue and manipulate digital assets.'''<br />
* Any issuer can sign and distribute new [[Sample Currency Contract|currency contracts]] in order to create new digital asset types.<br />
* Users may create many ''pseudonyms'' (public keys), each of which may own ''asset accounts'' of various types, on OT servers.<br />
* Users can operate '''&quot;cash-only&quot;''' ''(without accounts)'' for maximum anonymity, using '''[[Sample Cash|untraceable digital cash]]'''.<br />
<br />
-----<br />
<br />
'''NEW: GUI Mock-Ups! (first draft)'''<br />
<br />
[https://www.fluidui.com/editor/live/preview/p_8ZN0r9Pbp2XzPC7yL3lDFw5lW2L7vEye.1343824445082 standard mode]<br />
<br />
[https://www.fluidui.com/editor/live/preview/p_XcN9TmQ5FItuPr5QctxES2XfAhinsVPp.1343659566990 advanced mode]<br />
<br />
[http://www.reddit.com/r/Agorism/comments/19p6oa/how_to_issue_your_own_currency_using/ Install via apt-get (click here)]<br />
<br />
-----<br />
<br />
'''Radio Interview'''<br />
<br />
[http://agoristradio.com/?p=234 Part 1, courtesy of AgoristRadio]<br />
<br />
[http://agoristradio.com/?p=246 Part 2, courtesy of AgoristRadio]<br />
<br />
Bitcoin donation address: 1NtTPVVjDsUfDWybS4BwvHpG2pdS9RnYyQ<br />
<br />
IRC: #opentransactions at irc.freenode.net<br />
<br />
-----<br />
<br />
'''Video Walkthru''' <br />
<br />
[http://vimeo.com/28141679 Video 1 posted by J. Orlin Grabbe]<br />
<br />
[http://vimeo.com/28142096 Video 2 posted by J. Orlin Grabbe]<br />
<br />
[http://open-transactions.github.io/tv/ New videos!]<br />
<br />
-----<br />
<br />
'''FINANCIAL INSTRUMENTS'''<br />
<br />
* Users can transfer digital assets ''securely and provably'', with [[Triple-Signed Receipts|receipts]] signed by all parties.<br />
* '''Even an OT server cannot change balances, or forge transactions--since it cannot forge your signature on your receipt.'''<br />
* Open-Transactions supports a range of '''[[Instruments|financial instruments]]''' such as account transfer, '''[[Sample-Cheque|cheques]]''' and vouchers (aka &quot;cashier's cheques&quot; or &quot;banker's cheques&quot;), in addition to cash.<br />
* 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.<br />
<br />
-----<br />
<br />
'''Diagrams:'''<br />
<br />
[http://billstclair.com/ot/ot-diagram.jpg Architecture Overview]<br />
<br />
[http://billstclair.com/ot/OT-Anon-CashOnly.jpg Fully-Anonymous (cash only)]<br />
<br />
[http://billstclair.com/ot/OT-Pseudonym-Instruments.jpg Pseudo-Anonymous (using accounts)]<br />
<br />
-----<br />
<br />
'''MARKETS, BASKET CURRENCIES, and SMART CONTRACTS'''<br />
<br />
* Open-Transactions also implements higher-level, '''contract-based transactions''' such as '''payment plans''' and '''markets with trades'''.<br />
* 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.<br />
* '''Basket currencies''' are also supported, as well as payment plans (recurring payments.)<br />
* [[Smart contracts]]: Multi-party agreements with scriptable clauses... including hooks, callbacks, internal state, etc.<br />
* [[Client-side scripting]]: <code>!/usr/bin/env ot</code> The entire (mostly) high and low level OT API is available within your scripts.<br />
<br />
-----<br />
<br />
'''TRIPLE SIGNED RECEIPTS'''<br />
<br />
* 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'''.<br />
* Without the special mechanism that makes this possible, ''all parties would otherwise be forced to store all receipts forever''.<br />
* Nyms and Asset Types have consistent IDs across all OT servers, since the ID is formed by hashing the relevant contract or public key.<br />
<br />
-----<br />
<br />
The real beauty of Open-Transactions is the as-yet-unwritten future of ''new ideas'' that you can build with it, and the future liberty and security of your children that you can help to protect by doing so--in a very real and tangible way.<br />
<br />
-----<br />
<br />
'''IS Open-Transactions [[CENTRALIZED]]?'''<br />
<br />
'''The vision is not of a central server that you must trust.''' '''Rather, the vision is of federated servers you don't have to trust.'''<br />
<br />
-----<br />
<br />
'''Mailing list''': open-transactions-subscribe@rayservers.com<br />
<br />
'''[[FAQ]]'''<br />
<br />
'''[[Components and GNU Licensing|Components]]'''<br />
<br />
'''[[Installation|Install Notes]]'''<br />
<br />
'''[[Use Cases]]'''<br />
<br />
'''[[API]]'''<br />
<br />
'''[[Business Cases]]'''<br />
<br />
'''[[Release Notes]]'''<br />
<br />
-----<br />
<br />
The server itself is a [[Transactions|transaction processor]] in the cypherpunk tradition. In more detail:<br />
<br />
* Many '''financial instruments''' are supported: Users can write '''cheques''', purchase '''cashier's cheques''' (&quot;vouchers&quot;), and withdraw in '''[[Sample Cash|untraceable digital cash]]'''. The software uses Chaumian-style, blinded tokens courtesy of the [http://anoncvs.aldigital.co.uk/lucre/ Lucre] library by Ben Laurie.<br />
* 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.<br />
* 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''.<br />
* '''Any user can issue new digital currencies''' and digital asset types, by uploading the new [currency contract] to the server. (This functionality is comparable to [http://www.systemics.com/docs/sox/overview.html Ricardo] by [http://financialcryptography.com/ Ian Grigg].)<br />
* '''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 Chkeroff.)<br />
* [[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].)<br />
* 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'''.<br />
* 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'''.)<br />
* [[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].<br />
* [[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><br />
* 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.)<br />
* '''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.<br />
* 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 [https://github.com/FellowTraveler/Open-Transactions/wiki/Auditing auditing protocol].<br />
* 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.<br />
* '''All communications are secured with OpenSSL.''' All messages are also signed and encrypted. All transactions require signatures from relevant parties including the server.<br />
* 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.)<br />
* The software is fully '''cross-platform''': '''Linux, Mac OS X, FreeBSD, Android, and Windows''' are supported with makefiles, project files, and instructions.<br />
* 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.'''<br />
* [[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.<br />
* OT currently supports '''MsgPack''' and '''protobuf''' for data packing, though new packers can be added by subclassing OTDB::Packer.<br />
<br />
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>Cryptomanhttp://opentransactions.org/wiki/index.php?title=Release_Notes&diff=103Release Notes2013-06-12T13:10:02Z<p>Cryptoman: Created page with "Please see the ''Wiki'', ''Use Cases'', ''FAQ'', and ''Business Cases''. NOTES on the Version: 0.85c--- Lots of progress! Added: <pre> - Im..."</p>
<hr />
<div>Please see the ''[[Main Page|Wiki]]'', ''[[Use Cases]]'', ''[[FAQ]]'', and ''[[Business Cases]]''.<br />
<br />
NOTES on the Version:<br />
<br />
0.85c--- Lots of progress! Added:<br />
<br />
<pre> - Import/export Nym, import/export cert, import/export Cash.<br />
- Cash can now be exported to a passphrase-protected purse,<br />
or a recipient Nym (your choice.) Try: opentxs exportcash<br />
Also: opentxs exportcash --args &quot;passwd true&quot;<br />
<br />
- Added API call: OT_API_CreatePurse_Passphrase, for creating<br />
password-protected cash purses. Also, a few purse-related<br />
API calls have changed slightly.<br />
<br />
- The &quot;instrument&quot; API calls have been simplified and some<br />
were renamed.<br />
<br />
- You can now change the master passphrase on your wallet.<br />
<br />
- The opentxs command-line utility now accepts name<br />
abbreviations in addition to ID abbreviations.<br />
For example, this command-line option:<br />
opentxs --mynym T1Q3wZWgeTUoaUvn9m1lzIK5tn5wITlzxzrGNI8qtaV<br />
Works abbreviated: opentxs --mynym T1<br />
AND works using the name: opentxs --mynym &quot;FT's Test Nym&quot;<br />
<br />
- Added script to scripts/util for adjusting usage credits.<br />
See Open-Transactions/scripts/util/adjust_usage.ot<br />
<br />
- load_or_retrieve_pubkey(serverID, nymID, recipientNymID)<br />
This new ot_made_easy function should be called, for example,<br />
before exporting cash to a given Nym, in any scripts. That<br />
way the public key for the recipient can be retrieved, if<br />
needed, before it's used. For HisNym (--hisnym ID) opentxs<br />
will first search by full ID, then by abbreviated ID, then<br />
by abbreviated name as it appears in the wallet, and then<br />
finally by downloading the pubkey from the server, if<br />
necessary.<br />
<br />
- OTAssetContract is now able to take an amount, and format<br />
it properly for that currency based on locale plus rules<br />
in the currency contract. For example, 2763 might display<br />
as $27.63.<br />
<br />
- Hash calculation was moved from OTIdentifier to OTCrypto.<br />
<br />
- Various methods in OTPurse and OTToken were changed to accept<br />
EITHER an owner Nym, or a symmetric key instead.</pre><br />
0.84c--- Market-related commands added to the opentxs CLI tool: getmarkets, showmarkets, getoffers, showoffers, getmyoffers, showmyoffers, and PAY DIVIDEND :-)<br />
<br />
0.84a--- OT now creates ALL data files it needs.<br />
<br />
0.83 --- Added OTKeyring for handling the Mac Keychain, Windows DPAPI, the KDE KWallet, and the Gnome Keyring.<br />
<br />
0.82e--- Various bugs were fixed: create_asset_contract.ot and create_ server_contract.ot were both fixed. An empty passphrase will no longer assert on the client side. Release() is no longer called from inside destructors.<br />
<br />
0.82c--- Resync script was fixed (in scripts/utils folder.) You should never need to actually use this, but it's there as a tool. I also fixed a bug in ot_utility.ot, so if you are keeping your existing data for any reason, make sure to copy over the new scripts to your ~/.ot/client_data/scripts/ot folder, so you get the updates.<br />
<br />
<pre> Also: &quot;write_cheque.ot&quot; was added to the scripts/samples folder.</pre><br />
0.82b--- The createmint utility was fixed; the mints were regenerated; cash withdrawal was fixed in the test GUI. The contents of scripts/ot and scripts/samples were updated. (Make sure, if you are keeping your current data folder, to overwrite the old script headers in ~/.ot/client_data/scripts/ot with the new ones in: Open-Transactions/scripts/ot (Bugs were fixed in the script headers) Also, send_user_msg.ot was fixed.<br />
<br />
0.82a--- Automake support added! Thanks to da2ce7.<br />
<br />
0.80f--- OTAsymmetricKey now creates its own copy of the EVP_PKEY when setting it, to fix an openssl-related segfault.<br />
<br />
<pre> master_key_timeout was added to the config files.<br />
<br />
_PASSWORD_LEN bug was fixed. (#ifndef, #define'd as 128.)</pre><br />
0.80e--- Added the OTMasterKey class. The user's passphrase is no longer used to directly open his private keys for his Nyms. Instead, the passphrase is used to derive a key, which is used to unlock a MASTER key, and THAT is used for the private keys. This master key is stored in protected memory for X minutes, and then is destroyed. During the X minutes, you will NOT have to type your passphrase (more than once.) But once the X minutes are over, then you WILL be forced to enter your passphrase once again.<br />
<br />
0.80d--- Fixed up some of the CRYPTO code. OTPayload and OTPassword now have a Randomize() method. OTAsymmetricKey now has a &quot;timer&quot; mechanism for keys, and takes pains to wipe them when done. Some memory is securely zeroed out, such as OTString, OTData, OTPayload, and OTPassword. A new OTSymmetricKey class was added for passphrase-protection as a new alternative to public keys. OTEnvelope was significantly re-written and now supports multiple recipients, as well as password-protected envelopes. OTSymmetricKey uses a random key for all encryption/decryption, and this random key is then encrypted to another key that's generated using a key-derivation algorithm with passphrase input.<br />
<br />
<pre> The Init/Cleanup code was also significantly upgraded. Special<br />
tricks are now used to reduce occurances of memory being written<br />
to swap files, as well as to prevent core dumps. Functions were <br />
added such as safe_memcpy, safe_strlen, safe_strcopy, etc.</pre><br />
0.80c--- Added synchronization code to reduce the number of box receipts needing to be downloaded. (Should speed things up a bit.) Download the latest Moneychanger!<br />
<br />
0.80 --- Contracts are now serialized in ascii-armored form, instead of clear-signed form (for cross-platform capabilities.) OT is still able to read the clear-signed versions, so it should support old data. Some more hiccups were fixed since the big synchronization changes were added.<br />
<br />
0.79 --- * Inbox, Outbox, and Nymbox now are hashed, with the hashes sent to the client on certain server reply messages. The client will refrain from downloading those files unless the hashes have changed. * The server drops all important replies into the Nymbox, to make sure the client doesn't miss them (for synchronization purposes.) * The client-side now tracks all sent messages, and when a reply is lost, the client is smart enough to download the Nymbox and check for a reply there, before harvesting any transaction numbers back for re-use. * The API now draws a sharp distinction between 'error' messages and 'failed' messages. ('Error' could mean &quot;missed server reply&quot; which could actually mean, &quot;The reply was actually a success, but we just didn't know because it was dropped on the network.&quot; OT takes all of this into account now, for synchronization purposes.) * All API calls to send a message now return the request #, if the message was actually sent. This allows the client developer to look up any replies based on the request #, as well as reference the sent message itself by request #. * The high-level API wrapper (in Java) has been completely re-written for this new synchronization code. * The high-level API wrapper (in OTScript) has NOT yet been re-written, but that is coming probably with my next check-in.<br />
<br />
0.78 --- Fixed a nasty bug in signatures that forced me to regenerate the test data. Nyms stayed the same, but all contracts were re-signed and all server IDs and asset IDs have changed. Due to this all the accounts were re-created as well.<br />
<br />
<pre> ** Notice the growing scripts/samples folder. **<br />
<br />
Also, transaction numbers are downloaded 20 at a time now,<br />
in a single receipt (instead of forcing 50 box receipts to<br />
download for each and every transaction number, as used to<br />
happen.) <br />
</pre><br />
0.77 --- Added Box Receipts. (Inboxes now store their receipts separately, with only a hash remaining in the main file.) Many other misc bug fixes.<br />
<br />
0.76 --- Bugfix release. Many bugs were uncovered by recent testing with new users. (One user with an especially bad network connection.) OT now has much more powerful polling, blocking, configurability, timeouts, synchronization, and robustness against network faults. Also see resync.ot in the scripts folder.<br />
<br />
0.75 --- Smart Contracts! (Server-side SCRIPTABLE CLAUSES, and hooks!) Users can now design and activate their own financial instruments, in SCRIPT FORM!<br />
<br />
<pre> Also, configurable permissions were added for all of the OT server's<br />
transactions and messages. See your config file: ~/.ot/server.cfg</pre><br />
0.74 --- OT can now be configured (or not) to require USAGE CREDITS. (This makes it possible for server operators to charge transaction fees.) API functions were added for viewing and setting these usage credits.<br />
<br />
<pre> Also: I added whitespace trimming, to make sure contracts will calculate<br />
the exact same ID every single time. (I regenerated all the test data.)</pre><br />
0.73 --- Client side scripting! See the Open-Transactions/scripts folder. (The ''entire'' OT API is now available for use inside the client- side scripts.)<br />
<br />
0.72b--- Basket Exchange is now working in the GUI!<br />
<br />
0.72a--- More bug fixes. Plus: added more options to the ini files.<br />
<br />
0.72 --- This release was all debugging. It's downright embarrassing, all the bugs I still had to fix. A new version of the GUI is coming soon, with matching fixes.<br />
<br />
0.71 --- Massive upgrades to the command-line utility for OT, as well as the addition of &quot;make install&quot;. Lots of debugging. Default data folders are now ~/.ot/server_data and ~/.ot/client_data<br />
<br />
0.70 --- Added finalReceipt, basketReceipt, plus related internal changes. Also added messages for DELETING accounts and nyms.<br />
<br />
0.69 --- Bug fixes in preparation for the new MARKETS screen...<br />
<br />
0.68 --- Minor bug fixes at the request of client developers.<br />
<br />
0.67 --- Output now goes to a logfile (in the config file) or stderr. No more logs to standard output. OT client no longer hangs if server isn't running. Client and Server now both use ini files as well as config files.<br />
<br />
0.66 --- Added the rest of the Market API, since the GUI will soon support it!<br />
<br />
0.65 --- THE SAMPLE DATA WAS ALL RE-GENERATED... So grab it, plus the latest version of the code. What all changed?<br />
<br />
<pre> I added default packing to all OTASCIIArmor strings. I think<br />
OT should now be binary compatible across all platforms, but<br />
we'll see. Oh and, due to this, re-generated all sample data.<br />
<br />
===&gt; Also added bindings for **the D programming language**<br />
http://www.digitalmars.com/d/2.0/overview.html<br />
<br />
===&gt; Also added .ot_ini files! (What sorts of options would <br />
YOU like to see in the configuration files for OT?)<br />
<br />
Also did some bug fixes in OTString, OTMint, and createmint.</pre><br />
0.64 --- Added default packing (currently protobuf) to all binary to base64 encoding. I had a recent complaint about binary incompatibility across platform, and this is either the complete fix, or at least a strong beginning of a drive to ensure binary compatibility across all platforms.<br />
<br />
0.63 --- Open Transactions has entirely been converted to the NEW STORAGE CLASS. (This means you can easily switch to different storage systems, instead of using the filesystem, just by sub- classing the OTDB::Storage class and overriding a few methods.)<br />
<br />
<pre> IN OTHER NEWS: OT now uses the ZeroMQ library for transport!<br />
To learn more about OT's new transport capabilities, check out<br />
this guide: http://zguide.zeromq.org/page:all</pre><br />
0.62 --- Load/SaveWallet uses the new Storage class. Dynamic casting was added to the storable objects. Pack/Unpack were debugged. Store/Query now supports plain strings. Contact ID was added. Storable objects now use smart pointers for internals.<br />
<br />
0.61 --- Added new Storage context class! Currently filesystem supported only, BUT you can now add any new storage you want simply by subclassing OTDB::Storage and implementing a few methods!! Many other storage methods can now quickly and easily be added.<br />
<br />
<pre> Furthermore, the Storage object was designed to make it easy to<br />
swap Packing libraries. OT now supports MsgPack IN ADDITION TO<br />
Google's Protobuf library. Soon these will also be used to<br />
clear up any binary incompatibilities between different<br />
systems running OT. (So the contracts will work on all systems<br />
equally.)</pre><br />
0.60 --- Added password callback! Works in the API, in Java, etc.<br />
<br />
0.59 --- Fixed ANOTHER old bug in receipt verification.<br />
<br />
0.58 --- Added API stub for Import Nym<br />
<br />
0.57 --- Fixed an old bug in receipt verification.<br />
<br />
0.56 --- &quot;Verify Last Signed Receipt against intermediary files&quot; has officially been added to the API. Also added more ability to manipulate Tokens through the API. Also some debugging in balance agreement (cleaned up an old bug that prevented transactions while certain receipt types were in the inbox.)<br />
<br />
0.55 --- Minor release, goes along with Moneychanger (new Java GUI.)<br />
<br />
0.54 --- OT now stores the last 1024 logs internally, and makes them available via the API. Various other API debugging was done.<br />
<br />
0.53 --- API functions for Nym outbox, and for checking success status of a transaction message. Various other API fixes preparing for the upcoming test GUI.<br />
<br />
0.52 --- API functions for deleting Nyms, Accounts, and Contracts.<br />
<br />
0.51 --- API functions for Mail and Transactions.<br />
<br />
0.50 --- BASE-62-ENCODED IDs (much more compact.)<br />
<br />
0.45 --- Added a few API functions and updated the Windows build.<br />
<br />
0.44 --- RECEIPT VERIFICATION. Goes with the below change. Client-side receipts are now saved after every transaction, and whenever account/inbox/outbox files are downloaded, they're verified against the last signed receipt.<br />
<br />
0.43 --- BALANCE AGREEMENT / NO ACCOUNT HISTORY has been added! Just make sure you grab the outbox and inbox, and the account file, before doing a transaction, since they are needed for balance agreement, which is now operational and required.<br />
<br />
0.42 --- More bug fixes, plus added OT_API_CreateNym() (finally).<br />
<br />
0.41 --- Bug fixes in support of API, added various transaction types, receipt types, item types, to get full transfer receipt process working end-to-end.<br />
<br />
0.40 --- More additions to the API, plus many under-the-hood fixes.<br />
<br />
0.39 --- Continually updating the API based on developer feedback.<br />
<br />
0.38 --- Added Payment Plans, Markets, and Baskets to the API. Also added message buffer access to the API, so you can read all the server replies if you want to (or flush them...)<br />
<br />
0.37 --- Added build option DSP=1, for using custom builds of OpenSSL, and for turning off all the output logs.<br />
<br />
0.36 --- Top-level build targets added for API in Python, Ruby, PHP, and Perl! It's now this easy to build the API:<br />
<br />
<pre> cd Open-Transactions<br />
make clean<br />
<br />
Then, from the same folder:<br />
<br />
make ruby<br />
make python<br />
make php5<br />
make perl5<br />
make java (added in v0.44)<br />
<br />
(More languages are supported, but for now these are the ones<br />
available at the top level.) </pre><br />
0.35 --- Huge additions to the API! See testwallet/OTAPI_funcdef.h for the complete interface, with NOTES above each function.<br />
<br />
<pre> That same interface is also wrapped by SWIG, and available<br />
in Java, Python, Ruby, Perl, Php, Lisp, etc, so those OTAPI<br />
functions are relevant to ALL developers...<br />
<br />
People have asked about documentation so hopefully the API,<br />
plus the notes within, will answer any questions for now<br />
until more professional docs can be written. As always, feel<br />
free to contact me with any questions.<br />
<br />
This release continues my push to make the library EASY and<br />
ACCESSIBLE to all developers, in all languages, on all<br />
platforms. There are already multiple developers who are<br />
starting to play around with client software using the OTAPI,<br />
and I am very responsive to their needs.<br />
<br />
*** The latest SECURITY notes..<br />
<br />
..Any new software requires testing with users AND peer review!<br />
Open Transactions was recently reviewed by Ben Laurie, and<br />
I accepted all the changes that he submitted. It's a good<br />
start! This process must continue.<br />
<br />
..In this release I have replaced all instances of strcpy<br />
with strlcpy/strcpy_s, and all instances of sprintf with<br />
snprintf/sprintf_s, and all instances of vsprintf with<br />
vsnprintf/vsprintf_s, and all instances of strcat with<br />
strlcat/strcat_s. It's important to make sure there are no<br />
buffer overflows in this code.<br />
<br />
..I also set up the code with Valgrind, and went through all<br />
the warnings, adding comments, fixes, and exclusions where<br />
appropriate or necessary. This process will continue, but<br />
it's important to run code scanners on this sort of software!<br />
</pre><br />
0.34 --- (Various additions to the API at developer request.)<br />
<br />
0.33 --- Slicker build process. This release is all about having an EASY BUILD PROCESS, and is based on real-world feedback I've been getting from YOU, my testers:<br />
<br />
<pre> * For ALL users: XmlRpc++ is now part of the distribution, and is part of the <br />
build process. Various users had trouble installing this library separately, <br />
so I integrated it into the project. Now it's built-in! <br />
* For ALL users: Platform now auto-detected by MUCH easier/slicker Makefiles. <br />
(And as with the last release, I was able to eliminate several Makefiles.) <br />
To build (from main folder), just type: <br />
make <br />
(You may prefer 'make rpc', to build in the preferred XmlRpc mode.) <br />
* To build the API: <br />
cd testwallet; <br />
make -f Makefile.API TRANSPORT=XmlRpc LANGUAGE=c <br />
make -f Makefile.API TRANSPORT=XmlRpc LANGUAGE=ruby <br />
make -f Makefile.API TRANSPORT=XmlRpc LANGUAGE=java <br />
make -f Makefile.API TRANSPORT=XmlRpc LANGUAGE=python <br />
make -f Makefile.API TRANSPORT=XmlRpc LANGUAGE=perl5 <br />
make -f Makefile.API TRANSPORT=XmlRpc LANGUAGE=php5 <br />
make -f Makefile.API TRANSPORT=XmlRpc LANGUAGE=lisp <br />
Etc... <br />
Slick, eh? In all the above cases, the platform is automatically detected. <br />
See testwallet/API-README.txt for more notes. <br />
<br />
* For MAC users: The Makefiles had been using the wrong location for OpenSSL <br />
(at least, for the Macports 1.0.0a version) so I fixed this. The previous <br />
Makefiles referenced the default location, where (the wrong) version 0.9.8 <br />
can be found. (The new version looks in /opt, as used by MacPorts.) <br />
<br />
* For LINUX users: Now, OT attempts to link 64-bit libs where appropriate. <br />
<br />
* For FREEBSD users: The full new Makefile is now FULLY operational on <br />
FreeBSD, including the utilities &quot;createmint.exe&quot; and &quot;signcontract.exe&quot;, <br />
which were previously unsupported on FreeBSD. <br />
<br />
0.31 --- **Native API**, with easy Makefiles, added for: <br />
**Java, Lisp, Ruby, Python, Perl, PHP, C, C++, Objective-C, C#,**<br />
and Tcl. Also supporting JRuby, Jython, and any other languages<br />
on the JVM. <br />
<br />
Transport is now implemented as a CALLBACK FUNCTION, which<br />
means it is now VERY EASY to swap out to different forms of<br />
transport (though XmlRpc is probably the last form we'll ever<br />
need.)<br />
<br />
The build process has been greatly simplified, and many Makefiles<br />
were made redundant and removed.</pre><br />
0.30 --- MAJOR RELEASE! Markets, Payment Plans, and OT as a Web Service!<br />
<br />
<pre> *** Open Transactions is now officially a WEB SERVICE! The server,<br />
client, and API now support *XML-RPC/HTTP*, in addition to the<br />
TCP/SSL mode from before.<br />
<br />
*** Open Transactions now supports real MARKETS with 2-way trades!<br />
These markets are full-featured, and allow for LIMIT orders,<br />
STOP orders, DAY orders, FILL-OR-KILL orders, STOP LIMITS, etc.<br />
Markets also have SCALE, which means bulk pricing and arbitrage.<br />
<br />
*** Open Transactions now supports PAYMENT PLANS. As long as both<br />
parties have signed the contract, the server will continue<br />
processing it according to its terms, placing receipts in the<br />
inboxes of the two parties until the payments are done.<br />
<br />
*** All data files were removed to a data folder, and all file<br />
paths were removed from data files (filenames are generated<br />
now, when needed.) This all means datafiles are much easier now.</pre><br />
// ---------------------------------------------------------------------<br />
<br />
0.25 --- All FILE pointers were removed and replaced with C++ fstreams.<br />
<br />
<pre> An all new logging class, with errors, asserts, and multi-<br />
verbosity output. See the OTLog.h and .cpp files for more.<br />
(Centralizing the output and logging also helps porting efforts.)<br />
<br />
All the test certs were regenerated, and the contracts were<br />
re-signed, etc. This time they will last for 10 years, instead<br />
of 30 days. Slight fix to the Open-Transactions/ssl Makefile.</pre><br />
0.24 --- FreeBSD working!<br />
<br />
0.23 --- Android version! (In support of our upcoming Android client.)<br />
<br />
<pre> Now it's easier than ever to use Open Transactions in your<br />
Java and C++ applications, for Mac, Linux, and Windows!</pre><br />
0.22 --- EASY Makefiles and project files are now available for the JNI Java interface, as well as the high-level C++ API.<br />
<br />
<pre> Makefiles are supplied for MAC and LINUX, as well as project<br />
files for XCode on Mac and MS Visual C++ 2010 Express on Windows. <br />
<br />
&quot;FiatCash&quot; (the first client, on Android) is humming along<br />
and hopefully we'll have some basic version soon up on Github.<br />
<br />
Negative transactions are no longer allowed for vouchers,<br />
account transfers, or cash withdrawals. They are still, however,<br />
allowed for cheques, which serve as invoices.<br />
<br />
Various global variable issues were cleaned up...</pre><br />
// ---------------------------------------------------------------------<br />
<br />
0.21 --- Windows release!<br />
<br />
<pre> Open Transactions now supports Windows, LINUX, and Mac OS X.<br />
(In the same code base.)<br />
<br />
This distribution comes with gcc Makefiles for Mac and Linux,<br />
as well as XCode project files for Mac and Microsoft VC++ project<br />
files for Windows.<br />
<br />
The Windows port was at the request of an Android developer who<br />
has begun work on a wallet (client app) that he calls &quot;FiatCash&quot;.<br />
He will be building it on Windows, in Java, using the Open<br />
Transactions JNI interface to talk to the library. When complete,<br />
the wallet software will run on Android phones.<br />
<br />
INVOICES: Imagine that you hand someone an invoice. He runs it<br />
through his bank account and the money is automatically transferred<br />
to you, with receipts on both sides. This is the same thing as<br />
a cheque with a negative amount. Thus, &quot;negative cheques&quot; can be<br />
used as invoices. (Already operational.)<br />
<br />
Assorted:<br />
<br />
Many of the C Standard Library includes were replaced with their<br />
C++ standard library versions.<br />
<br />
Other cleanups were made including some fixes to OTString (which<br />
used to have some large stack-allocations) as well as a bug fix<br />
in the socket code for the server / test client.<br />
<br />
The client cert expired, so I re-created all the certs. If you have<br />
any problem with your own, just install the new version to fix it.<br />
</pre><br />
// ---------------------------------------------------------------------<br />
<br />
0.2 --- Major Release! ALL NEW:<br />
<br />
<pre> JNI Interface (High-level Java API)<br />
<br />
High-level C++ Interface<br />
<br />
Spent Token Database is fully operational!<br />
<br />
Mints and Tokens now support Expiration AND Series. <br />
<br />
New Financial Instruments: Cheques and Vouchers.<br />
<br />
Reserve accounts are now working to store the backing funds<br />
for cash withdrawals and vouchers (cashier's cheques.)<br />
<br />
Transaction numbers are fully working now.<br />
<br />
Nym files are now signed (to prevent tampering.)<br />
<br />
Hardcoding of paths was fixed, using config files and<br />
command-line arguments now, so you can use the software <br />
without having to change the code.<br />
<br />
Path separators were improved to support Windows-style paths<br />
(though I haven't tried to actually build on Windows.)<br />
<br />
Numerous bug fixes. Including a big one: discarding<br />
token signature after unblinding.</pre><br />
// ---------------------------------------------------------------------<br />
<br />
0.11 --- Added LINUX support...<br />
<br />
<pre> Added Makefiles, and a few fixes related to Linux. <br />
<br />
OT now runs on TWO platforms: LINUX and Mac OS X.</pre><br />
// ---------------------------------------------------------------------<br />
<br />
0.1 --- The original goal was just proof-of-concept. There are many TODOs listed on the project page, as well as throughout the code. But it all works!!!<br />
<br />
A WARNING: This software is brand-spanking-new. The project has not yet been audited for security or tested for any extended period of time. Thus far, it must be considered as for experimental purposes only.<br />
<br />
<pre> --- There are still a few values that are hardcoded (in the client<br />
and the server), unfortunately, but it's all documented and I<br />
have everything set up already to run, so you don't have to<br />
mess with them. This will be fixed next release.</pre><br />
<br />
-----<br />
<br />
The server expects its OWN cert to be in the transaction/certs folder. The filename should be the server_user_ID from notaryServer.xml (I HAVE ALREADY PLACED IT THERE.)<br />
<br />
This is the file that includes the server's public AND private key.<br />
<br />
<br />
-----</div>Cryptomanhttp://opentransactions.org/wiki/index.php?title=Business_Cases&diff=102Business Cases2013-06-12T13:01:32Z<p>Cryptoman: Created page with "1. Operate a transaction server (running Open Transactions) in return for transaction fees. These can be earned anonymously, and thus the server has the option to run anonymou..."</p>
<hr />
<div>1. Operate a transaction server (running Open Transactions) in return for transaction fees. These can be earned anonymously, and thus the server has the option to run anonymously (on Tor or I2P, etc.)<br />
<br />
2. Operate an anonymous remailer, SERVICES PAID FOR IN DIGITAL CASH. Run it on Tor if you want.<br />
<br />
3. Operate a Nym server, services paid for in digital cash. <br />
<br />
4. Operate a Tor outproxy, services paid for in digital cash. Finally these sorts of services can be offered for profit, instead of relying on hobbyists and enthusiasts!<br />
<br />
5. Integrated with an anonymous network, Open Transactions solves problems of resource allocation. College kids will leave their computers running all day while they're in class, so that anonymous file-sharing can occur through their computer while they're away (collecting digital cash postage in return.) When they get home, the postage is theirs to keep -- or they can use it to pay for their own downloads. Voila! '''Anonymous networks can now be drastically sped-up through the anonymous contribution of resources.''' If you don't want to contribute computing resources, that's fine: just pay for those resources with anonymous digital cash instead, and the network will provide you those resources from someone else.<br />
Relevant:<br />
http://cap-lore.com/Economics/DSR/SilkSec.html<br />
<br />
6. The above (5) is true for MESH NETWORKS as well. Imagine Mesh routers popping up like mushrooms, the same way that ATM machines pop up today. Instead of paying your ISP for network resources (with a credit card), rather, pay your PEERS for network resources using digital cash (backed in Bitcoin...)<br />
<br />
7. Issue a digital gold-based currency (whether or not you actually run the server itself, which could be run by another entity) and earn transaction fees (if you operate it yourself) or issuer fees from the server operator (if someone else operates it.) These fees can be earned anonymously and untraceably. (Make sure to follow the laws in your jurisdiction.)<br />
<br />
8. If you already run businesses that value privacy, such as porn or gaming, issue a currency so that you can offer anonymity to your customers, thus making you more competitive in your own market.<br />
<br />
9. Or partner with someone else who issues the currency, in order to keep the two businesses entirely separate.<br />
<br />
10. Write a Wallet software that is also a file-sharing client, that allows users to pay for faster anonymous resources using digital postage. The wallet also contains an anonymous network node internally, so it has the capability to collect postage as well. If the Wallet software is unregistered, then the postage is sent home to the software company. Also, expired cash reverts to the software company. But once the wallet is registered (with a payment to the software company) then postage is retained by the user and expiring cash is exchanged for the user. The wallet software itself can be distributed for free. '''This constitutes a great example for the next generation of file-sharing integrated with digital cash.'''<br />
<br />
11. Darknet hosting. Tahoe might be adaptable to this: http://tahoe-lafs.org/trac/tahoe-lafs<br />
<br />
<br />
ALSO:<br />
<br />
* The software could be licensed to a legitimate bank. In fact, this has actually happened once before, if you Google the history of DigiCash and Mark Twain bank. (I think the software has better potential uses.)<br />
<br />
* The software could be used for horse racing or concert tickets.<br />
<br />
* It could be used for payments on toll roads, since many countries have strict privacy laws.<br />
<br />
* It could be used for video games. StarCraft II could use this software to track and control their star credits. Warcraft 2 could use this software to track and secure their warcraft gold. Etc.<br />
<br />
* Anonymous donations and tips online.<br />
<br />
* Secure, online transactions for community currencies.<br />
<br />
* Secure system for issuing other online currencies such as Bitcoin. (Enables you to write cheques in Bitcoins, withdraw untraceable cash in Bitcoins, get cashier's cheques in Bitcoins, etc.)<br />
<br />
* Secure and private financial transactions made possible even in countries with oppressive financial laws or unstable currencies...</div>Cryptomanhttp://opentransactions.org/wiki/index.php?title=Components_and_GNU_Licensing&diff=101Components and GNU Licensing2013-06-12T12:58:37Z<p>Cryptoman: Created page with "''Open Transactions'' is quickly turning into a family of components: <br>NAME: '''Xml-OTC'''..........— A ''file format''................'''LICENSE''': GNU Free Documentat..."</p>
<hr />
<div>''Open Transactions'' is quickly turning into a family of components:<br />
<br />
<br>NAME: '''Xml-OTC'''..........— A ''file format''................'''LICENSE''': GNU Free Documentation License ? Unlicense? RFC? <br />
<br>NAME: '''Xml-OTX'''..........— A ''messaging protocol''...'''LICENSE''': GNU Free Documentation License ? Unlicense? RFC? <br />
<br>NAME: '''OTTP'''...............— A ''URI format''...............'''LICENSE''': GNU Free Documentation License ? Unlicense? RFC? <br />
<br>NAME: '''OTLib'''..............— A ''class library''..............'''LICENSE''': LAGPLv3<br />
<br>NAME: '''OT-API'''.............— A ''Client API''................'''LICENSE''': LAGPLv3 <br />
<br>NAME: '''OT-Server'''........— A ''Server Application''......'''LICENSE''': AGPLv3 <br />
<br>NAME: '''testwallet'''........— A ''command-line client''....'''LICENSE''': LAGPLv3 <br />
<br>NAME: '''Moneychanger'''.....— A Java ''Client App''..........'''LICENSE''': GPLv3<br />
<br />
<br />
-----<br />
<br />
-- '''[[Messaging|Xml-OTX]]''', which describes the internal OTMessage format (a russian-doll metaphor of nested, signed contracts) and '''[[Sample Currency Contract|Xml-OTC]]''', which describes the basic file format it is based on, will be fully illuminated in as-yet-unwritten RFCs (I guess.)<br />
<br />
-- '''[[List of Classes|OTLib]]''' is the core foundation library of OT's C++ classes, and comprises the bulk of the code. (Though it doesn’t include any transport code, server code, or client code.) Classes such as OTToken, OTMint, OTCheque, OTMessage, OTIdentifier, etc can be found here.<br />
<br />
-- The '''[[API|OT-API]]''' implements the [[Use Cases|client side of the Xml-OTX protocol]]. '''The OT API is the high-level interface that most developers will actually use.''' OT also includes interfaces for Java, Ruby, Python, Php5, Perl5, LISP, C, C++, etc.<br />
<br />
-- The '''[[OTTP URI Format]]''' (incomplete) Would enable Open Transactions links to be added to HTML and other hyperlinked media. (Open Transactions requires client-side processing and storage, for verifying receipts, withdrawing cash, signing cheques, etc.) The use of OTTP URIs would allow web developers to link to OT resources, which could then be processed on the client side with the user's approval (and via the user's GUI.)<br />
<br />
-- The '''[[OT Server]]''' (transaction.exe) is '''a software implementation of the server side''' of the Xml-OTX protocol.<br />
<br />
-- The '''[[Test Wallet commands|testwallet]]''' is a command-line test program — a software implementation of the client side of the Xml-OTX protocol.<br />
<br />
-- The '''[[TestGUI]]''' is now called [[Moneychanger]], and it's '''a client GUI that operates via the OT-API (in Java)'''.<br />
<br />
<br />
-----<br />
<br />
'''Licenses'''<br />
<br />
'''GPLv3: You are required to open-source your code if it links to this OT code, but only if you are distributing binaries of your own code.''' If you are instead running your code on your website only (so-called “software as a service”), and you are not distributing binaries, then you do not have to open-source your own code in order to link to this OT code.<br />
<br />
'''LGPLv3''': Whether you are distributing binaries, or “software as a service,” either way, you may use this library without having to open-source your code. However, '''if you are distributing binaries''', and if you make any improvements to the OT library itself, then you must make those improvements available ('''your own application code may remain private, but improvements to OT must be shared'''.)<br />
<br />
'''AGPLv3''': Whether you are distributing binaries, or even if you are only using this OT code in your website — so-called “software as a service” — either way, '''your own code that links to OT must be open-source as well'''. (Otherwise contact the developer for an alternate license.)<br />
<br />
'''LAGPLv3''': Whether you are distributing binaries that link to the OT-API, or whether you are using the OT-API in your website — so-called “software as a service” — either way, '''your own code may remain private, but any improvements to the OT library or API code itself must be made available open-source'''. <br />
<br>Just as the LGPL is written as a set of additional permissions on top of the GPL, so in like manner, the ''LAGPL'' is written as a set of additional permissions on top of ''AGPL''. The [http://mo.morsi.org/blog/node/270 LAGPL] license starts with the AGPL (closing the software-as-a-service loophole) and then it grants the additional LGPL permissions, so that developers can use the OT-API even in their proprietary code.<br />
<br />
RECENT RELAXATION IN LICENSING: Open-Transactions recently relaxed the OTLib and OT-API licensing from AGPL to LAGPL.<br />
<br />
<br />
-----<br />
<br />
Links: <br />
<br>[http://www.fsf.org/ Free Software Movement].<br />
<br />
The GNU license creates 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.) The license creates 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.<br />
<br />
'''My rationale for this below, from David Wheeler's blog:''' ([http://www.dwheeler.com/blog/2006/09/01/#gpl-bsd])<br />
<br />
'''GPL, BSD, and NetBSD - why the GPL rocketed Linux to success'''<br />
<br />
<br>Charles M. Hannum (one of the 4 originators of NetBSD) has posted a sad article about serious problems in the NetBSD project, saying &quot;the NetBSD Project has stagnated to the point of irrelevance.&quot; You can see the article or an LWN article about it.<br />
<br />
<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 (&quot;Linux&quot;) 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 />
<br />
<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 (&quot;BSD-style&quot;) 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, &quot;Let's start a company based on this BSD code!&quot; 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 />
<br />
<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 &quot;business friendly&quot;, but if you look at actual practice, that argument doesn't wash. The GPL has created a &quot;safe&quot; 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 &quot;business-friendly&quot;.<br />
<br />
<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 />
<br />
<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 &quot;better&quot; 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 />
<br />
<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 &quot;bad&quot; licenses, or that the GPL is always the &quot;best&quot; license. But others, like Linux, gcc, etc., have done better with copylefting / &quot;protective&quot; 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 &quot;BSD license bad&quot; - 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 />
<br />
<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 />
<br />
<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 />
<br />
<br>If your goal is to have a useful program that stays useful long-term, then a protective (&quot;copylefting&quot;) 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 />
<br />
<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 &quot;Prisoner's Dilemma&quot;. 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 />
<br />
<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.</div>Cryptomanhttp://opentransactions.org/wiki/index.php?title=Otserver&diff=97Otserver2013-06-12T02:16:47Z<p>Cryptoman: </p>
<hr />
<div>After you <code>make install</code>, the OT Server will be named <code>otserver</code> and most likely will be located in <code>/usr/local/bin</code><br />
<br />
You can probably run it simply by typing: <code>otserver</code><br />
<br />
If you run it with blank data, it will walk you through the process of creating a fresh server. You will want to make use of the sample contracts in the sample-data folder for this process.<br />
<br />
You can also copy sample data from the sample data folder, which includes pre-created server and client data, allowing you to instantly get OT up and running without having to create anything. Just copy the sample data folders for server_data and client_data into <code>~/.ot/server_data</code> and <code>~/.ot/client_data</code><br />
<br />
<br />
-----<br />
<br />
<code>make install</code> creates the <code>~/.ot</code> folder, including the server's folder: <code>~/.ot/server_data</code> (That is where the otserver will look, by default, to load its data.<br />
<br />
The main datafile is: <code>~/.ot/server_data/notaryServer.xml</code><br />
<br />
When you first start playing with OT, be sure to keep an eye on the server output while you are running your client, so you can see what is happening on the server side.<br />
<br />
<br />
-----<br />
<br />
See the include/otserver/OTServer.h and src/otserver/OTServer.cpp files for the bulk of the server code.<br />
<br />
<br />
-----<br />
<br />
''See also:'' The [[TestGUI|OT Test GUI]] The [[opentxs|command line test wallet]] The [[API|OT API]] and [[Use Cases]].</div>Cryptomanhttp://opentransactions.org/wiki/index.php?title=FAQ&diff=96FAQ2013-06-12T02:07:47Z<p>Cryptoman: Created page with "'''DO YOU HAVE A GUI YET?''' Yes... a test GUI in Java. It's called [https://github.com/FellowTraveler/Moneychanger Moneychanger]. (It's your job to write the real GUIs... A..."</p>
<hr />
<div>'''DO YOU HAVE A GUI YET?'''<br />
<br />
Yes... a test GUI in Java. It's called [https://github.com/FellowTraveler/Moneychanger Moneychanger].<br />
<br />
(It's your job to write the real GUIs... Android, iPhone, Chrome plugin, QT, etc.)<br />
<br />
<br />
-----<br />
<br />
'''UNTRACEABLE DIGITAL CASH? ... FOR REAL?'''<br />
<br />
<blockquote>Is this the '''real''' stuff? With blinded tokens? As in, invented by David Chaum?<br />
</blockquote><br />
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].<br />
<br />
Here's an intro [http://www.cs.bham.ac.uk/~mdr/teaching/modules06/netsec/lectures/DigitalCash.html article on digital cash].<br />
<br />
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.<br />
<br />
<hr /><br />
<br />
<br />
<br>'''EXPLAIN THE DIFFERENCE BETWEEN &quot;NUMBERED ACCOUNTS&quot; and &quot;UNTRACEABLE&quot; and &quot;ANONYMOUS&quot;'''<br />
<br />
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 &quot;Nym&quot;) 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])<br />
<br />
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 &quot;Chaumian blinding&quot;.)<br />
<br />
''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 '''&quot;cash-only&quot;.'''<br />
<br />
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.<br />
<br />
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.)<br />
<br />
<hr /><br />
<br />
<br />
<br>'''WHY DO YOU USE THE WORD &quot;CASH&quot; -- ISN'T THAT CONFUSING?'''<br />
<br />
Cash is the most accurate analogy.<br />
<br />
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.<br />
<br />
The other digital financial instruments are much the same as their paper equivalents:<br />
<br />
* account '''transfer''' (a PGP-signed message, given directly to the bank, transferring funds to some other account),<br />
* digital '''cheque''' (a signed message, given to the recipient, authorizing bank to transfer funds when presented),<br />
* digital '''vouchers''' (like a cashier’s cheque. Funds are transferred to bank, who then issues a cheque. Bank becomes payer.),<br />
* digital '''cash''' (Like a real cash withdrawal. Funds are transferred to bank, who then issues blinded, untraceable, bearer certificates), <br />
<br>'''New: 2-way trades and re-occurring billing''' are also now functional!<br />
<br />
'''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 &quot;their full faith and credit&quot; or whatever they claim that their currency is backed with.)<br />
<br />
'''''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)<br />
<br />
''In Open Transactions, anyone can issue a currency. But the '''users''' still decide '''what they want to trade''' and '''who they want to trust.'''''<br />
<br />
<br />
<hr /><br />
<br />
<br />
<br>'''So I can just give myself 1000000000000 Weaselbucks and then I can pay you in weaselbucks?'''<br />
<br>''' Maybe I just don't get it.'''<br />
<br />
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 &quot;weaselbucks.&quot;'''<br />
<br />
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.<br />
<br />
Imagine an eco-system with various different entities...<br />
<br />
Open Transactions is the software for the '''transaction server.'''<br />
<br />
Anyone choosing to act as an '''issuer''' could connect to such a transaction server and issue a currency. (Or even operate his own server.)<br />
<br />
MOREOVER, there will be a ''multiplicity'' of issuers ''and'' transaction servers, all operating in a ''diversity'' of jurisdictions. This is like the concept of &quot;Federated Software&quot; such as that proposed by the Diaspora project.<br />
<br />
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 &quot;coin of the realm.&quot; 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.)<br />
<br />
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.<br />
<br />
<hr /><br />
<br />
<br />
<br>'''HOW DOES THE CASH WORK?'''<br />
<br />
If you Google about &quot;untraceable digital cash&quot; you will find plenty of articles explaining it, including a good article from Wired.<br />
<br />
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.)<br />
<br />
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.)<br />
<br />
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.<br />
<br />
You can see the full progression of the blinding code if you look here:<br />
<br />
<ol start="1" style="list-style-type: decimal;"><br />
<li>WITHDRAW (CREATE) PROTOTOKENS <br />
<br>OTClient.cpp: <br />
<br>else if (OTClient::notarizeWithdrawal == requestedCommand) // NOTARIZE WITHDRAWAL<br />
<li>SIGN PROTOTOKENS <br />
<br>OTServer.cpp:<br />
<br />void OTServer::NotarizeWithdrawal(OTPseudonym &amp; theNym, OTAccount theAccount, OTTransaction &amp; tranIn, OTTransaction &amp; tranOut)<br />
<li>UNBLIND TOKENS <br />
<br>OTClient.cpp:<br />
<br />void OTClient::ProcessWithdrawalResponse(OTTransaction &amp; theTransaction, OTServerConnection &amp; theConnection, OTMessage &amp; theReply)<br />
<br />
[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...]<br />
<br />
<li>DEPOSIT TOKENS (IN PURSE) <br />
<br>OTClient.cpp: <br />
<br>else if (OTClient::notarizePurse == requestedCommand) // NOTARIZE PURSE (deposit)<br />
<li>VERIFY TOKENS <br />
<br>OTServer.cpp:<br />
<br />void OTServer::NotarizeDeposit(OTPseudonym &amp; theNym, OTAccount &amp; theAccount, OTTransaction &amp; tranIn, OTTransaction &amp; tranOut)</li></ol><br />
<br />
'''Also I suggest reading the OTToken and OTMint classes to see the actual Lucre calls being made.'''<br />
<br />
Update: The Spent Token Database is now operational as well!<br />
<br />
<br />
<hr /><br />
<br />
<br />
<br>'''HOW DOES THIS COMPARE TO BITCOIN?'''<br />
<br />
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.<br />
<br />
'''Bitcoin gives OT:''' a universal &quot;glue&quot; between servers, a network of existing exchangers, and a publicly-auditable, reserve currency that cannot be confiscated or shut down.<br />
<br />
'''OT gives Bitcoin:''' Untraceable 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''.)<br />
<br />
In more detail:<br />
<br />
Bitcoin Pros: <br />
* Bitcoin cannot be confiscated since there are no real-world assets backing it. <br />
* Bitcoin cannot be shut down since there is no central server. (Unlike Napster...) <br />
* 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''.) <br />
* 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!<br />
<br />
Bitcoin Cons: <br />
* 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.) <br />
* Bitcoin is not untraceable by itself. (Due to being publicly auditable.)<br />
* Bitcoin does not feature immediate settlement. (It takes ''time'' for several blocks before your transaction is secure. Ten minutes to an hour.)<br />
<br />
Opportunities: Since Bitcoin is publicly auditable, use it as the backing reserves for a currency issued on OT.<br />
<br />
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.<br />
<br />
'''I would also like to point out that Bitcoin will probably serve as a &quot;glue&quot; 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.'''<br />
<br />
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]].)<br />
<br />
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.<br />
<br />
--<br />
<br />
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.<br />
<br />
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.<br />
<br />
<hr /><br />
<br />
<br />
<br>'''IS OT &quot;DISTRIBUTED&quot; or &quot;FEDERATED&quot; or &quot;P2P&quot; or &quot;CLIENT/SERVER&quot; ...OR WHAT?'''<br />
<br />
OT, at a basic level, ''is'' client/server. (There must be a signer in order to have untraceable cash.) Contrast this with fully distributed digital commodities, like Bitcoin, which rely on block chains and therefore cannot be untraceable.<br />
<br />
'''However, OT will end up with P2P Clients and Federated Servers. Here's why:'''<br />
<br />
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.)<br />
<br />
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.<br />
<br />
'''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'''.<br />
<br />
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.<br />
<br />
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 &quot;flow&quot; 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 &quot;6 degrees of separation&quot; between us through our friends, and converts the currency as it ripples.<br />
<br />
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.)<br />
<br />
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.<br />
<br />
'''I would also like to point out that Bitcoin will probably serve as a &quot;glue&quot; 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.'''<br />
<br />
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.<br />
<br />
'''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.<br />
<br />
'''The wallets will also need to be p2p due to the &quot;Ripple&quot; possibilities outlined above. Users will automatically earn percentage cuts for money flows through their wallets, and centralized sources will no longer be necessary for &quot;wire transfers&quot; as they were in the 20th Century'''.<br />
<br />
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'''.<br />
<br />
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.)'''<br />
<br />
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 &quot;pecunix-backed&quot; currency on an OT server(s) somewhere, if they wanted to--and it is up to the market to DECIDE WHO THEY TRUST.<br />
<br />
'''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.<br />
<br />
Another example of risk distribution: '''A nice wallet software can be designed to automatically distribute funds across MULTIPLE SERVERS. The little &quot;pile of gold&quot; 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.<br />
<br />
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.<br />
<br />
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.)<br />
<br />
<br />
<hr /><br />
<br />
<br>'''HOW DOES THIS COMPARE TO E-GOLD OR PECUNIX?'''<br />
<br />
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.<br />
<br />
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.)<br />
<br />
Open Transactions supports account transfer, ''and'' digital cheques, ''and'' digital cash.<br />
<br />
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].<br />
<br />
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.)<br />
<br />
<hr /><br />
<br />
<br />
<br>'''HOW DOES ''OPEN TRANSACTIONS'' COMPARE TO ''LOOM''?'''<br />
<br />
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].<br />
<br />
<br />
<hr /><br />
<br />
<br />
<br>'''HOW DOES ''OPEN TRANSACTIONS'' COMPARE TO ''RIPPLE''?'''<br />
<br />
[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 &quot;flow&quot; through users so that two otherwise unrelated parties, using two otherwise unrelated payment systems, can still send payments to each other, via a &quot;six degrees of separation&quot; through a social network of mutual friends. (Sort of like Hawala.)<br />
<br />
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 &quot;banking system transfer&quot; entirely.<br />
<br />
With users incorporating such software, it will no longer even be necessary to add &quot;server transfer&quot; 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.<br />
<br />
<hr /><br />
<br />
'''HOW DOES ''OPEN TRANSACTIONS'' COMPARE TO TRULEDGER (formerly ''TRUBANC'')?'''<br />
<br />
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].<br />
<br />
When using the ACCOUNT TRANSFER instrument (instead of cheques, or cash) these are the signatures that are received by all parties:<br />
<br />
ALICE <br />
<br>- Alice gets the server's signature on her transfer request (whether it is accepted or rejected, she still gets a signed receipt.) <br />
<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.<br />
<br />
BOB <br />
<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 />
<br>- Then, when he accepts her transfer, he will get a signed receipt from the server when his balance is updated. <br />
<br>- He will also have a signed balance agreement from the server at this time.<br />
<br />
THE SERVER <br />
<br>- The server gets Alice's signature on the transfer request. <br />
<br>- The server gets Bob's signature accepting Alice's transfer. <br />
<br>- The server gets Alice's signature acknowledging Bob's acceptance (when she removes his accept notice from her inbox.) <br />
<br>- The server will also have Alice AND Bob's agreement on both of their balances, allowing the server to destroy any other records.<br />
<br />
Not to complicate things, but on each of the above (on each balance agreement), there is also: <br />
<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 />
<br>- ...and a similar list of pending outgoings (in the outbox.)<br />
<br />
You can see why we call it &quot;[[Triple-Signed Receipts]]&quot; for account transfer!<br />
<br />
For more info, check out Bill St. Clair's document: [http://truledger.com/doc/plain-english.html]<br />
<br />
<hr /><br />
<br />
<br />
<br>''HOW DOES ''OPEN TRANSACTIONS'' COMPARE TO ''RICARDO'' BY SYSTEMICS?''<br />
<br />
[http://www.financialcryptography.com/ Ian Grigg] has commented that Open Transactions is along the same lines as Ricardo.<br />
<br />
Open Transactions has definitely adopted the '''[http://iang.org/papers/ricardian_contract.html Ricardian Contract]''' form, which is one of his innovations.<br />
<br />
<br />
<hr /><br />
<br />
<br />
<br>'''HOW DOES ''OPEN TRANSACTIONS'' COMPARE TO ''eCache''?'''<br />
<br />
'''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.)<br />
<br />
As far as I know, eCache supports a '''&quot;Tor / HTTPS, Cash-Only Interface&quot; like the one described in this FAQ,''' and their users exchange bearer tokens through it, '''backed in gold''' and other precious metals.<br />
<br />
(What actual software they use over at eCache, and their math implementation, I have no idea -- I haven't seen their code.)<br />
<br />
<hr /><br />
<br />
<br />
<br>'''WHAT IF I WANT TO EXCHANGE TOKENS, BUT WITHOUT CREATING AN ACCOUNT?'''<br />
<br />
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 &quot;account&quot;.''' (Notice that it must be the server operator who provides this interface, otherwise you now have to trust the interface provider.)<br />
<br />
Keep in mind, that an &quot;account&quot; 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 &quot;accounts&quot; 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...<br />
<br />
'''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.<br />
<br />
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.<br />
<br />
<br />
<hr /><br />
<br />
<br />
<br>'''AN INVOICE IS JUST A NEGATIVE CHEQUE? PLEASE EXPLAIN.'''<br />
<br />
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.<br />
<br />
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.)<br />
<br />
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.)<br />
<br />
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...)<br />
<br />
<br />
<hr /><br />
<br />
<br />
<br>'''THE TRANSPORT LAYER...'''<br />
<br />
-- '''The Open Transactions library itself is entirely agnostic to transport!''' All messages serialize to a string and you can transport them however you wish.<br />
<br />
-- The Server, API, and Test Client currently use the ZeroMQ library for all transport.<br />
<br />
-- This code is easy to swap out, due to its localization to a single callback.<br />
<br />
-- The library does all the heavy lifting of generating and [[Messaging|processing the OTMessages]].<br />
<br />
-- 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 &quot;Withdraw Cash&quot; or &quot;Write Cheque.&quot;<br />
<br />
<br />
<hr /><br />
<br />
<br />
<br>'''WHAT DATABASE DOES OPEN TRANSACTIONS USE?'''<br />
<br />
* Internally, the software uses signed XML contracts nearly exclusively, and is agnostic to where and how they are stored.<br />
* '''All of the classes serialize to a STRING'''<br />
* '''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 &quot;OT local storage&quot;.<br />
* 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.)<br />
* 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.'''<br />
* OT Storage paths are usable as keys or as filenames. So &quot;nyms/a6b123874ef2v1cc3.nym&quot; could be the key in a table instead of a filename on a filesystem.<br />
* I assume this will eventually move towards some distributed db or &quot;data haven&quot;. 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.)<br />
<br />
Feedback? Anyone?<br />
<br />
<br />
<hr /><br />
<br />
<br />
<br>'''WHAT ABOUT CHAUM'S TRICK FOR IDENTIFYING THE DOUBLE-SPENDER?'''<br />
<br />
<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...)<br />
</blockquote><br />
The answer is '''NO'''.<br />
<br />
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.)''<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
So what could be done?<br />
<br />
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.)<br />
<br />
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.<br />
<br />
Similarly, if you are somewhere else on the internet, then we are probably communicating through a &quot;cash streaming protocol.&quot; 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.<br />
<br />
<br />
<hr /><br />
<br />
<br />
<br>'''LINUX?'''<br />
<br />
GOOD NEWS: Open Transactions is now available for Linux! Make sure you download the latest version of the code.<br />
<br />
<br />
<hr /><br />
<br />
<br>'''FreeBSD?'''<br />
<br />
GOOD NEWS: Open Transactions is now available for FreeBSD!<br />
<br />
<hr /><br />
<br />
<br>'''WINDOWS?'''<br />
<br />
GOOD NEWS: Open Transactions is now available for Windows!<br />
<br />
<hr /><br />
<br />
<br />
<br>'''ANDROID?'''<br />
<br />
GOOD NEWS: Open Transactions is now available for Android!<br />
<br />
All supported platforms come with easy makefiles, project files, and instructions.<br />
<br />
<br />
<hr /><br />
<br />
<br />
<br>'''RUBY / PYTHON / PHP / Java ?'''<br />
<br />
Open Transactions now comes with Native APIs for:<br />
<br />
Java, Ruby, Python, Perl, PHP, C, C++, Obj-C, C#, Tcl, and Lisp.<br />
<br />
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 untraceable properties of the digital cash.)<br />
<br />
<br>'''How about portability?'''<br />
<br />
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.)<br />
<br />
<br />
<hr /><br />
<br />
<br />
<br>'''CAN YOU CONVERT THE LIBRARY TO ''C'' ?'''<br />
<br />
<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).<br />
<br />
My questions are: <br />
<br>1) would you consider turning main components of it into C? <br />
<br>2) would you assist someone attempting to do the same?<br />
</blockquote><br />
Thank you for your kind words.<br />
<br />
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.)<br />
<br />
However, it shouldn't be too difficult to convert...<br />
<br />
# The library doesn't use any exception handling -- it's all return values.<br />
# I would convert the class members to a struct.<br />
# I would convert the class methods to normal functions, with an additional &quot;this&quot; pointer passed in (for the struct)<br />
# Have to make sure to call the constructor / destructor by hand whenever a struct is created or deleted.<br />
# 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.<br />
<br />
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.<br />
<br />
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.)<br />
<br />
So Lucre itself would also need to be converted, whether by hand or using a tool.<br />
<br />
NOTE: There is now a C function [[API]] that comes with Open Transactions.<br />
<br />
<br />
<hr /><br />
<br />
<br />
<br>'''WHAT ABOUT CHAUM'S CUT-AND-CHOOSE PROTOCOL?'''<br />
<br />
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 &quot;here.&quot;:http://wiki.github.com/FellowTraveler/Open-Transactions/lucre-and-denominations<br />
<br />
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?<br />
<br />
<br />
<hr /><br />
<br />
<br />
<br>'''WHAT ABOUT BRANDS' PROTOCOL? WHAT ABOUT XYZ PROTOCOL?'''<br />
<br />
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.)<br />
<br />
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.<br />
<br />
<br />
<hr /><br />
<br />
<br />
<br>'''HOW DO I VIEW THE BASE64-ENCODED DATA THAT APPEARS IN THE FILES AND MESSAGES?'''<br />
<br />
The data is always either encrypted, or just base64-encoded.<br />
<br />
If the data is only base64-encoded, then type &quot;decode&quot; and paste the data. Now hit enter and you will see the decoded contents.<br />
<br />
But if the data is encrypted, it will probably start with 3 A's (&quot;AAA&quot;). Type &quot;decrypt&quot; 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 &quot;load&quot; you'll be fine.)<br />
<br />
<br />
<hr /><br />
<br />
<br />
<br>'''WHY IS CASH WITHDRAWAL FAILING?'''<br />
<br />
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.)<br />
<br />
Thus, there is a separate utility called &quot;createmint.exe&quot; 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<br />
<br />
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.<br />
<br />
The Moneychanger GUI is smart enough to check the expiration date on any Mint, and download the latest version if it's expired.<br />
<br />
(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!)<br />
<br />
<br />
<hr /><br />
<br />
<br />
<br>'''WHAT IF I WANT TO CREATE MY OWN CONTRACTS?'''<br />
<br />
Look in the Open-Transactions/sample-contracts folder: The .otc files ARE SIGNED. The .xml files are NOT signed.<br />
<br />
(Otherwise they are identical.)<br />
<br />
The public key of the issuer must be INSIDE the contract. (In the sample contracts, it's the first key that appears.)<br />
<br />
The contract must be SIGNED with THAT SAME KEY.<br />
<br />
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 &quot;contract signing page&quot; will be added to Moneychanger, but I haven't gotten around to it yet.<br />
<br />
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.)<br />
<br />
The GUI will make this easier in the future by stripping whitespace as appropriate before generating the ID.<br />
<br />
<hr /><br />
<br />
<br>'''HOW CAN THE SERVER OPERATOR MAKE MONEY?'''<br />
<br />
* Transaction fees can easily be added, since transactions consist already of multiple items in a list.<br />
* He can also make money from expired vouchers and expired cash, which both revert to the bank.<br />
* He could issue a fractional reserve contract and make money from investments...<br />
* The OT server also supports usage credits (charging by API call.)<br />
* See the [[Business Cases]] page for more on this...<br />
<br />
<br />
<hr /><br />
<br />
<br />
<br>'''LICENSE ?'''<br />
<br />
The various components of Open Transactions are released under the GPLv3, AGPLv3, and LAGPLv3 licenses (depending on which component.) Developers: If you are only using the OT-API, then you are under the LAGPL, ''not'' the AGPL, '''meaning you do not have to release your own source code if you don't want to'''. [[Components|See this article for more details.]]<br />
<br />
<br>NAME: '''Xml-OTC'''..........— A ''file<br />
format''................'''LICENSE''': GNU Free Documentation License ? Unlicense? RFC? <br />
<br>NAME: ''Xml-OTX''..........— A ''messaging protocol''...''LICENSE'': GNU<br />
Free Documentation License ? Unlicense? RFC? <br />
<br>NAME: ''OTTP''...............— A ''URI format''...............''LICENSE'':<br />
GNU Free Documentation License ? Unlicense? RFC? <br />
<br>NAME: ''OTLib''..............— A ''class<br />
library''..............''LICENSE'': LAGPLv3<br />
<br />NAME: ''OT-API''.............— A ''Client<br />
API''................''LICENSE'': LAGPLv3 <br />
<br>NAME: ''OT-Server''........— A ''Server Application''......''LICENSE'': AGPLv3 <br />
<br>NAME: ''testwallet''........— A ''command-line client''....''LICENSE'': LAGPLv3 <br />
<br>NAME: ''OT-TestGUI''......— A Java ''Client App''.........''LICENSE'': GPLv3</div>Cryptomanhttp://opentransactions.org/wiki/index.php?title=CENTRALIZED&diff=95CENTRALIZED2013-06-11T21:41:15Z<p>Cryptoman: </p>
<hr />
<div>''The vision is not of a central server you must trust.''<br />
<br>''Rather, the vision is of federated servers you don’t have to trust.''<br />
<br />
My goal with Open-Transactions is for the servers to be able to run on anonymous networks. For this to work, that means '''the users must be able to trust the system, even if they do not trust the servers'''.<br />
<br />
We must have LOW-TRUST SERVERS--and that is what I have been working towards. The combination of low-trust technology with untraceable cash is what will make it possible to run OT servers on anonymous networks, at a profit.<br />
<br />
<br />
-----<br />
<br />
There are some big differences between Open-Transactions and the “typical centralized system”...<br />
<br />
# — A ''typical centralized system'' is '''fully-traceable'''. You are always under the watchful gaze of the “all-seeing eye”.<br />
<br />
But on OPEN-TRANSACTIONS, blind signatures are employed, providing '''untraceable digital cash'''.<br />
<br />
<br />
-----<br />
<br><br />
<ol start="2" style="list-style-type: decimal;"><br />
<li>— The '''typical centralized system''' stores a simple number as your “account balance.” '''The server could change your balance simply by changing that number''', and '''you must trust the server''' not to change your balance, or steal your money. (Ironically, this is the case on all the Bitcoin-related exchange sites today.)</li></ol><br />
<br />
'''But an OPEN-TRANSACTIONS server cannot forge any transaction, nor can it change your balance without your signature.''' Even a malicious server cannot do these things!<br />
<br />
How is this possible? Because your “account balance” on OT is whatever appears on your last receipt. And an OT server cannot sign any receipt unless you have first signed the initial request, since a full copy of that request must appear inside the receipt. Thus the server cannot falsify any receipt because the server cannot forge your signature on the request.<br />
<br />
Therefore the OT server can never sign any balance, or transaction, that you have not signed first!<br />
<br />
<br />
-----<br />
<br><br />
<ol start="3" style="list-style-type: decimal;"><br />
<li>— A ''typical centralized system'' would have the ability to '''abscond with your Bitcoins''' or gold.</li></ol><br />
<br />
'''But an OPEN-TRANSACTIONS server cannot disappear with the reserves!'''<br />
<br />
Why not? Because it doesn’t have any. (For Bitcoin, this will be done using [https://gist.github.com/39158239e36f6af69d6f voting pools] on the blockchain, a feature which has not yet been coded. Scroll to the bottom of this page for a description of how it will work.)<br />
<br />
OT follows a philosophy of “separation of powers”. Meaning, the issuer and the transaction server are separate entities. If, for example, your currency is backed in gold, then it is the gold issuer you must trust, not the OT transaction server. ''Even if an OT transaction server disappears into the night, you still have your account (i.e. the last receipt) and you can still redeem it at your issuer or have it re-issued onto a new transaction server.''<br />
<br />
The same will soon be true with Bitcoin: I have been cooperating with certain Bitcoin developers on a ''new mechanism'' to allow users to bail their Bitcoins in-and-out of OT servers, ''without having to trust the server itself''. That is, even if the server tried to disappear with your Bitcoin, it would not be able to. The next generation of Bitcoin and OT will have this capability. (The new BTC protocol hasn’t been added to OT yet but is coming soon.) Woe to anyone building a Bitcoin site that doesn’t have this capability! …Because soon your OT-enabled competitors will eat your lunch.<br />
<br />
More on separation of powers: <br />
<br>— ''A single currency (such as “Pecunix gold grams” or “Liberty Reserve dollars”) might be issued on a dozen different transaction servers'' in different jurisdictions, with the same currency contract being used for all of them. One currency--many servers. <br />
<br>— ''Transaction servers can prove which currencies have been issued there'', by producing the issuer’s last receipt. (And the currency contract.) <br>— ''Issuers and transaction servers can both prove the total amount that has been issued'', also by producing the last receipt. <br />
<br>— ''The same currency might be distributed across a dozen different issuers, using basket currencies.'' (Basket currencies allow users to distribute the risk of a single currency across multiple trusted issuers.) <br />
<br>— ''The contents of a single “asset account” might be distributed across a dozen different transaction servers.'' (If this abstraction is coded into your client GUI, then what appears as a single account is actually spread across X number of servers.)<br />
<br />
<br />
-----<br />
<br><br />
<ol start="4" style="list-style-type: decimal;"><br />
<li>— Let’s concede that while OT can’t forge receipts against individual users, a malicious server could still use a dummy account to inflate the currency itself, without having to forge any of the individual users’ receipts, and without having to forge the issuer’s receipt.</li></ol><br />
<br />
This is true, but it would not escape the upcoming ''OT Audit Protocol!''<br />
<br />
Why not? Because counterfeit funds cannot be spent without flowing from an illicit account into the other accounts of the general population, where the total amount will show up on an audit and be compared against the amount on the issuer’s last receipt.<br />
<br />
As long as there is real-time auditing, OR as long as receipts are stored between audits (which could be daily) then '''the users, as above, can simply dump the untrusted server''' and redeem their receipts at the issuer. (This can all be automated.) Transaction servers, of course, would have a huge incentive not to pull this, since they already can’t get away with it, and since they would instantly lose their daily revenues from transaction fees.<br />
<br />
A similar solution is planned for Bitcoin-based accounts on OT, using the same new mechanism described in answer (3). (It also doesn’t hurt that Bitcoins are publicly-auditable, but our plans go beyond that.)<br />
<br />
FYI, the OT Audit protocol is designed but not yet coded.<br />
<br />
<br />
-----<br />
<br><br />
<ol start="5" style="list-style-type: decimal;"><br />
<li>— ''A typical centralized system is very vulnerable to hackers'', who make use of all manner of '''cross-site-scripting and SQL injection''' in order to '''gain access to your server account''' and do transactions you never authorized.</li></ol><br />
<br />
But on OPEN-TRANSACTIONS, hacking a user would entail gaining access to his private key--which is not stored on the server--as well as installing a keylogger on the user’s machine (in order to get his passphrase.) Furthermore, the hacker would have to do this for ''each individual user''. (The ultimate solution goes even further: store your private key on a crypto-card. People will actually start doing this once enough of them have been hacked.)<br />
<br />
'''By comparison, MtGox recently had hackers sell-off all of the users’ balances for pennies. This also had the effect of crashing the Bitcoin market and damaging the “bulletproof” reputation of Bitcoin.'''<br />
<br />
<br />
-----<br />
<br><br />
<ol start="6" style="list-style-type: decimal;"><br />
<li>— A ''typical centralized system'' is vulnerable to hackers obtaining a copy of their database, and subsequently distributing the users’ email addresses, hashed passwords, account balances, and usernames all over the Internet.</li></ol><br />
<br />
These same users are then subjected to an aftermath consisting of hacks on their Tradehill, Facebook, etc accounts, as well as the imposition of frustrating account-validation and password-changing procedures at all of those sites.<br />
<br />
'''But on OPEN-TRANSACTIONS, no passwords are stored on the server OR client side'''. Instead, public-key cryptography is used, and the server only responds to signed requests. Users will never have to go and change their Gmail password because of using OT-based systems.<br />
<br />
<br />
-----<br />
<br><br />
<ol start="7" style="list-style-type: decimal;"><br />
<li>— A ''typical centralized system'' must store all of its receipts, forever. This is because it cannot prove ''which instruments are authorized'', or ''which transactions have cleared'', without storing them all (in an ever-growing database.) That’s the only way it can prove its case in the event of any dispute. (If parties cannot &quot;prove their case&quot; in a dispute, then the system breaks down.)</li></ol><br />
<br />
But OPEN-TRANSACTIONS uses Triple-Signed-Receipts: '''Parties can prove '''which transactions have cleared''', and '''which instruments are authorized''', simply by keeping their '''''last signed receipt.'''''<br />
<br />
<br />
-----<br />
<br><br />
<ol start="8" style="list-style-type: decimal;"><br />
<li>— A ''typical centralized server'' (such as e-gold) can be pressured to produce transaction data, and made legally responsible to report it. Such data is also vulnerable to hackers (such as happened to MtGox.)</li></ol><br />
<br />
'''But on OPEN-TRANSACTIONS, users and transaction servers both have the choice to operate in “cash-only” mode, which is completely anonymous. The server cannot be pressured or hacked to reveal your account, if you don’t have one!'''<br />
<br />
The issuer is similarly safe, due to OT’s philosophy of “separation of powers.” Since he has outsourced the transaction processing to the transaction server, the issuer cannot be forced to produce any transaction data--he doesn’t have any!<br />
<br />
Note: the more often the issuer performs an audit, the more transaction data he has access to. Clearly in a real-time audit he DOES have access to all transaction data. Therefore the length of the auditing period will be shaped partially by legal considerations. In the case of Bitcoin, on the other hand, real-time auditing will usually be preferable. (Of course when those transactions involve cash, they are untraceable either way.)<br />
<br />
<br />
-----<br />
<br><br />
<ol start="9" style="list-style-type: decimal;"><br />
<li>— A ''typical centralized server'' requires a bailment process to exchange funds onto the server, and back off again.</li></ol><br />
<br />
'''Open-Transactions servers don't require any bailment process, since they don't store any reserves'''. Instead, the issuer chooses when to issue new units of any currency, and any bailment happens through the issuer directly. (Just like on Loom.)<br />
<br />
A similar, yet more p2p solution is coming soon for Bitcoin-backed currencies--this is the same new mechanism mentioned in (3).<br />
<br />
Additional options also coming soon:<br />
<br />
A user will soon be able to transfer to another user in return for a similar reciprocal transfer on an entirely different system (via '''Ripple'''), and even into a completely different currency, with the exchange being negotiated p2p by the Ripple protocol.<br />
<br />
In effect, this allows users to bail out of specific servers without having to “bail out” at all — instead merely sending an internal transfer to another user, who then pays them in a separate account via Ripple.<br />
<br />
Ripple client capabilities are being built into Moneychanger (OT Java client.) Since Moneychanger users will likely list different currency types in their wallets, it only makes sense to connect them all via Ripple. Especially since OT clients will be P2P anyway (they need to compare notes on public mint files for various OT servers.)<br />
<br />
'''This is where I see the true value of Ripple: Eliminating any need for server-to-server transfer, by allowing currency flows directly through the users.'''<br />
<br />
Open-Transactions also allows for users to transfer from one server to another through the issuer, since he already exists at both ends. (Therefore the user doesn’t have to “bail out” in-between.)<br />
<br />
'''Open-Transactions will also make use of Bitcoin as a “glue”, or “universal medium”, between OT servers.''' OT will always use a crypto-currency in this regard (whether Bitcoin or whatever else) since it is a unique solution to this problem.<br />
<br />
<br />
-----<br />
<br><br />
<ol start="10" style="list-style-type: decimal;"><br />
<li>— A ''typical centralized server'' only supports two financial instruments: ''account transfer'', and sometimes ''market trades''.</li></ol><br />
<br />
'''But OPEN-TRANSACTIONS currently supports cheques, invoices, vouchers, account transfer, receipts, market trades, payment plans, and untraceable digital cash.'''<br />
<br />
Many more instruments are coming soon to OT, including those with scriptable custom behaviors.<br />
<br />
<br />
-----<br />
<br><br />
<ol start="11" style="list-style-type: decimal;"><br />
<li>— A ''typical centralized system'' does not have '''contracts.'''</li></ol><br />
<br />
'''OPEN-TRANSACTIONS allows users to create Ricardian-style contracts'''. These can be used to ''issue currencies'', or to ''make agreements'' between other users—and '''these contracts can be enforced by the server'''.<br />
<br />
OT also uses server contracts, meaning that each OT transaction server is identified by a contract, which contains its connection details for various networks, as well as its public key.<br />
<br />
'''In OT, contracts have become the building block of the entire library.''' These contracts are self-verifying, and if applied to the domain name problem, they have the potential to entirely decentralize the DNS system.<br />
<br />
Coming soon: “Smart contracts” (scriptable clauses.) The Bitcoin economy, as well as the DGCs (digital gold currencies) will need more financial instruments in order to grow. Instruments such as Escrow, Real Bills, Stocks, Bonds, etc. There will always be the need for a system that enables that next financial instrument. I propose to make those available through scripts, so that new custom code is not necessary inside OT itself for most new contract types.<br />
<br />
<br />
-----<br />
<br />
[https://gist.github.com/39158239e36f6af69d6f VOTING POOLS]: <br />
<br>(FOR SAFE, DECENTRALIZED BAILMENT OF BITCOINS ONTO OPEN-TRANSACTIONS SERVERS)<br />
<br />
This post originally posted here: http://forum.bitcoin.org/index.php?topic=28565.msg363945#msg363945<br />
<br />
Benefits (to Bitcoin) of using an OT layer: <br />
# Untraceable transactions <br />
# Easy convertibility to other currencies on the OT market. <br />
# Instant finality of settlement <br />
# The server cannot forge transactions, or change balances without the user's signature. <br />
# All parties need only to store the last signed receipt, and they can prove their current balance, as well as prove which instruments are valid and which transactions are open or closed. <br />
# No worries about running out of space on the block chain.<br />
<br />
===&gt; '''YOU MIGHT ASK: But what if I don't want to TRUST the OT server with my Bitcoins? What if it steals them, or disappears, or gets hacked?'''<br />
<br />
===&gt; Based on conversations with Bitcoin developers, I believe I have found the solution to this. I've got the protocol figured out, but I haven't coded everything yet...<br />
<br />
===&gt; I've hinted at this before, but I've got a bit more free time now, so here it is:<br />
<br />
THE GIST: LOW-TRUST SERVERS (For Bitcoin on OT. The protocol is different with non-crypto-currencies.)<br />
<br />
# Basically, instead of bailing the BTC into a single server, you bail it into a [https://gist.github.com/39158239e36f6af69d6f VOTING POOL] of maybe 50 different servers (or however many.) These will operate like a secure escrow in the blockchain. Many of you already have discussed this concept.<br />
# In my own protocol, the wallet signs the bail-in request, including the amount, the relevant IDs, etc, then the server countersigns it and sends you the receipt. (All the server is doing here is verifying everything in your request, and then signing it, too.)<br />
# Then your client GUI sends that receipt to the voting pool AND sends the Bitcoins to the pool. (There is no single recipient on the blockchain, but a pool of recipients at once.)<br />
# This same process happens in reverse when bailing back out. But this time, after the pool members verify that both parties have signed the bail-out request, they then vote on the blockchain to transfer BTC out to the recipient on that request, with a 3/4ths vote (or whatever) which is what actually effects the BTC transfer back to you. Rules can also be enforced here, involving inbox notification, time delays, maximum daily transfers, or whatever we decide.<br />
# The &quot;vote&quot; between the pool members occurs on the blockchain itself, using the built-in Bitcoin script language. Normally all votes will always be 100% in the same direction, since they will always agree on the truth. So we set it to 3/4ths or 9/10ths, whatever, so that it really takes a supermajority to do any bailment out, yet still leaves enough wiggle-room for the pool to prevent the loss of any BTC, and return it to the rightful owner, even if a server disappears or fails an audit.<br />
# If a receipt is ever submitted to the pool that's NOT properly signed, then the pool members simply vote to reject the receipt. (And probably to distrust the bad actor who submitted it.)<br />
# In the event that an OT server disappears, your BTC is still safe in the pool, and it's still possible to send a signed recovery request to the pool members, get your 3/4ths vote, and have your BTC transferred back to you.<br />
<br />
There's more to it than that, and it involves the '''OT audit protocol''' as well, which is slightly different for issuer-based digital assets than it is for BTC-based digital assets (on OT.)<br />
<br />
...But you get the general idea.<br />
<br />
I've already got all the code I need on the Bitcoin side, I think, and I've got the new protocol figured out on the OT side (not coded yet).<br />
<br />
I think I can swing this with the existing Bitcoin codebase (no changes to Bitcoin itself), and with the existing mining groups, though I'll have to include some Bitcoin code into OT for everything to work. I hope to be able to demonstrate this protocol soon. (Frankly I'm shocked no one else has done this yet.)<br />
<br />
<br />
-----<br />
<br />
<br>A NOTE ON ROLLBACKS!<br />
<br />
For example, if there is real-time auditing between the server and the issuer (or the server and the voting pool, in the case of Bitcoin) then it becomes impossible for the transaction server to counterfeit, though you must trust the issuer (or server pool) with a copy of all receipts, (as you would normally trust only a single OT server with those same receipts.) In this example of real-time auditing, rollbacks are never necessary.<br />
<br />
If, on the other hand, there is once-per-day auditing, then bailments OUT of the system (to get your Bitcoins out of the pool and back into your Bitcoin wallet again) must also have a 24-hour delay, since there is always the potential for a rollback to the last audit, in the event that a server is caught counterfeiting.<br />
<br />
We already knew that servers could not forge transactions or screw you on your balance, but it is this last piece, the ''auditing'', that entirely prevents ''counterfeiting'' as well, and thus brings us truly into the realm of '''low-trust servers.'''</div>Cryptomanhttp://opentransactions.org/wiki/index.php?title=CENTRALIZED&diff=94CENTRALIZED2013-06-11T21:36:07Z<p>Cryptoman: Created page with "''The vision is not of a central server you must trust. <br>Rather, the vision is of federated servers you don’t have to trust.'' My goal with Open-Transactions is for the ..."</p>
<hr />
<div>''The vision is not of a central server you must trust.<br />
<br>Rather, the vision is of federated servers you don’t have to trust.''<br />
<br />
My goal with Open-Transactions is for the servers to be able to run on anonymous networks. For this to work, that means '''the users must be able to trust the system, even if they do not trust the servers'''.<br />
<br />
We must have LOW-TRUST SERVERS--and that is what I have been working towards. The combination of low-trust technology with untraceable cash is what will make it possible to run OT servers on anonymous networks, at a profit.<br />
<br />
<br />
-----<br />
<br />
There are some big differences between Open-Transactions and the “typical centralized system”...<br />
<br />
# — A ''typical centralized system'' is '''fully-traceable'''. You are always under the watchful gaze of the “all-seeing eye”.<br />
<br />
But on OPEN-TRANSACTIONS, blind signatures are employed, providing '''untraceable digital cash'''.<br />
<br />
<br />
-----<br />
<br><br />
<ol start="2" style="list-style-type: decimal;"><br />
<li>— The '''typical centralized system''' stores a simple number as your “account balance.” '''The server could change your balance simply by changing that number''', and '''you must trust the server''' not to change your balance, or steal your money. (Ironically, this is the case on all the Bitcoin-related exchange sites today.)</li></ol><br />
<br />
'''But an OPEN-TRANSACTIONS server cannot forge any transaction, nor can it change your balance without your signature.''' Even a malicious server cannot do these things!<br />
<br />
How is this possible? Because your “account balance” on OT is whatever appears on your last receipt. And an OT server cannot sign any receipt unless you have first signed the initial request, since a full copy of that request must appear inside the receipt. Thus the server cannot falsify any receipt because the server cannot forge your signature on the request.<br />
<br />
Therefore the OT server can never sign any balance, or transaction, that you have not signed first!<br />
<br />
<br />
-----<br />
<br><br />
<ol start="3" style="list-style-type: decimal;"><br />
<li>— A ''typical centralized system'' would have the ability to '''abscond with your Bitcoins''' or gold.</li></ol><br />
<br />
'''But an OPEN-TRANSACTIONS server cannot disappear with the reserves!'''<br />
<br />
Why not? Because it doesn’t have any. (For Bitcoin, this will be done using [https://gist.github.com/39158239e36f6af69d6f voting pools] on the blockchain, a feature which has not yet been coded. Scroll to the bottom of this page for a description of how it will work.)<br />
<br />
OT follows a philosophy of “separation of powers”. Meaning, the issuer and the transaction server are separate entities. If, for example, your currency is backed in gold, then it is the gold issuer you must trust, not the OT transaction server. ''Even if an OT transaction server disappears into the night, you still have your account (i.e. the last receipt) and you can still redeem it at your issuer or have it re-issued onto a new transaction server.''<br />
<br />
The same will soon be true with Bitcoin: I have been cooperating with certain Bitcoin developers on a ''new mechanism'' to allow users to bail their Bitcoins in-and-out of OT servers, ''without having to trust the server itself''. That is, even if the server tried to disappear with your Bitcoin, it would not be able to. The next generation of Bitcoin and OT will have this capability. (The new BTC protocol hasn’t been added to OT yet but is coming soon.) Woe to anyone building a Bitcoin site that doesn’t have this capability! …Because soon your OT-enabled competitors will eat your lunch.<br />
<br />
More on separation of powers: <br />
<br>— ''A single currency (such as “Pecunix gold grams” or “Liberty Reserve dollars”) might be issued on a dozen different transaction servers'' in different jurisdictions, with the same currency contract being used for all of them. One currency--many servers. <br />
<br>— ''Transaction servers can prove which currencies have been issued there'', by producing the issuer’s last receipt. (And the currency contract.) <br>— ''Issuers and transaction servers can both prove the total amount that has been issued'', also by producing the last receipt. <br />
<br>— ''The same currency might be distributed across a dozen different issuers, using basket currencies.'' (Basket currencies allow users to distribute the risk of a single currency across multiple trusted issuers.) <br />
<br>— ''The contents of a single “asset account” might be distributed across a dozen different transaction servers.'' (If this abstraction is coded into your client GUI, then what appears as a single account is actually spread across X number of servers.)<br />
<br />
<br />
-----<br />
<br><br />
<ol start="4" style="list-style-type: decimal;"><br />
<li>— Let’s concede that while OT can’t forge receipts against individual users, a malicious server could still use a dummy account to inflate the currency itself, without having to forge any of the individual users’ receipts, and without having to forge the issuer’s receipt.</li></ol><br />
<br />
This is true, but it would not escape the upcoming ''OT Audit Protocol!''<br />
<br />
Why not? Because counterfeit funds cannot be spent without flowing from an illicit account into the other accounts of the general population, where the total amount will show up on an audit and be compared against the amount on the issuer’s last receipt.<br />
<br />
As long as there is real-time auditing, OR as long as receipts are stored between audits (which could be daily) then '''the users, as above, can simply dump the untrusted server''' and redeem their receipts at the issuer. (This can all be automated.) Transaction servers, of course, would have a huge incentive not to pull this, since they already can’t get away with it, and since they would instantly lose their daily revenues from transaction fees.<br />
<br />
A similar solution is planned for Bitcoin-based accounts on OT, using the same new mechanism described in answer (3). (It also doesn’t hurt that Bitcoins are publicly-auditable, but our plans go beyond that.)<br />
<br />
FYI, the OT Audit protocol is designed but not yet coded.<br />
<br />
<br />
-----<br />
<br><br />
<ol start="5" style="list-style-type: decimal;"><br />
<li>— ''A typical centralized system is very vulnerable to hackers'', who make use of all manner of '''cross-site-scripting and SQL injection''' in order to '''gain access to your server account''' and do transactions you never authorized.</li></ol><br />
<br />
But on OPEN-TRANSACTIONS, hacking a user would entail gaining access to his private key--which is not stored on the server--as well as installing a keylogger on the user’s machine (in order to get his passphrase.) Furthermore, the hacker would have to do this for '''each individual user'''. (The ultimate solution goes even further: store your private key on a crypto-card. People will actually start doing this once enough of them have been hacked.)<br />
<br />
'''By comparison, MtGox recently had hackers sell-off all of the users’ balances for pennies. This also had the effect of crashing the Bitcoin market and damaging the “bulletproof” reputation of Bitcoin.'''<br />
<br />
<br />
-----<br />
<br><br />
<ol start="6" style="list-style-type: decimal;"><br />
<li>— A ''typical centralized system'' is vulnerable to hackers obtaining a copy of their database, and subsequently distributing the users’ email addresses, hashed passwords, account balances, and usernames all over the Internet.</li></ol><br />
<br />
These same users are then subjected to an aftermath consisting of hacks on their Tradehill, Facebook, etc accounts, as well as the imposition of frustrating account-validation and password-changing procedures at all of those sites.<br />
<br />
'''But on OPEN-TRANSACTIONS, no passwords are stored on the server OR client side'''. Instead, public-key cryptography is used, and the server only responds to signed requests. Users will never have to go and change their Gmail password because of using OT-based systems.<br />
<br />
<br />
-----<br />
<br />
<ol start="7" style="list-style-type: decimal;"><br />
<li>— A ''typical centralized system'' must store all of its receipts, forever. This is because it cannot prove ''which instruments are authorized'', or ''which transactions have cleared'', without storing them all (in an ever-growing database.) That’s the only way it can prove its case in the event of any dispute. (If parties cannot &quot;prove their case&quot; in a dispute, then the system breaks down.)</li></ol><br />
<br />
But OPEN-TRANSACTIONS uses Triple-Signed-Receipts: '''Parties can prove '''which transactions have cleared''', and '''which instruments are authorized''', simply by keeping their '''''last signed receipt.'''''<br />
<br />
<br />
-----<br />
<br><br />
<ol start="8" style="list-style-type: decimal;"><br />
<li>— A ''typical centralized server'' (such as e-gold) can be pressured to produce transaction data, and made legally responsible to report it. Such data is also vulnerable to hackers (such as happened to MtGox.)</li></ol><br />
<br />
'''But on OPEN-TRANSACTIONS, users and transaction servers both have the choice to operate in “cash-only” mode, which is completely anonymous. The server cannot be pressured or hacked to reveal your account, if you don’t have one!'''<br />
<br />
The issuer is similarly safe, due to OT’s philosophy of “separation of powers.” Since he has outsourced the transaction processing to the transaction server, the issuer cannot be forced to produce any transaction data--he doesn’t have any!<br />
<br />
Note: the more often the issuer performs an audit, the more transaction data he has access to. Clearly in a real-time audit he DOES have access to all transaction data. Therefore the length of the auditing period will be shaped partially by legal considerations. In the case of Bitcoin, on the other hand, real-time auditing will usually be preferable. (Of course when those transactions involve cash, they are untraceable either way.)<br />
<br />
<br />
-----<br />
<br><br />
<ol start="9" style="list-style-type: decimal;"><br />
<li>— A ''typical centralized server'' requires a bailment process to exchange funds onto the server, and back off again.</li></ol><br />
<br />
'''Open-Transactions servers don't require any bailment process, since they don't store any reserves'''. Instead, the issuer chooses when to issue new units of any currency, and any bailment happens through the issuer directly. (Just like on Loom.)<br />
<br />
A similar, yet more p2p solution is coming soon for Bitcoin-backed currencies--this is the same new mechanism mentioned in (3).<br />
<br />
Additional options also coming soon:<br />
<br />
A user will soon be able to transfer to another user in return for a similar reciprocal transfer on an entirely different system (via '''Ripple'''), and even into a completely different currency, with the exchange being negotiated p2p by the Ripple protocol.<br />
<br />
In effect, this allows users to bail out of specific servers without having to “bail out” at all — instead merely sending an internal transfer to another user, who then pays them in a separate account via Ripple.<br />
<br />
Ripple client capabilities are being built into Moneychanger (OT Java client.) Since Moneychanger users will likely list different currency types in their wallets, it only makes sense to connect them all via Ripple. Especially since OT clients will be P2P anyway (they need to compare notes on public mint files for various OT servers.)<br />
<br />
'''This is where I see the true value of Ripple: Eliminating any need for server-to-server transfer, by allowing currency flows directly through the users.'''<br />
<br />
Open-Transactions also allows for users to transfer from one server to another through the issuer, since he already exists at both ends. (Therefore the user doesn’t have to “bail out” in-between.)<br />
<br />
'''Open-Transactions will also make use of Bitcoin as a “glue”, or “universal medium”, between OT servers.''' OT will always use a crypto-currency in this regard (whether Bitcoin or whatever else) since it is a unique solution to this problem.<br />
<br />
<br />
-----<br />
<br><br />
<ol start="10" style="list-style-type: decimal;"><br />
<li>— A ''typical centralized server'' only supports two financial instruments: ''account transfer'', and sometimes ''market trades''.</li></ol><br />
<br />
'''But OPEN-TRANSACTIONS currently supports cheques, invoices, vouchers, account transfer, receipts, market trades, payment plans, and untraceable digital cash.'''<br />
<br />
Many more instruments are coming soon to OT, including those with scriptable custom behaviors.<br />
<br />
<br />
-----<br />
<br><br />
<ol start="11" style="list-style-type: decimal;"><br />
<li>— A ''typical centralized system'' does not have '''contracts.'''</li></ol><br />
<br />
'''OPEN-TRANSACTIONS allows users to create Ricardian-style contracts'''. These can be used to ''issue currencies'', or to ''make agreements'' between other users—and '''these contracts can be enforced by the server'''.<br />
<br />
OT also uses server contracts, meaning that each OT transaction server is identified by a contract, which contains its connection details for various networks, as well as its public key.<br />
<br />
'''In OT, contracts have become the building block of the entire library.''' These contracts are self-verifying, and if applied to the domain name problem, they have the potential to entirely decentralize the DNS system.<br />
<br />
Coming soon: “Smart contracts” (scriptable clauses.) The Bitcoin economy, as well as the DGCs (digital gold currencies) will need more financial instruments in order to grow. Instruments such as Escrow, Real Bills, Stocks, Bonds, etc. There will always be the need for a system that enables that next financial instrument. I propose to make those available through scripts, so that new custom code is not necessary inside OT itself for most new contract types.<br />
<br />
<br />
-----<br />
<br />
[https://gist.github.com/39158239e36f6af69d6f VOTING POOLS]: <br />
<br>(FOR SAFE, DECENTRALIZED BAILMENT OF BITCOINS ONTO OPEN-TRANSACTIONS SERVERS)<br />
<br />
This post originally posted here: http://forum.bitcoin.org/index.php?topic=28565.msg363945#msg363945<br />
<br />
Benefits (to Bitcoin) of using an OT layer: <br />
# Untraceable transactions <br />
# Easy convertibility to other currencies on the OT market. <br />
# Instant finality of settlement <br />
# The server cannot forge transactions, or change balances without the user's signature. <br />
# All parties need only to store the last signed receipt, and they can prove their current balance, as well as prove which instruments are valid and which transactions are open or closed. <br />
# No worries about running out of space on the block chain.<br />
<br />
===&gt; '''YOU MIGHT ASK: But what if I don't want to TRUST the OT server with my Bitcoins? What if it steals them, or disappears, or gets hacked?'''<br />
<br />
===&gt; Based on conversations with Bitcoin developers, I believe I have found the solution to this. I've got the protocol figured out, but I haven't coded everything yet...<br />
<br />
===&gt; I've hinted at this before, but I've got a bit more free time now, so here it is:<br />
<br />
THE GIST: LOW-TRUST SERVERS (For Bitcoin on OT. The protocol is different with non-crypto-currencies.)<br />
<br />
# Basically, instead of bailing the BTC into a single server, you bail it into a [https://gist.github.com/39158239e36f6af69d6f VOTING POOL] of maybe 50 different servers (or however many.) These will operate like a secure escrow in the blockchain. Many of you already have discussed this concept.<br />
# In my own protocol, the wallet signs the bail-in request, including the amount, the relevant IDs, etc, then the server countersigns it and sends you the receipt. (All the server is doing here is verifying everything in your request, and then signing it, too.)<br />
# Then your client GUI sends that receipt to the voting pool AND sends the Bitcoins to the pool. (There is no single recipient on the blockchain, but a pool of recipients at once.)<br />
# This same process happens in reverse when bailing back out. But this time, after the pool members verify that both parties have signed the bail-out request, they then vote on the blockchain to transfer BTC out to the recipient on that request, with a 3/4ths vote (or whatever) which is what actually effects the BTC transfer back to you. Rules can also be enforced here, involving inbox notification, time delays, maximum daily transfers, or whatever we decide.<br />
# The &quot;vote&quot; between the pool members occurs on the blockchain itself, using the built-in Bitcoin script language. Normally all votes will always be 100% in the same direction, since they will always agree on the truth. So we set it to 3/4ths or 9/10ths, whatever, so that it really takes a supermajority to do any bailment out, yet still leaves enough wiggle-room for the pool to prevent the loss of any BTC, and return it to the rightful owner, even if a server disappears or fails an audit.<br />
# If a receipt is ever submitted to the pool that's NOT properly signed, then the pool members simply vote to reject the receipt. (And probably to distrust the bad actor who submitted it.)<br />
# In the event that an OT server disappears, your BTC is still safe in the pool, and it's still possible to send a signed recovery request to the pool members, get your 3/4ths vote, and have your BTC transferred back to you.<br />
<br />
There's more to it than that, and it involves the '''OT audit protocol''' as well, which is slightly different for issuer-based digital assets than it is for BTC-based digital assets (on OT.)<br />
<br />
...But you get the general idea.<br />
<br />
I've already got all the code I need on the Bitcoin side, I think, and I've got the new protocol figured out on the OT side (not coded yet).<br />
<br />
I think I can swing this with the existing Bitcoin codebase (no changes to Bitcoin itself), and with the existing mining groups, though I'll have to include some Bitcoin code into OT for everything to work. I hope to be able to demonstrate this protocol soon. (Frankly I'm shocked no one else has done this yet.)<br />
<br />
<br />
-----<br />
<br />
<br>A NOTE ON ROLLBACKS!<br />
<br />
For example, if there is real-time auditing between the server and the issuer (or the server and the voting pool, in the case of Bitcoin) then it becomes impossible for the transaction server to counterfeit, though you must trust the issuer (or server pool) with a copy of all receipts, (as you would normally trust only a single OT server with those same receipts.) In this example of real-time auditing, rollbacks are never necessary.<br />
<br />
If, on the other hand, there is once-per-day auditing, then bailments OUT of the system (to get your Bitcoins out of the pool and back into your Bitcoin wallet again) must also have a 24-hour delay, since there is always the potential for a rollback to the last audit, in the event that a server is caught counterfeiting.<br />
<br />
We already knew that servers could not forge transactions or screw you on your balance, but it is this last piece, the ''auditing'', that entirely prevents ''counterfeiting'' as well, and thus brings us truly into the realm of '''low-trust servers.'''</div>Cryptomanhttp://opentransactions.org/wiki/index.php?title=Client-side_scripting&diff=93Client-side scripting2013-06-11T19:52:45Z<p>Cryptoman: Created page with "The ot script interpreter (&quot;ot&quot;) has access to the entire OT Client API, including the low-level ''and'' high-level APIs. In fact, the opentxs command-li..."</p>
<hr />
<div>The ot script interpreter (&quot;ot&quot;) has access to the entire OT Client API, including the low-level ''and'' high-level APIs. In fact, the [[Opentxs|opentxs]] command-line tool itself is written in ot script, just like any other script.<br />
<br />
To make your own OT script, create a text file, and <code>chmod u+x filename</code> in order to be able to run it as an executable. Then put this shebang at the top of the file: <code>#!/usr/bin/env ot</code><br />
<br />
Now you can run that file like any other executable, just type: <code>./filename</code> and the script will execute as an OT client, with full access to the OT [[API|low-level API]] as well as the OT [[Use Cases|high-level API]].<br />
<br />
OT is easy! Even a trained monkey can write OT-based scripts and client applications! If you want to see how the high-level API is used, check out the [https://github.com/FellowTraveler/Open-Transactions/blob/master/scripts/ot/ot_commands.ot code for the opentxs CLI tool] for example functions demonstrating all of the OT functionality. (In fact, you can actually CALL all those functions from your own OT scripts.)<br />
<br />
See also: [[Smart contracts]]</div>Cryptomanhttp://opentransactions.org/wiki/index.php?title=Markets&diff=92Markets2013-06-11T19:41:56Z<p>Cryptoman: Created page with "Right now I've got the markets coded and trading. You can put an offer on a market. (There may be a hundred other offers already there... each with their own terms and limits...."</p>
<hr />
<div>Right now I've got the markets coded and trading. You can put an offer on a market. (There may be a hundred other offers already there... each with their own terms and limits.)<br />
<br />
You'll always get the lowest price on the market if you're buying, or the highest price if you're selling. (As long as there are offers within your range.)<br />
<br />
Your offer may trade many times before it is done, and against ''multiple other offers'' on the market. After each trade, OTCron will drop a receipt into the respective inboxes for the 4 asset accounts involved. (A trade involves, say, a buyer and seller ''bitcoin'' acct, and a buyer and seller ''WoW gold'' account. That's 4 asset accounts total, with each Nym controlling two accounts.)<br />
<br />
When your offer has completed its terms, OTCron then removes it from the market.<br />
<br />
You can configure your offer as a &quot;day order&quot; (date range) and/or as a &quot;stop order&quot; (only activate onto the market when price reaches X level) and/or as a &quot;limit order&quot; (only allow trades at a certain price point) and/or as a &quot;fill-or-kill order&quot; (each trade against a given offer must occur in minimum increments.)<br />
<br />
OT Markets also support market granularity, meaning that the price of wheat on the 5000 bushel market might be cheaper, per bushel, than the price of the same wheat on the 10 bushel market. This means that traders would be able to profit by purchasing in bulk and then breaking up the wheat to be sold in smaller chunks (on smaller granularity markets.)<br />
<br />
You could also use the markets for trading currency baskets (since OT supports baskets).<br />
<br />
Since each asset type on OT is based on a currency contract, you could even issue futures contracts and other options, and use OT for trading futures on markets, or baskets of futures, etc etc.<br />
<br />
Current drawbacks: (1) OT is very new and has not been tested with users in the real world. The version is v0.44 as I write this. I'm very proud of it, but it is brand spanking new, so you have to take that into account. (2), the keysize is still restricted to 1024. Since the software is still experimental, I haven't added any other keysizes yet, but that will be necessary if you are using it for real trades, FYI. I am very supportive of any developers using the OT [[API]].<br />
<br />
Here's the issue market offer API call:<br />
<br />
<pre><br />
// --------------------------------------------------<br />
/// ISSUE MARKET OFFER<br />
///<br />
void <br />
// Notice the return value is void. Use OT_API_PopMessageBuffer() to check for server replies.<br />
OT_API_issueMarketOffer <br />
(const char * SERVER_ID,// The OT API uses the server ID to look up the connect info from the server contract.<br />
const char * USER_ID, // UserID (NymID) is a hash of the public key. ServerID (above) is a hash of server contract. <br />
// -------------------------------------------<br />
const char * ASSET_TYPE_ID, // Perhaps this is the wheat market.<br />
const char * ASSET_ACCT_ID, // This is my wheat account.<br />
// -------------------------------------------<br />
const char * CURRENCY_TYPE_ID, // Perhaps I'm buying the wheat with rubles.<br />
const char * CURRENCY_ACCT_ID, // This is my ruble account.<br />
// -------------------------------------------<br />
const char * MARKET_SCALE, // Defaults to minimum of 1. Market granularity.<br />
const char * MINIMUM_INCREMENT, // This will be multiplied by the Scale. Min 1.<br />
const char * TOTAL_ASSETS_ON_OFFER, // Total assets available for sale or purchase. Will be multiplied by minimum increment.<br />
const char * PRICE_LIMIT, // Per Minimum Increment...<br />
int bBuyingOrSelling); // Actually OT_BOOL. SELLING == OT_TRUE (1), BUYING == OT_FALSE (0).</pre><br />
For all you web guys, the &quot;const char *&quot; means that parameter is passed as a string.<br />
<br />
FOR THOSE FASCINATED WITH TRIPLE-ENTRY ACCOUNTING.<br />
<br />
(A description of the improvements made to receipts in the latest release of OT.)<br />
<br />
Warning: boring accounting details below...<br />
<br />
-- finalReceipt and basketReceipt are powerful additions to OT's receipt system, which bring OT's recurring transactions, basket currencies, and markets fully into compliance with the doctrine of &quot;destruction of account history&quot;.<br />
<br />
BACKGROUND (using chequeReceipt as an example):<br />
<br />
In order to perform any transaction, the OT client must use a transaction number. These numbers are signed-for ON EVERY SINGLE RECEIPT -- until they are closed.<br />
<br />
For example, if you write a cheque, #47, then the #47 will appear on every receipt going into the future, for '''every''' transaction that you do, until that transaction #47 is closed.<br />
<br />
When will it be closed? When the cheque is cashed, the chequeReceipt #47 will appear in your inbox. YOU must accept it, before #47 will be closed -- which removes it from your inbox, AND signs-off on the latest account balance.<br />
<br />
You see, since your balance is CHANGED whenever a cheque you wrote CLEARS, the server is thus forced to keep a copy of that chequeReceipt in your inbox, in order to prove the current balance, since that cheque has your signature on it. (The current balance, FYI, is your last signed balance, which the server already has on the most recent receipt, minus the amount of the cheque, which also features #47 -- a valid number -- and YOUR SIGNATURE.)<br />
<br />
Once you sign to accept the chequeReceipt, it disappears from your inbox, the latest balance is signed, and #47 disappears forever from your list of &quot;Issued Transaction Numbers&quot;. (That is, you no longer have to sign for #47 on any of your future receipts, since #47 is now CLOSED.)<br />
<br />
IN SUM: &quot;To perform a transaction, you must burn up one of your transaction numbers. And you need to sign for those in advance before you can use them. AND you need to CONTINUE signing, on into the future, for any transaction number that has been used, UNTIL YOU FINALLY SIGN TO CLOSE it.&quot;<br />
<br />
<br />
-----<br />
<br />
<br>NOW LET'S examine the latest updates to OT:<br />
<br />
FINAL RECEIPT and BASKET RECEIPT<br />
All of the above still holds true; chequeReceipt still operates exactly the same, as do the receipts for transfers, withdrawals, deposits, etc. Those are the same.<br />
<br />
===&gt; But, for Markets…. (and other recurring transactions...)<br />
<br />
-- When Alice places an offer on a market, the server saves a copy of her signed offer. BUT THIS TIME, '''THREE''' transaction numbers are provided instead of one: an opening number, and a closing number for EACH asset account, of which there are two. (She is buying bushels of wheat in return for dollars. Therefore she has a WHEAT account and a DOLLAR account.)<br />
<br />
-- As various trades process on the market over time (against her market offer), marketReceipts will appear in Alice's inbox for her wheat account, and her inbox for her dollar account. Each marketReceipt contains a copy of Alice's ORIGINAL market offer, as well as an UPDATED VERSION (showing the changes to her account balances as a result of each trade.)<br />
<br />
-- Remember that Alice has to sign for these 3 transaction numbers on ALL of her future receipts, until they are closed out. Let's say the numbers are #9, #10, and #11.<br />
<br />
-- marketReceipts will continue to appear in Alice's inboxes over time, which she can remove by signing to accept them. This allows the server to prove the latest balance for each account (as caused by each trade and proven by each receipt.) So far, this much is similar to when you sign for a normal chequeReceipt.<br />
<br />
-- But now Alice cannot cancel her market offer! Because what if new marketReceipts are popping into her inbox from new trades so quickly, that she is unable to do a new balance agreement before a new one comes in? If she cannot sign a proper balance agreement, then she cannot perform the transaction necessary to cancel the trading (nor can she close out the numbers from her receipts, and out of her inbox!) She's trapped.<br />
<br />
===&gt; THIS IS WHY there are now THREE transaction numbers for a market offer (say #9, #10 and #11): Because when the &quot;Cancel Market Offer&quot; message is sent, it requires no balance agreement at all! Instead, these actions occur:<br />
<br />
# Transaction #9 is permanently closed, and will not appear on any future receipts.<br />
# Transaction #10 appears as a FINAL RECEIPT in Alice's WHEAT inbox (in reference to #9.)<br />
# Transaction #11 appears as a FINAL RECEIPT in Alice's DOLLAR inbox (in reference to #9.)<br />
<br />
===&gt; Trans#'s 10 and 11 stay open. (For now.)<br />
<br />
===&gt; The finalReceipts in each inbox prove when the offer was officially closed. (Whether by Alice, or by some other natural expiration. This is where smart contracts will figure big, in the future.)<br />
<br />
===&gt; Alice's &quot;last signed receipt&quot; shows her inbox contents, and the same receipt no longer shows #9 signed out -- she's not responsible for number 9 anymore. Thus any marketReceipt appearing AFTER would automatically be INVALID. (No NEW balance changes are permitted, related to #9.)<br />
<br />
===&gt; This means that new marketReceipts can never be dumped onto Alice AFTER she has closed a market offer (or payment plan.)<br />
<br />
From there, Alice can accept the various receipts in her inbox at her LEISURE--the trading has been stopped, no more recurring transactions can occur, and the finalReceipt proves this.<br />
<br />
THE TRICK IS: #10 and #11 are still open, and they REFER to #9. In order to finally CLOSE those finalReceipts for #10 and #11, which both refer to #9 -- OT requires Alice to ALSO close any other marketReceipts present in those inboxes, that ALSO refer to #9. (That is, the finalReceipt cannot be removed until those related receipts are also removed.)<br />
<br />
===&gt; This way, OT is guaranteed that all of Alice's WHEAT balance changes (shown in the marketReceipts in the wheat inbox) will be signed-for by the client and CLOSED OUT properly before finalReceipt#10 itself is closed out.<br />
<br />
===&gt; Similarly, all of Alice's DOLLAR balance changes (shown in the marketReceipts for her dollar inbox) will also be signed for by the client and CLOSED OUT properly before finalReceipt #11 itself is finally closed.<br />
<br />
===&gt; Thus, by the time the finalReceipts #10 and #11 are finally closed, ALL RECEIPTS will have been closed related to this market offer, and all balances have been agreed, for Alice's wheat account AND her dollar account.<br />
<br />
I find this very interesting because it takes the concept of &quot;Destruction of Account History&quot; as pioneered by Bill St. Clair and Patrick Chkeroff, and adapts it to '''* recurring transactions *''' such as market offers and PAYMENT PLANS.<br />
<br />
This innovation is unique to OT, as far as I know.<br />
<br />
<br />
-----<br />
<br />
<br>The same concept has also now been adapted for OT's BASKET CURRENCIES.<br />
<br />
When you exchange into a [dollar/gold/bitcoin] basket, you must actually supply your dollar account, your gold account, and your bitcoin account, so that OT can remove the the appropriate amount of dollars, gold, and bitcoins from those accounts, in order to credit you with the new basket units during the exchange.<br />
<br />
The OT client will now provide '''4''' transaction numbers in order to perform the exchange:<br />
<br />
9. The main basket account's basketReceipt <br />
<br />
10. The dollar account's basketReceipt <br />
<br />
11. The gold account's basketReceipt <br />
<br />
12. The bitcoin account's basketReceipt <br />
<br />
When the exchange occurs, the client does NOT have to sign any balance agreements. Instead, a basketReceipt is dropped into EACH INBOX, and the balance agreements can be signed later, whenever the client wants to finally close out those receipts.<br />
<br />
OTHERWISE, THE CLIENT WOULD HAVE TO PROVIDE a full balance agreement for every single account, all at once, in order to perform the exchange! The server would also have to verify all 4 of these balance agreements in order to process it!<br />
<br />
That would be unwieldy. What if there were 10 asset accounts in the basket, or 50? Must I perform 50 balance agreements in order to do a single transaction?<br />
<br />
INSTEAD, THINGS ARE EASY: a basketReceipt is simply dropped into the inbox for each constituent account, and the user can close those receipts later, the same as he would close a chequeReceipt or transferReceipt, signing the new balance at that time.<br />
<br />
I find this very interesting because it takes the concept of &quot;Destruction of Account History&quot; and adapts it to BASKET CURRENCIES.<br />
<br />
<br />
-----<br />
<br />
<br>This means:<br />
<br />
===&gt; finalReceipt means that OT can perform transactions that PROCESS REPEATEDLY OVER TIME, even hundreds of times, yet it maintains the secure paradigm of &quot;destruction of account history.&quot;<br />
<br />
===&gt; basketReceipt means that OT can perform transactions that process across ANY NUMBER OF ASSET ACCOUNTS -- even dozens of asset accounts in a single transaction -- yet it still maintains the secure paradigm of &quot;destruction of account history.&quot;<br />
<br />
===&gt; This means that a new transaction type involving MULTIPLE TRADES can be processed based on STANDING OFFERS, WITHOUT forcing a signature from each client at each stop along the way.<br />
<br />
This is awesome IMO!<br />
<br />
<br />
-----<br />
<br />
<br>I'm sure you can see where I'm going with all of this...<br />
<br />
<nowiki>**** RIPPLE ****</nowiki><br />
<br />
The latest changes to receipts are what will make it possible to eventually add RIPPLE CREDIT LINES and RIPPLE FLOWS to OT!<br />
<br />
Of course that will require a whole other set of code, which I will have to get around to at some point when I can afford it, but it will someday become possible to extend &quot;credit lines&quot; between Nyms, and then have &quot;Ripple Markets&quot; where payments can flow p2p between the various credit lines.<br />
<br />
This is made possible by the new receipt code, since instead of having to sign for each individual transaction during a &quot;Ripple Flow&quot;, credit lines will involve STANDING OFFERS, which will process according to their terms as long as the transaction stays open! (The same way as marketReceipts do now -- until the credit line is closed, and the &quot;finalReceipt&quot; is thrown.)<br />
<br />
So this release gets us closer to using OT as Ripple, although more would still need to be coded, such as the CreditLine object itself, and the RippleMarket, etc.<br />
<br />
In case you guys find any of this Ripple stuff interesting, I've attached some of my notes below. It will probably be months before any of this actually gets coded, but you might enjoy the thoughts recorded.<br />
<br />
Happy September! And remember, the time is short.<br />
<br />
Your friend,<br />
<br />
-Fellow Traveler<br />
<br />
PS NEED VOLUNTEERS: iOS client, Mac client, Google Native Chrome, Android client, Windows client, QT client, Bitcoin integration, Bittorrent integration, TAHOE-LAFS integration, Freenet integration, i2p integration, mixminion integration, Tor integration, Firefox integration, Thunderbird integration...<br />
<br />
<br />
-----<br />
<br />
<br>Ripple Notes<br />
<br />
The only change necessary for OT to have built in Ripple is to make possible to execute various trades atomically.<br />
<br />
Alice, Bob, Timón, and FT issue each one their own digital currency.<br />
<br />
The denomination is not very important, because it will only affect the exchange rate, that users will have to set manually anyway.<br />
<br />
<br>1) Alice issues aUSDs that are accepted by her and Bob, because they're friends.<br />
<br />
Bob issues bUSDs that are accepted by him, Alice and Timón.<br />
<br />
Bob usually buys bread to Timón for bitcoins, and Timón sometimes accepts bUSDs.<br />
<br />
Timón issues tHours that Bob accepts, because with them he can buy bUSDs (to settle debts with Timón) and bread.<br />
<br />
FT issues fOz's (ounces of silver) that really keeps at home and that Timón accepts because he knows FT accepts 1 Oz per hour of programming labor.<br />
<br />
<br>2) Now FT wants to buy a box full of apples from Alice, that see sells for 80 aUSDs.<br />
<br />
Let's see the market: Alice buys up to 100 bUSDs for aUSDs at a 1:1 rate Bob buys up to 100 aUSDs for bUSDs at a 1:1 rate Bob buys up to 10 tHours for bUSDs at a 1:10 rate Timón buys up to 2.5 fOz's for tHours at a 1:4 rate<br />
<br />
The balances don't change, they're just putting an offer in the market. For example.<br />
<br />
Alice buys up to 100 bUSDs for aUSDs at a 1:1 rate Would be like an offer like this: user=alice buying=bUSD, selling=aUSD, price=1, amount=100<br />
<br />
<br>3) So FT could sell 2 fOz's for 8 tHours. Then sell 8 tHours for 80 bUSDs. Then sell 80 bUSDs for 80 aUSDs. Then sell 80 aUSDs for a box full of apples.<br />
<br />
The payment described in 3 should be atomic.<br />
<br />
Balances before the transaction:<br />
<br />
{| class="wikitable"<br />
||||aUSD||bUSD||tHours||fSLV<br />
|-<br />
|Alice||10,000||0||0||0 <br />
|-<br />
|Bob||0||10,000||0||0<br />
|-<br />
|Timón||0||0||1,000||0<br />
|-<br />
|FellowTraveller||0||0||0||500<br />
|}<br />
<br />
<br />
Balances after the transaction:<br />
<br />
{| class="wikitable"<br />
||||aUSD||bUSD||tHours||fSLV<br />
|-<br />
|Alice||10,000||80||0||0<br />
|-<br />
|Bob||0||9,920||8||0<br />
|-<br />
|Timón||0||0||992||2<br />
|-<br />
|FellowTraveller||0||0||0||498<br />
|}<br />
<br />
<br />
-----<br />
<br />
<br>If you want it step by step, here it is (but remember we want it to occur atomically).<br />
<br />
FT sells 2 fOz's for 8 tHours.<br />
<br />
{| class="wikitable"<br />
||||aUSD||bUSD||tHours||fSLV<br />
|-<br />
|Alice||10,000||0||0||0 <br />
|-<br />
|Bob||0||10,000||0||0<br />
|-<br />
|Timón||0||0||992||2<br />
|-<br />
|FellowTraveller||0||0||8||498<br />
|}<br />
<br />
Then sell 8 tHours for 80 bUSDs.<br />
<br />
{| class="wikitable"<br />
||||aUSD||bUSD||tHours||fSLV<br />
|-<br />
|Alice 10,000||0||0||0 <br />
|-<br />
|Bob||0||9,920||8||0 <br />
|-<br />
|Timón||0||0||992||2 <br />
|-<br />
|FellowTraveller||0||80||0||498<br />
|}<br />
<br />
Then sell 80 bUSDs for 80 aUSDs.<br />
<br />
{| class="wikitable"<br />
||||aUSD||bUSD||tHours||fSLV<br />
|-<br />
|Alice||9,920||80||0||0 <br />
|-<br />
|Bob||0||9,920||8||0 <br />
|-<br />
|Timón||0||0||992||2 <br />
|-<br />
|FellowTraveller||80||0||0||498<br />
|}<br />
<br />
Then sell 80 aUSDs for a box full of apples.<br />
<br />
{| class="wikitable"<br />
||||aUSD||bUSD||tHours||fSLV<br />
|-<br />
|Alice||10,000||80||0||0 <br />
|-<br />
|Bob||0||9,920||8||0 <br />
|-<br />
|Timón||0||0||992||2 <br />
|-<br />
|FellowTraveller||0||0||0||498<br />
|}<br />
<br><br />
<br><br />
-----<br />
<br />
<br>Q: WHAT IS A CREDIT LINE?<br />
<br />
A: Alice opening a bUSD account and putting an offer &quot;I buy up to 100 bUSD for aUSDs&quot; is the equivalent of giving credit to Bob.<br />
<br />
Q: Would Alice and Bob see that there are actually two currencies (aUSD and bUSD) or would the UI be such that they only need to see them as &quot;dollars&quot;, and they see that they are willing to accept dollars from each other?<br />
<br />
A: They could see separately:<br />
<br />
-How many dollars they have issued in total (how much they owe).<br />
<br />
-How many dollars their neighbors have of their currency (how much they owe by user)<br />
<br />
-How many dollars they have from their neighbors (how much each user owes them)<br />
<br />
-How many dollars they have from other people in total (how much people owe them)<br />
<br />
And the same for each denomination.<br />
<br />
<br />
-----<br />
<br />
<br>Alice opening a bUSD account and putting an offer &quot;I buy up to 100 bUSD for aUSDs&quot; is the equivalent of giving credit to Bob.<br />
<br />
In the example, Bob never has aUSDs so he doesn't need an aUSD account.<br />
<br />
For the credit line to become two-ways, Bob would need to open an aUSD and place an offer &quot;I buy up to X aUSD for bUSDs&quot;.<br />
<br />
<br />
-----<br />
<br />
<br>Potential UI sequence:<br />
<br />
# ALICE clicks &quot;Give Credit to,” and then she selects &quot;BOB&quot; from a list.<br />
# BOB logs in the next day, with a message &quot;Alice has extended credit to you in the amount of $100 USD. Do you accept?&quot; (This means that some sort of message will be sent via the internal OT message system, to facilitate this notification.)<br />
# When Bob clicks yes, then the software checks to see if Bob has already issued his own $bUSD currency. If not, then Bob's currency bUSD is automatically issued at this time. (Bob's &quot;credit line&quot; object will need to manage his issuer accounts for various currencies,as well as manage a list of his credit lines to and from other people, as well as his asset accounts from those people, as well as his bUSD internal asset account, as well as his Ripple market offers. This OTCreditLine object would need to be written.)<br />
# Alice's offer is created on the new aUSD/bUSD market: &quot;I buy up to 100 bUSD for aUSDs at X:Y rate&quot;. (This could probably be done using a modified version of the existing OT market code, to enable to atomic transactions. This modified version would be specially for Ripple, due to the atomic-multi-step transactions.)<br />
# This means that aUSDs, Alice's own USD currency must ALSO be issued at this time, if they haven't been already.<br />
# This means that Y aUSDs (from X:Y) must actually be issued into existence by Alice at this same time. That is, not only is the currency in existence, but say, 100 units of that currency are actually transferred at this time from Alice's aUSD issuer acct, leaving it at -100, to Alice's aUSD credit line account leaving it at +$100, so that they are actually available to fill her bUSD market offer, should a &quot;Ripple path&quot; transaction occur.<br />
<br />
(This means Alice has an internal account balance of $100 aUSD.)<br />
<br />
<ol start="7" style="list-style-type: decimal;"><br />
<li><p>Unlike Bob's silver account, which is private to him, and unlike Bob's gold account, which is private to him, Alice can actually SEE the contents of Bob's aUSD account! Because that shows her how much USD that she owes to Bob. This is unlike the normal OT accounts, where you are not shown other people's balances.</p></li><br />
<li><p>On Alice's &quot;Credit Lines&quot; page, she would have a list of currencies (Dollars, Bitcoins, Silver, etc.) When she clicks on a currency, say dollars, the details appear on the right:</p></li><br />
<li><p>Details: a list of credit lines. Bob, Carol, Donald, Edward, etc.</p></li><br />
<li><p>Alice's &quot;total dollars owed&quot; is the absolute value of her aUSD issuer account. So if her aUSD issuer account has -$2000, then she owes $2000 to all of her various friends (in TOTAL.)</p></li><br />
<li><p>For Bob, Carol, Edward, etc, she sees THEIR balances in aUSD:</p></li></ol><br />
<br />
{| class="wikitable"<br />
||||ALICE OWES THEM <br />
|-<br />
|Bob||$A 0 <br />
|-<br />
|Carol||$A 1000<br />
|- <br />
|Donald||$A 500<br />
|- <br />
|Edward||$A 500<br />
|}<br />
<br />
<ol start="12" style="list-style-type: decimal;"><br />
<li>She also sees HER balances in bUSD/cUSD/dUSD/eUSD:</li></ol><br />
<br />
{| class="wikitable"<br />
||||ALICE OWES||THEY OWE ALICE<br />
|-<br />
|Bob||$A 0||$0 bUSD<br />
|-<br />
|Carol||$A 1000||$877 cUSD<br />
|-<br />
|Donald||$A 500||$142 dUSD<br />
|-<br />
|Edward||$A 500||$905 eUSD<br />
|}<br />
<br />
Total owed BY Alice: $2000 Total owed TO Alice: $1924<br />
<br />
Net: Alice owes $76.<br />
<br />
-----<br />
<br />
<ol start="13" style="list-style-type: decimal;"><br />
<li>Alice should also see the CURRENT STATUS of her MARKET OFFERS. Above we only see the account balances (what is owed both ways) but we don't see what people are willing to CONVERT.</li></ol><br />
<br />
Let's say Alice and Bob are willing to convert $100 both ways (for each other):<br />
<br />
Alice: OFFER: &quot;I buy up to 100 bUSD for aUSDs&quot;<br />
<br />
Alice: INTERNAL: $100 aUSD<br />
<br />
(To trade $100, this means Alice has an internal account balance of $100 aUSD at least, and -$100 of her aUSD issuer account matches to this. Her market offers trade against this account.)<br />
<br />
Bob: OFFER: &quot;I buy up to 100 aUSD for bUSDs&quot;<br />
<br />
Bob: INTERNAL: $100 bUSD<br />
<br />
(This means Bob has an internal account balance of $100 bUSD at least, and -$100 of his bUSD issuer account matches to this. His market offers trade against this account.)<br />
<br />
<br />
-----<br />
<br />
<ol start="14" style="list-style-type: decimal;"><br />
<li>THEREFORE our total picture now looks like this:</li></ol><br />
<br />
{| class="wikitable"<br />
||||ALICE OWES||THEY OWE ALICE<br />
|-<br />
|Bob:||$A 0||$0 bUSD<br />
|-<br />
|Carol:||$A 1000||$877 cUSD<br />
|-<br />
|Donald:||$A 500||$142 dUSD <br />
|-<br />
|Edward:||$A 500||$905 eUSD<br />
|}<br />
<br />
Total owed BY Alice: $2000 <br />
<br>Total owed TO Alice: $1924 <br />
<br>Net: Alice owes $76.<br />
<br />
Alice: OFFER: &quot;I buy up to 100 bUSD for aUSDs&quot; <br />
<br>Alice: INTERNAL: $100 aUSD<br />
<br />
Bob: OFFER: &quot;I buy up to 100 aUSD for bUSDs&quot; <br />
<br>Bob: INTERNAL: $100 bUSD<br />
<br />
<br />
-----<br />
<br />
<ol start="15" style="list-style-type: decimal;"><br />
<li>Let's say a &quot;Ripple&quot; flows through and she converts HALF OF the bUSD she's willing to convert. How does our picture CHANGE?</li></ol><br />
<br />
{| class="wikitable"<br />
||||ALICE OWES||THEY OWE ALICE<br />
|-<br />
|Bob:||$A 0||$50 bUSD *<br />
|-<br />
|Carol:||$A 1000||$877 cUSD<br />
|-<br />
|Donald:||$A 500||$142 dUSD<br />
|-<br />
|Edward:||$A 500||$905 eUSD<br />
|}<br />
<br />
<br />
Total owed BY Alice: $2000 <br />
<br>Total owed TO Alice: $1974 <br />
<br>Net: Alice owes $26.<br />
<br />
Alice: OFFER: &quot;I buy up to 50 bUSD for aUSDs&quot; <br />
<br>Alice: INTERNAL: $50 aUSD<br />
<br />
Bob: OFFER: &quot;I buy up to 100 aUSD for bUSDs&quot; <br />
<br>Bob: INTERNAL: $100 bUSD<br />
<br />
QUESTION: Should Bob be able to see how much is LEFT on Alice's offer?<br />
<br />
That is: &quot;Alice's bUSD acct contains $50, which you owe to her, and there is still $50 left on her total credit line to you (of $100.)&quot;<br />
<br />
<br />
-----<br />
<br />
<br>NEXT QUESTION: How does this model ever CONVERT one currency to another?<br />
<br />
SO FAR, the creation of a CREDIT LINE has only resulted in two-way USD relationships, or two-way Gold relationships, etc.<br />
<br />
NOTHING in the above example shows where Alice converts Dollars to Gold, or Dollars to Bitcoin.<br />
<br />
FOR EXAMPLE, Let's say Alice extends GOLD credit to Bob…<br />
<br />
Even if Bob reciprocates, then they have 100g gold relationship both ways, complete with Alice's offer to buy bGold using aGold, and Bob's offer to buy aGold using bGold.<br />
<br />
STILL this doesn't explain how dollars get converted into gold, EVEN THOUGH ALICE AND BOB BOTH DEAL IN DOLLARS AND BOTH DEAL IN GOLD.<br />
<br />
===&gt; It's not ENOUGH for Alice and Bob to handle both gold and dollars, and to extend credit to each other in gold and dollars. ON TOP OF THIS, Alice must also be willing to convert gold into dollars, and dollars into gold, AND THIS HAS NOTHING TO DO WITH HER CREDIT RELATIONSHIPS TO BOB OR TO ANYONE ELSE. Rather, it has more to do with her market judgments of the various currencies.<br />
<br />
===&gt;Therefore, there still needs to be ANOTHER page, where Alice can set up her CONVERSION RATIOS between gold=&gt;dollars and dollars=&gt;gold, and BTC=&gt;dollars and dollars=&gt;BTC, etc.<br />
<br />
It seems to me that the &quot;Ripple path&quot; mechanism would need to make use of markets that included offers for the credit lines, as well as offers for the currency conversion, before it could operate properly.</div>Cryptomanhttp://opentransactions.org/wiki/index.php?title=About&diff=91About2013-06-11T18:36:35Z<p>Cryptoman: </p>
<hr />
<div>'''What is OPEN-TRANSACTIONS?'''<br />
<br />
* Open-Transactions is an [[Use Cases|easy-to-use]], financial crypto, [[Sample Cash|digital cash]] and transaction [[List of Classes|library]].<br />
* Open-Transactions includes a '''[[API|client API]]''', a working '''[[OT-Server|server]]''', a '''[[TestGUI|GUI test wallet]]''' (in Java) and a [[opentxs|command-line]] wallet utility.<br />
* Open-Transactions features: a large variety of financial instruments, markets, basket currencies, unforgeable account balances, '''untraceable digital cash,''' destruction of account history, [http://iang.org/papers/ricardian_contract.html Ricardian contracts], Smart Contracts (scriptable clauses), and more.<br />
<br />
'''WHAT DOES IT DO?'''<br />
<br />
* '''Open-Transactions allows users to issue and manipulate digital assets.'''<br />
* Any issuer can sign and distribute new [[Sample Currency Contract|currency contracts]] in order to create new digital asset types.<br />
* Users may create many ''pseudonyms'' (public keys), each of which may own ''asset accounts'' of various types, on OT servers.<br />
* Users can operate '''&quot;cash-only&quot;''' ''(without accounts)'' for maximum anonymity, using '''[[Sample Cash|untraceable digital cash]]'''.<br />
<br />
-----<br />
<br />
'''NEW: GUI Mock-Ups! (first draft)'''<br />
<br />
[https://www.fluidui.com/editor/live/preview/p_8ZN0r9Pbp2XzPC7yL3lDFw5lW2L7vEye.1343824445082 standard mode]<br />
<br />
[https://www.fluidui.com/editor/live/preview/p_XcN9TmQ5FItuPr5QctxES2XfAhinsVPp.1343659566990 advanced mode]<br />
<br />
[http://www.reddit.com/r/Agorism/comments/19p6oa/how_to_issue_your_own_currency_using/ Install via apt-get (click here)]<br />
<br />
-----<br />
<br />
'''Radio Interview'''<br />
<br />
[http://agoristradio.com/?p=234 Part 1, courtesy of AgoristRadio]<br />
<br />
[http://agoristradio.com/?p=246 Part 2, courtesy of AgoristRadio]<br />
<br />
Bitcoin donation address: 1NtTPVVjDsUfDWybS4BwvHpG2pdS9RnYyQ<br />
<br />
IRC: #opentransactions at irc.freenode.net<br />
<br />
-----<br />
<br />
'''Video Walkthru''' <br />
<br />
[http://vimeo.com/28141679 Video 1 posted by J. Orlin Grabbe]<br />
<br />
[http://vimeo.com/28142096 Video 2 posted by J. Orlin Grabbe]<br />
<br />
[http://open-transactions.github.io/tv/ New videos!]<br />
<br />
-----<br />
<br />
'''FINANCIAL INSTRUMENTS'''<br />
<br />
* Users can transfer digital assets ''securely and provably'', with [[Triple-Signed Receipts|receipts]] signed by all parties.<br />
* '''Even an OT server cannot change balances, or forge transactions--since it cannot forge your signature on your receipt.'''<br />
* Open-Transactions supports a range of '''[[Instruments|financial instruments]]''' such as account transfer, '''[[Sample-Cheque|cheques]]''' and vouchers (aka &quot;cashier's cheques&quot; or &quot;banker's cheques&quot;), in addition to cash.<br />
* 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.<br />
<br />
-----<br />
<br />
'''Diagrams:'''<br />
<br />
[http://billstclair.com/ot/ot-diagram.jpg Architecture Overview]<br />
<br />
[http://billstclair.com/ot/OT-Anon-CashOnly.jpg Fully-Anonymous (cash only)]<br />
<br />
[http://billstclair.com/ot/OT-Pseudonym-Instruments.jpg Pseudo-Anonymous (using accounts)]<br />
<br />
-----<br />
<br />
'''MARKETS, BASKET CURRENCIES, and SMART CONTRACTS'''<br />
<br />
* Open-Transactions also implements higher-level, '''contract-based transactions''' such as '''payment plans''' and '''markets with trades'''.<br />
* 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.<br />
* '''Basket currencies''' are also supported, as well as payment plans (recurring payments.)<br />
* [[Smart contracts]]: Multi-party agreements with scriptable clauses... including hooks, callbacks, internal state, etc.<br />
* [[Client-side scripting]]: <code>!/usr/bin/env ot</code> The entire (mostly) high and low level OT API is available within your scripts.<br />
<br />
-----<br />
<br />
'''TRIPLE SIGNED RECEIPTS'''<br />
<br />
* 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'''.<br />
* Without the special mechanism that makes this possible, ''all parties would otherwise be forced to store all receipts forever''.<br />
* Nyms and Asset Types have consistent IDs across all OT servers, since the ID is formed by hashing the relevant contract or public key.<br />
<br />
-----<br />
<br />
The real beauty of Open-Transactions is the as-yet-unwritten future of ''new ideas'' that you can build with it, and the future liberty and security of your children that you can help to protect by doing so--in a very real and tangible way.<br />
<br />
-----<br />
<br />
'''IS Open-Transactions [[CENTRALIZED]]?'''<br />
<br />
'''The vision is not of a central server that you must trust.''' '''Rather, the vision is of federated servers you don't have to trust.'''<br />
<br />
-----<br />
<br />
'''Mailing list''': open-transactions-subscribe@rayservers.com<br />
<br />
'''[[FAQ]]'''<br />
<br />
'''[[Components and GNU Licensing|Components]]'''<br />
<br />
'''[[Installation|Install Notes]]'''<br />
<br />
'''[[Use Cases]]'''<br />
<br />
'''[[API]]'''<br />
<br />
'''[[Business Cases]]'''<br />
<br />
'''[[Release Notes]]'''<br />
<br />
-----<br />
<br />
The server itself is a [[Transactions|transaction processor]] in the cypherpunk tradition. In more detail:<br />
<br />
* Many '''financial instruments''' are supported: Users can write '''cheques''', purchase '''cashier's cheques''' (&quot;vouchers&quot;), and withdraw in '''[[Sample Cash|untraceable digital cash]]'''. The software uses Chaumian-style, blinded tokens courtesy of the [http://anoncvs.aldigital.co.uk/lucre/ Lucre] library by Ben Laurie.<br />
* 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.<br />
* 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''.<br />
* '''Any user can issue new digital currencies''' and digital asset types, by uploading the new [currency contract] to the server. (This functionality is comparable to [http://www.systemics.com/docs/sox/overview.html Ricardo] by [http://financialcryptography.com/ Ian Grigg].)<br />
* '''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 Chkeroff.)<br />
* [[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].)<br />
* 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'''.<br />
* 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'''.)<br />
* [[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].<br />
* [[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><br />
* 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.)<br />
* '''Contracts''', in general, are very important to Open Transactions; they are the building block of the entire library. Open Transactions uses a Ricardian-style contract, and all the various instruments, data files, and messages resemble '''[[PGP-signed XML files|Currency Contract]]'''. All objects serialize to a string.<br />
* 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 [https://github.com/FellowTraveler/Open-Transactions/wiki/Auditing auditing protocol].<br />
* 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.<br />
* '''All communications are secured with OpenSSL.''' All messages are also signed and encrypted. All transactions require signatures from relevant parties including the server.<br />
* 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.)<br />
* The software is fully '''cross-platform''': '''Linux, Mac OS X, FreeBSD, Android, and Windows''' are supported with makefiles, project files, and instructions.<br />
* 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.'''<br />
* [[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.<br />
* OT currently supports '''MsgPack''' and '''protobuf''' for data packing, though new packers can be added by subclassing OTDB::Packer.<br />
<br />
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>Cryptomanhttp://opentransactions.org/wiki/index.php?title=About&diff=90About2013-06-11T18:30:17Z<p>Cryptoman: </p>
<hr />
<div>'''What is OPEN-TRANSACTIONS?'''<br />
<br />
* Open-Transactions is an [[Use Cases|easy-to-use]], financial crypto, [[Sample Cash|digital cash]] and transaction [[List of Classes|library]].<br />
* Open-Transactions includes a '''[[API|client API]]''', a working '''[[OT-Server|server]]''', a '''[[TestGUI|GUI test wallet]]''' (in Java) and a [[opentxs|command-line]] wallet utility.<br />
* Open-Transactions features: a large variety of financial instruments, markets, basket currencies, unforgeable account balances, '''untraceable digital cash,''' destruction of account history, [http://iang.org/papers/ricardian_contract.html Ricardian contracts], Smart Contracts (scriptable clauses), and more.<br />
<br />
'''WHAT DOES IT DO?'''<br />
<br />
* '''Open-Transactions allows users to issue and manipulate digital assets.'''<br />
* Any issuer can sign and distribute new [[Sample Currency Contract|currency contracts]] in order to create new digital asset types.<br />
* Users may create many ''pseudonyms'' (public keys), each of which may own ''asset accounts'' of various types, on OT servers.<br />
* Users can operate '''&quot;cash-only&quot;''' ''(without accounts)'' for maximum anonymity, using '''[[Sample Cash|untraceable digital cash]]'''.<br />
<br />
-----<br />
<br />
'''NEW: GUI Mock-Ups! (first draft)'''<br />
<br />
[https://www.fluidui.com/editor/live/preview/p_8ZN0r9Pbp2XzPC7yL3lDFw5lW2L7vEye.1343824445082 standard mode]<br />
<br />
[https://www.fluidui.com/editor/live/preview/p_XcN9TmQ5FItuPr5QctxES2XfAhinsVPp.1343659566990 advanced mode]<br />
<br />
[http://www.reddit.com/r/Agorism/comments/19p6oa/how_to_issue_your_own_currency_using/ Install via apt-get (click here)]<br />
<br />
-----<br />
<br />
'''Radio Interview'''<br />
<br />
[http://agoristradio.com/?p=234 Part 1, courtesy of AgoristRadio]<br />
<br />
[http://agoristradio.com/?p=246 Part 2, courtesy of AgoristRadio]<br />
<br />
Bitcoin donation address: 1NtTPVVjDsUfDWybS4BwvHpG2pdS9RnYyQ<br />
<br />
IRC: #opentransactions at irc.freenode.net<br />
<br />
-----<br />
<br />
'''Video Walkthru''' <br />
<br />
[http://vimeo.com/28141679 Video 1 posted by J. Orlin Grabbe]<br />
<br />
[http://vimeo.com/28142096 Video 2 posted by J. Orlin Grabbe]<br />
<br />
[http://open-transactions.github.io/tv/ New videos!]<br />
<br />
-----<br />
<br />
'''FINANCIAL INSTRUMENTS'''<br />
<br />
* Users can transfer digital assets ''securely and provably'', with [[Triple-Signed Receipts|receipts]] signed by all parties.<br />
* '''Even an OT server cannot change balances, or forge transactions--since it cannot forge your signature on your receipt.'''<br />
* Open-Transactions supports a range of '''[[Instruments|financial instruments]]''' such as account transfer, '''[[Sample-Cheque|cheques]]''' and vouchers (aka &quot;cashier's cheques&quot; or &quot;banker's cheques&quot;), in addition to cash.<br />
* 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.<br />
<br />
-----<br />
<br />
'''Diagrams:'''<br />
<br />
[http://billstclair.com/ot/ot-diagram.jpg Architecture Overview]<br />
<br />
[http://billstclair.com/ot/OT-Anon-CashOnly.jpg Fully-Anonymous (cash only)]<br />
<br />
[http://billstclair.com/ot/OT-Pseudonym-Instruments.jpg Pseudo-Anonymous (using accounts)]<br />
<br />
-----<br />
<br />
'''MARKETS, BASKET CURRENCIES, and SMART CONTRACTS'''<br />
<br />
* Open-Transactions also implements higher-level, '''contract-based transactions''' such as '''payment plans''' and '''markets with trades'''.<br />
* 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.<br />
* '''Basket currencies''' are also supported, as well as payment plans (recurring payments.)<br />
* [[Smart contracts]]: Multi-party agreements with scriptable clauses... including hooks, callbacks, internal state, etc.<br />
* [[Client-side scripting]]: <code>!/usr/bin/env ot</code> The entire (mostly) high and low level OT API is available within your scripts.<br />
<br />
-----<br />
<br />
'''TRIPLE SIGNED RECEIPTS'''<br />
<br />
* 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'''.<br />
* Without the special mechanism that makes this possible, ''all parties would otherwise be forced to store all receipts forever''.<br />
* Nyms and Asset Types have consistent IDs across all OT servers, since the ID is formed by hashing the relevant contract or public key.<br />
<br />
-----<br />
<br />
The real beauty of Open-Transactions is the as-yet-unwritten future of ''new ideas'' that you can build with it, and the future liberty and security of your children that you can help to protect by doing so--in a very real and tangible way.<br />
<br />
-----<br />
<br />
'''IS Open-Transactions [[CENTRALIZED]]?'''<br />
<br />
'''The vision is not of a central server that you must trust.''' '''Rather, the vision is of federated servers you don't have to trust.'''<br />
<br />
-----<br />
<br />
'''Mailing list''': open-transactions-subscribe@rayservers.com<br />
<br />
'''[[FAQ]]'''<br />
<br />
'''[[Components and GNU Licensing|Components]]'''<br />
<br />
'''[[Installation|Install Notes]]'''<br />
<br />
'''[[Use Cases]'''<br />
<br />
'''[[API]]'''<br />
<br />
'''[[Business Cases]]'''<br />
<br />
'''[[Release Notes]]'''<br />
<br />
-----<br />
<br />
The server itself is a [[Transactions|transaction processor]] in the cypherpunk tradition. In more detail:<br />
<br />
* Many '''financial instruments''' are supported: Users can write '''cheques''', purchase '''cashier's cheques''' (&quot;vouchers&quot;), and withdraw in '''[[untraceable digital cash|digital cash]]'''. The software uses Chaumian-style, blinded tokens courtesy of the [http://anoncvs.aldigital.co.uk/lucre/ Lucre] library by Ben Laurie.<br />
* 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.<br />
* 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''.<br />
* '''Any user can issue new digital currencies''' and digital asset types, by uploading the new [currency contract] to the server. (This functionality is comparable to [http://www.systemics.com/docs/sox/overview.html Ricardo] by [http://financialcryptography.com/ Ian Grigg].)<br />
* '''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 Chkeroff.)<br />
* [[Triple Signed Receipts / No Account History|Triple Signed Receipts]]. 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].)<br />
* 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'''.<br />
* 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'''.)<br />
* [[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].<br />
* [[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><br />
* 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.)<br />
* '''Contracts''', in general, are very important to Open Transactions; they are the building block of the entire library. Open Transactions uses a Ricardian-style contract, and all the various instruments, data files, and messages resemble '''[[PGP-signed XML files|Currency Contract]]'''. All objects serialize to a string.<br />
* 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 [https://github.com/FellowTraveler/Open-Transactions/wiki/Auditing auditing protocol].<br />
* 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.<br />
* '''All communications are secured with OpenSSL.''' All messages are also signed and encrypted. All transactions require signatures from relevant parties including the server.<br />
* 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.)<br />
* The software is fully '''cross-platform''': '''Linux, Mac OS X, FreeBSD, Android, and Windows''' are supported with makefiles, project files, and instructions.<br />
* 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.'''<br />
* [[OTX Protocol|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.<br />
* OT currently supports '''MsgPack''' and '''protobuf''' for data packing, though new packers can be added by subclassing OTDB::Packer.<br />
<br />
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>Cryptomanhttp://opentransactions.org/wiki/index.php?title=About&diff=89About2013-06-11T18:24:54Z<p>Cryptoman: </p>
<hr />
<div>'''What is OPEN-TRANSACTIONS?'''<br />
<br />
* Open-Transactions is an [[Use Cases|easy-to-use]], financial crypto, [[Sample Cash|digital cash]] and transaction [[List of Classes|library]].<br />
* Open-Transactions includes a '''[[API|client API]]''', a working '''[[OT-Server|server]]''', a '''[[TestGUI|GUI test wallet]]''' (in Java) and a [[opentxs|command-line]] wallet utility.<br />
* Open-Transactions features: a large variety of financial instruments, markets, basket currencies, unforgeable account balances, '''untraceable digital cash,''' destruction of account history, [http://iang.org/papers/ricardian_contract.html Ricardian contracts], Smart Contracts (scriptable clauses), and more.<br />
<br />
'''WHAT DOES IT DO?'''<br />
<br />
* '''Open-Transactions allows users to issue and manipulate digital assets.'''<br />
* Any issuer can sign and distribute new [[Sample Currency Contract|currency contracts]] in order to create new digital asset types.<br />
* Users may create many ''pseudonyms'' (public keys), each of which may own ''asset accounts'' of various types, on OT servers.<br />
* Users can operate '''&quot;cash-only&quot;''' ''(without accounts)'' for maximum anonymity, using '''[[Sample Cash|untraceable digital cash]]'''.<br />
<br />
-----<br />
<br />
'''NEW: GUI Mock-Ups! (first draft)'''<br />
<br />
[https://www.fluidui.com/editor/live/preview/p_8ZN0r9Pbp2XzPC7yL3lDFw5lW2L7vEye.1343824445082 standard mode]<br />
<br />
[https://www.fluidui.com/editor/live/preview/p_XcN9TmQ5FItuPr5QctxES2XfAhinsVPp.1343659566990 advanced mode]<br />
<br />
[http://www.reddit.com/r/Agorism/comments/19p6oa/how_to_issue_your_own_currency_using/ Install via apt-get (click here)]<br />
<br />
-----<br />
<br />
'''Radio Interview'''<br />
<br />
[http://agoristradio.com/?p=234 Part 1, courtesy of AgoristRadio]<br />
<br />
[http://agoristradio.com/?p=246 Part 2, courtesy of AgoristRadio]<br />
<br />
Bitcoin donation address: 1NtTPVVjDsUfDWybS4BwvHpG2pdS9RnYyQ<br />
<br />
IRC: #opentransactions at irc.freenode.net<br />
<br />
-----<br />
<br />
'''Video Walkthru''' <br />
<br />
[http://vimeo.com/28141679 Video 1 posted by J. Orlin Grabbe]<br />
<br />
[http://vimeo.com/28142096 Video 2 posted by J. Orlin Grabbe]<br />
<br />
[http://open-transactions.github.io/tv/ New videos!]<br />
<br />
-----<br />
<br />
'''FINANCIAL INSTRUMENTS'''<br />
<br />
* Users can transfer digital assets ''securely and provably'', with [[Triple-Signed Receipts|receipts]] signed by all parties.<br />
* '''Even an OT server cannot change balances, or forge transactions--since it cannot forge your signature on your receipt.'''<br />
* Open-Transactions supports a range of '''[[Instruments|financial instruments]]''' such as account transfer, '''[[Sample-Cheque|cheques]]''' and vouchers (aka &quot;cashier's cheques&quot; or &quot;banker's cheques&quot;), in addition to cash.<br />
* 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.<br />
<br />
-----<br />
<br />
'''Diagrams:'''<br />
<br />
[http://billstclair.com/ot/ot-diagram.jpg Architecture Overview]<br />
<br />
[http://billstclair.com/ot/OT-Anon-CashOnly.jpg Fully-Anonymous (cash only)]<br />
<br />
[http://billstclair.com/ot/OT-Pseudonym-Instruments.jpg Pseudo-Anonymous (using accounts)]<br />
<br />
-----<br />
<br />
'''MARKETS, BASKET CURRENCIES, and SMART CONTRACTS'''<br />
<br />
* Open-Transactions also implements higher-level, '''contract-based transactions''' such as '''payment plans''' and '''markets with trades'''.<br />
* 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.<br />
* '''Basket currencies''' are also supported, as well as payment plans (recurring payments.)<br />
* [[Smart contracts]]: Multi-party agreements with scriptable clauses... including hooks, callbacks, internal state, etc.<br />
* [[Client-side scripting]]: @#!/usr/bin/env ot@ The entire (mostly) high and low level OT API is available within your scripts.<br />
<br />
-----<br />
<br />
'''TRIPLE SIGNED RECEIPTS'''<br />
<br />
* 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'''.<br />
* Without the special mechanism that makes this possible, ''all parties would otherwise be forced to store all receipts forever''.<br />
* Nyms and Asset Types have consistent IDs across all OT servers, since the ID is formed by hashing the relevant contract or public key.<br />
<br />
-----<br />
<br />
The real beauty of Open-Transactions is the as-yet-unwritten future of ''new ideas'' that you can build with it, and the future liberty and security of your children that you can help to protect by doing so--in a very real and tangible way.<br />
<br />
-----<br />
<br />
'''IS Open-Transactions [[CENTRALIZED]]?'''<br />
<br />
'''The vision is not of a central server that you must trust.''' '''Rather, the vision is of federated servers you don't have to trust.'''<br />
<br />
-----<br />
<br />
'''Mailing list''': open-transactions-subscribe@rayservers.com<br />
<br />
''[[FAQ]]''<br />
<br />
''[[Components and GNU Licensing|Components]]''<br />
<br />
''[[Installation]]''<br />
<br />
''[[API]]''<br />
<br />
''[[Business Cases]]''<br />
<br />
''[[Release Notes]]''<br />
<br />
-----<br />
<br />
The server itself is a [[Transactions|transaction processor]] in the cypherpunk tradition. In more detail:<br />
<br />
* Many '''financial instruments''' are supported: Users can write '''cheques''', purchase '''cashier's cheques''' (&quot;vouchers&quot;), and withdraw in '''[[untraceable digital cash|digital cash]]'''. The software uses Chaumian-style, blinded tokens courtesy of the [http://anoncvs.aldigital.co.uk/lucre/ Lucre] library by Ben Laurie.<br />
* 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.<br />
* 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''.<br />
* '''Any user can issue new digital currencies''' and digital asset types, by uploading the new [currency contract] to the server. (This functionality is comparable to [http://www.systemics.com/docs/sox/overview.html Ricardo] by [http://financialcryptography.com/ Ian Grigg].)<br />
* '''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 Chkeroff.)<br />
* [[Triple Signed Receipts / No Account History|Triple Signed Receipts]]. 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].)<br />
* 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'''.<br />
* 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'''.)<br />
* [[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].<br />
* [[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><br />
* 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.)<br />
* '''Contracts''', in general, are very important to Open Transactions; they are the building block of the entire library. Open Transactions uses a Ricardian-style contract, and all the various instruments, data files, and messages resemble '''[[PGP-signed XML files|Currency Contract]]'''. All objects serialize to a string.<br />
* 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 [https://github.com/FellowTraveler/Open-Transactions/wiki/Auditing auditing protocol].<br />
* 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.<br />
* '''All communications are secured with OpenSSL.''' All messages are also signed and encrypted. All transactions require signatures from relevant parties including the server.<br />
* 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.)<br />
* The software is fully '''cross-platform''': '''Linux, Mac OS X, FreeBSD, Android, and Windows''' are supported with makefiles, project files, and instructions.<br />
* 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.'''<br />
* [[OTX Protocol|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.<br />
* OT currently supports '''MsgPack''' and '''protobuf''' for data packing, though new packers can be added by subclassing OTDB::Packer.<br />
<br />
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>Cryptomanhttp://opentransactions.org/wiki/index.php?title=Instruments&diff=88Instruments2013-06-11T18:20:17Z<p>Cryptoman: Created page with "Open Transactions supports different types of financial instruments... * '''account transfer''' (a signed message, given to the bank, asking to transfer funds to another acco..."</p>
<hr />
<div>Open Transactions supports different types of financial instruments...<br />
<br />
* '''account transfer''' (a signed message, given to the bank, asking to transfer funds to another account),<br />
* '''[[Sample-Cheque|digital cheque]]''' (a signed message, given to the recipient, authorizing bank to transfer funds when presented),<br />
* '''digital vouchers''' (like a cashier's cheque. Funds are transferred to bank, who then issues a cheque. Bank becomes payer),<br />
* '''[[Sample Cash|digital cash]]''' (Like a real cash withdrawal. Funds are transferred to bank, who then issues untraceable bearer certificates),<br />
* NEW: Now supporting markets (with trades) and payment plans.<br />
<br />
Here's a little chart to show some of the differences between these instruments:<br />
<br />
{| class="wikitable"<br />
!rowspan=2 | '''CHARACTERISTICS OF INSTRUMENT'''<br />
!colspan=4 | '''INSTRUMENT TYPE'''<br />
|-<br />
| align="center" style="background:#f0f0f0;"|'''DIGITAL CASH'''<br />
| align="center" style="background:#f0f0f0;"|'''ACCT TRANSFER'''<br />
| align="center" style="background:#f0f0f0;"|'''CHEQUE'''<br />
| align="center" style="background:#f0f0f0;"|'''VOUCHER'''<br />
|-<br />
|Can have a specific recipient: <br />
|NO <br />
|YES <br />
|YES <br />
|YES<br />
|-<br />
|Must have a specific recipient:<br />
|NO<br />
|YES<br />
|NO<br />
|NO<br />
|-<br />
|Can have a blank recipient:<br />
|YES<br />
|NO<br />
|YES<br />
|YES<br />
|-<br />
|Must have a blank recipient:<br />
|YES<br />
|NO<br />
|NO<br />
|NO<br />
|-<br />
|Can be cancelled by sender:<br />
|NO<br />
|YES^<br />
|YES^<br />
|YES^<br />
|-<br />
||||||||||<br />
|-<br />
|Creating instrument removes funds:<br />
|YES<br />
|YES<br />
|NO<br />
|YES<br />
|-<br />
|Payer has "benefit of float":<br />
|NO<br />
|NO<br />
|YES<br />
|NO<br />
|-<br />
||||||||||<br />
|-<br />
|Instrument might bounce:<br />
|NO<br />
|NO<br />
|YES<br />
|NO<br />
|-<br />
|Instrument might be already spent:<br />
|YES<br />
|NO<br />
|YES<br />
|YES<br />
|-<br />
||||||||||<br />
|-<br />
|Guarantee of receipt:<br />
|NO<br />
|YES<br />
|YES<br />
|YES<br />
|-<br />
|Guarantee of funds (when good):<br />
|YES<br />
|YES<br />
|NO<br />
|YES<br />
|-<br />
|||||||||| <br />
|-<br />
|Instrument created online:<br />
|YES<br />
|YES<br />
|NO<br />
|YES<br />
|-<br />
|Payment must be online:<br />
|NO<br />
|YES<br />
|NO<br />
|NO<br />
|-<br />
|Instrument verified online:<br />
|YES<br />
|YES<br />
|YES<br />
|YES<br />
|-<br />
|||||||||| <br />
|-<br />
|Has an expiration date:<br />
|YES<br />
|NO<br />
|YES<br />
|YES<br />
|-<br />
|Money kept by bank upon expire:<br />
|YES<br />
|NO EXPIRY<br />
|NO<br />
|YES<br />
|-<br />
|Money kept by user upon expire:<br />
|NO<br />
|NO EXPIRY<br />
|YES<br />
|NO<br />
|-<br />
||||||||||<br />
|-<br />
|Record created when instrument is:<br />
|NO<br />
|YES<br />
|NO<br />
|YES<br />
|-<br />
|Sending a payment creates a record:<br />
|NO<br />
|YES<br />
|NO<br />
|NO<br />
|-<br />
|Accepting a payment creates a record:<br />
|YES^^^<br />
|YES<br />
|YES<br />
|YES<br />
|-<br />
|||||||||| <br />
|-<br />
|Untraceable to recipient:<br />
|YES<br />
|NO<br />
|NO<br />
|YES^^<br />
|-<br />
|Untraceable to ANYONE:<br />
|YES<br />
|NO<br />
|NO<br />
|NO <br />
|}<br />
<br />
^ Assuming it is canceled '''before''' it’s accepted by the recipient. (Once a transfer is accepted, or a cheque is cashed, it cannot be canceled anymore.)<br />
<br />
^^ Unlike digital cash, (which is untraceable by anyone), digital vouchers '''are''' traceable by the bank, '''but''' the information is hidden from the recipient, who instead sees the bank as the sender, just like a cashier’s check. (In the case of a voucher, the recipient could serve the bank with a subpoena to find out the sender’s identity. But with cash, he could not—that becomes impossible.)<br />
<br />
^ ^ ^ When you receive a digital cash payment, you will most likely want to deposit it immediately, or exchange it for a new token, just to make sure your money is safe. When you do this, the bank doesn't know where the token came from, and it has no way of knowing who you will eventually spend it to. It also has no way of knowing whether you just received this token, or whether you are just exchanging the same one over and over again (or whether you are exchanging a pre-existing token from your wallet that was about to expire.)<br />
<br />
'''BUT''' the bank can still make a record that you exchanged a token, which is why I say here that a record could be created with cash, even though I also say that it is untraceable. Remember, the tokens all have the same expiration dates, they all have the same denominations, and the bank cannot see where they came from, and the bank cannot see where they are going, and the bank cannot prove how much of them you actually have.<br />
<br />
'''UPDATE''' But!!! the bank can provide a web interface over HTTPS for exchanging tokens, so that even people who are so paranoid they don't even want to even OPEN an account at all can STILL receive tokens, exchange them, and use them for payments. This easily satisfies the &quot;bearer-only&quot; crowd: as long as the https interface is operated by the same entity as the transaction processor, ''you don't have to open an account at all.'' (See main wiki page for a link to a diagram showing this &quot;full-anonymous&quot; mode.)<br />
<br />
<br />
-----<br />
<br />
Here are some nice, graphical diagrams of some of the instruments ([http://www.systemics.com/docs/sox/overview.html these diagrams] are for the ''Ricardo'' transaction server).</div>Cryptomanhttp://opentransactions.org/wiki/index.php?title=Sample-Cheque&diff=87Sample-Cheque2013-06-11T17:40:24Z<p>Cryptoman: </p>
<hr />
<div>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 &quot;Cheque ID&quot; or &quot;spent cheque database&quot;.) 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.<br />
<br />
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...'''<br />
<br />
All of the financial instruments have different properties... I invite you to check out the chart on the [[Instruments]] page and see for yourself.<br />
<br />
SAMPLE CHEQUE:<br />
<br />
<pre><br />
-----BEGIN SIGNED CHEQUE-----<br />
Hash: SAMY<br />
<br />
&lt;?xml version=&quot;1.0&quot;?&gt;<br />
<br />
&lt;cheque<br />
version=&quot;1.0&quot;<br />
amount=&quot;72&quot;<br />
assetTypeID=&quot;XUHBvdsWAEmErZMzHaRKaNPaAVsUvKwL4uLY4nOY2s4&quot;<br />
transactionNum=&quot;343&quot;<br />
serverID=&quot;44FmyPAgrmGu671RywGnhrt8aR6tzmNFn9WKQ92BXn&quot;<br />
senderAcctID=&quot;PhmhKernutijMa2XXxH1dZnTluIDQUVn1tifSOq9H4x&quot;<br />
senderUserID=&quot;Bg2QrSTomOEU5ICfvhfYfBYxQZPktDSnaVPpMLYxUnz&quot;<br />
hasRecipient=&quot;true&quot;<br />
recipientUserID=&quot;Bg2QrSTomOEU5ICfvhfYfBYxQZPktDSnaVPpMLYxUnz&quot;<br />
validFrom=&quot;1281783321&quot;<br />
validTo=&quot;1281783921&quot; &gt;<br />
<br />
&lt;memo&gt;<br />
eJzzSC1KVShPVUjPV0hMT8zMU2QAADncBbg=<br />
&lt;/memo&gt;<br />
<br />
&lt;/cheque&gt;<br />
-----BEGIN CHEQUE SIGNATURE-----<br />
DYPJjCc9LIpz/9B8aBPDrVsJBtvjt+737rWiMDDVYAhcnvb+PAuI4K3sM49W/WYJ<br />
DKVKA9bawxd4w7KWlmibYM5X8nYr40s+H+6dyvD5C1mXAg1jjlm+XWl/JtvVxP2w<br />
/DCmXPXgukYppTSkgHIrYn7E/Ong3nh62fGDwU+Aqfw=<br />
-----END CHEQUE SIGNATURE-----<br />
</pre><br />
<br />
<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 />
<br><br />
-----<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.<br />
<br />
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 &quot;pay by cheque&quot; 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.<br />
<br />
SAMPLE VOUCHER:<br />
<br />
<pre><br />
-----BEGIN SIGNED VOUCHER-----<br />
Hash: SAMY<br />
<br />
&lt;?xml version=&quot;1.0&quot;?&gt;<br />
<br />
&lt;cheque<br />
version=&quot;1.0&quot;<br />
amount=&quot;73&quot;<br />
assetTypeID=&quot;XUHBvdsWAEmErZMzHaRKaNPaAVsUvKwL4uLY4nOY2s4&quot;<br />
transactionNum=&quot;417&quot;<br />
serverID=&quot;44FmyPAgrmGu671RywGnhrt8aR6tzmNFn9WKQ92BXn&quot;<br />
senderAcctID=&quot;khlj2LLL9EYxPimNR4yAYDDzO5QzSg7LSxxsGc1RpsP&quot;<br />
senderUserID=&quot;LG4bi40PAw6vlkU5TXiphXqmEELf3k1gjMsKQVjw7SE&quot;<br />
hasRecipient=&quot;false&quot;<br />
recipientUserID=&quot;&quot;<br />
validFrom=&quot;1281868590&quot;<br />
validTo=&quot;1297420590&quot; &gt;<br />
<br />
&lt;memo&gt;<br />
eJwLzyzJSClKLFcIyy9NzkgtslJQ4HIqrczMS1dIVCiDiOkoFGfkl+akKJTnF2Ur<br />
MgAA18ERtQ==<br />
&lt;/memo&gt;<br />
<br />
&lt;/cheque&gt;<br />
-----BEGIN VOUCHER SIGNATURE-----<br />
HNufQ742X0pMwu5rQwtHQVXeQ0rJ9fu2ZirZ0rdTy9RXhSTWQY4YNR6F8YWScIfZ<br />
/dv+mW8LNg5eUCBmSiDEN0jLLImEnVY2wpVtqAxMGGbXxHxU9yI7RbsvSBxQHKTd<br />
tok7Sqn2syMlnAufszo+ScRXuvPWC8K51KgPxXTvBJI=<br />
-----END VOUCHER SIGNATURE-----<br />
</pre></div>Cryptomanhttp://opentransactions.org/wiki/index.php?title=Sample-Cheque&diff=86Sample-Cheque2013-06-11T17:39:55Z<p>Cryptoman: </p>
<hr />
<div>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 &quot;Cheque ID&quot; or &quot;spent cheque database&quot;.) 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.<br />
<br />
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...'''<br />
<br />
All of the financial instruments have different properties... I invite you to check out the chart on the [[Instruments]] page and see for yourself.<br />
<br />
SAMPLE CHEQUE:<br />
<br />
<pre><br />
-----BEGIN SIGNED CHEQUE-----<br />
Hash: SAMY<br />
<br />
&lt;?xml version=&quot;1.0&quot;?&gt;<br />
<br />
&lt;cheque<br />
version=&quot;1.0&quot;<br />
amount=&quot;72&quot;<br />
assetTypeID=&quot;XUHBvdsWAEmErZMzHaRKaNPaAVsUvKwL4uLY4nOY2s4&quot;<br />
transactionNum=&quot;343&quot;<br />
serverID=&quot;44FmyPAgrmGu671RywGnhrt8aR6tzmNFn9WKQ92BXn&quot;<br />
senderAcctID=&quot;PhmhKernutijMa2XXxH1dZnTluIDQUVn1tifSOq9H4x&quot;<br />
senderUserID=&quot;Bg2QrSTomOEU5ICfvhfYfBYxQZPktDSnaVPpMLYxUnz&quot;<br />
hasRecipient=&quot;true&quot;<br />
recipientUserID=&quot;Bg2QrSTomOEU5ICfvhfYfBYxQZPktDSnaVPpMLYxUnz&quot;<br />
validFrom=&quot;1281783321&quot;<br />
validTo=&quot;1281783921&quot; &gt;<br />
<br />
&lt;memo&gt;<br />
eJzzSC1KVShPVUjPV0hMT8zMU2QAADncBbg=<br />
&lt;/memo&gt;<br />
<br />
&lt;/cheque&gt;<br />
-----BEGIN CHEQUE SIGNATURE-----<br />
DYPJjCc9LIpz/9B8aBPDrVsJBtvjt+737rWiMDDVYAhcnvb+PAuI4K3sM49W/WYJ<br />
DKVKA9bawxd4w7KWlmibYM5X8nYr40s+H+6dyvD5C1mXAg1jjlm+XWl/JtvVxP2w<br />
/DCmXPXgukYppTSkgHIrYn7E/Ong3nh62fGDwU+Aqfw=<br />
-----END CHEQUE SIGNATURE-----<br />
</pre><br />
<br />
<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 />
-----<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.<br />
<br />
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 &quot;pay by cheque&quot; 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.<br />
<br />
SAMPLE VOUCHER:<br />
<br />
<pre><br />
-----BEGIN SIGNED VOUCHER-----<br />
Hash: SAMY<br />
<br />
&lt;?xml version=&quot;1.0&quot;?&gt;<br />
<br />
&lt;cheque<br />
version=&quot;1.0&quot;<br />
amount=&quot;73&quot;<br />
assetTypeID=&quot;XUHBvdsWAEmErZMzHaRKaNPaAVsUvKwL4uLY4nOY2s4&quot;<br />
transactionNum=&quot;417&quot;<br />
serverID=&quot;44FmyPAgrmGu671RywGnhrt8aR6tzmNFn9WKQ92BXn&quot;<br />
senderAcctID=&quot;khlj2LLL9EYxPimNR4yAYDDzO5QzSg7LSxxsGc1RpsP&quot;<br />
senderUserID=&quot;LG4bi40PAw6vlkU5TXiphXqmEELf3k1gjMsKQVjw7SE&quot;<br />
hasRecipient=&quot;false&quot;<br />
recipientUserID=&quot;&quot;<br />
validFrom=&quot;1281868590&quot;<br />
validTo=&quot;1297420590&quot; &gt;<br />
<br />
&lt;memo&gt;<br />
eJwLzyzJSClKLFcIyy9NzkgtslJQ4HIqrczMS1dIVCiDiOkoFGfkl+akKJTnF2Ur<br />
MgAA18ERtQ==<br />
&lt;/memo&gt;<br />
<br />
&lt;/cheque&gt;<br />
-----BEGIN VOUCHER SIGNATURE-----<br />
HNufQ742X0pMwu5rQwtHQVXeQ0rJ9fu2ZirZ0rdTy9RXhSTWQY4YNR6F8YWScIfZ<br />
/dv+mW8LNg5eUCBmSiDEN0jLLImEnVY2wpVtqAxMGGbXxHxU9yI7RbsvSBxQHKTd<br />
tok7Sqn2syMlnAufszo+ScRXuvPWC8K51KgPxXTvBJI=<br />
-----END VOUCHER SIGNATURE-----<br />
</pre></div>Cryptomanhttp://opentransactions.org/wiki/index.php?title=Sample-Cheque&diff=85Sample-Cheque2013-06-11T17:39:27Z<p>Cryptoman: Created page with "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 &quot;Cheque I..."</p>
<hr />
<div>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 &quot;Cheque ID&quot; or &quot;spent cheque database&quot;.) 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.<br />
<br />
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...'''<br />
<br />
All of the financial instruments have different properties... I invite you to check out the chart on the [[Instruments]] page and see for yourself.<br />
<br />
SAMPLE CHEQUE:<br />
<br />
<pre><br />
-----BEGIN SIGNED CHEQUE-----<br />
Hash: SAMY<br />
<br />
&lt;?xml version=&quot;1.0&quot;?&gt;<br />
<br />
&lt;cheque<br />
version=&quot;1.0&quot;<br />
amount=&quot;72&quot;<br />
assetTypeID=&quot;XUHBvdsWAEmErZMzHaRKaNPaAVsUvKwL4uLY4nOY2s4&quot;<br />
transactionNum=&quot;343&quot;<br />
serverID=&quot;44FmyPAgrmGu671RywGnhrt8aR6tzmNFn9WKQ92BXn&quot;<br />
senderAcctID=&quot;PhmhKernutijMa2XXxH1dZnTluIDQUVn1tifSOq9H4x&quot;<br />
senderUserID=&quot;Bg2QrSTomOEU5ICfvhfYfBYxQZPktDSnaVPpMLYxUnz&quot;<br />
hasRecipient=&quot;true&quot;<br />
recipientUserID=&quot;Bg2QrSTomOEU5ICfvhfYfBYxQZPktDSnaVPpMLYxUnz&quot;<br />
validFrom=&quot;1281783321&quot;<br />
validTo=&quot;1281783921&quot; &gt;<br />
<br />
&lt;memo&gt;<br />
eJzzSC1KVShPVUjPV0hMT8zMU2QAADncBbg=<br />
&lt;/memo&gt;<br />
<br />
&lt;/cheque&gt;<br />
-----BEGIN CHEQUE SIGNATURE-----<br />
DYPJjCc9LIpz/9B8aBPDrVsJBtvjt+737rWiMDDVYAhcnvb+PAuI4K3sM49W/WYJ<br />
DKVKA9bawxd4w7KWlmibYM5X8nYr40s+H+6dyvD5C1mXAg1jjlm+XWl/JtvVxP2w<br />
/DCmXPXgukYppTSkgHIrYn7E/Ong3nh62fGDwU+Aqfw=<br />
-----END CHEQUE SIGNATURE-----<br />
</pre><br />
<br />
<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 />
<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.<br />
<br />
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 &quot;pay by cheque&quot; 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.<br />
<br />
SAMPLE VOUCHER:<br />
<br />
<pre><br />
-----BEGIN SIGNED VOUCHER-----<br />
Hash: SAMY<br />
<br />
&lt;?xml version=&quot;1.0&quot;?&gt;<br />
<br />
&lt;cheque<br />
version=&quot;1.0&quot;<br />
amount=&quot;73&quot;<br />
assetTypeID=&quot;XUHBvdsWAEmErZMzHaRKaNPaAVsUvKwL4uLY4nOY2s4&quot;<br />
transactionNum=&quot;417&quot;<br />
serverID=&quot;44FmyPAgrmGu671RywGnhrt8aR6tzmNFn9WKQ92BXn&quot;<br />
senderAcctID=&quot;khlj2LLL9EYxPimNR4yAYDDzO5QzSg7LSxxsGc1RpsP&quot;<br />
senderUserID=&quot;LG4bi40PAw6vlkU5TXiphXqmEELf3k1gjMsKQVjw7SE&quot;<br />
hasRecipient=&quot;false&quot;<br />
recipientUserID=&quot;&quot;<br />
validFrom=&quot;1281868590&quot;<br />
validTo=&quot;1297420590&quot; &gt;<br />
<br />
&lt;memo&gt;<br />
eJwLzyzJSClKLFcIyy9NzkgtslJQ4HIqrczMS1dIVCiDiOkoFGfkl+akKJTnF2Ur<br />
MgAA18ERtQ==<br />
&lt;/memo&gt;<br />
<br />
&lt;/cheque&gt;<br />
-----BEGIN VOUCHER SIGNATURE-----<br />
HNufQ742X0pMwu5rQwtHQVXeQ0rJ9fu2ZirZ0rdTy9RXhSTWQY4YNR6F8YWScIfZ<br />
/dv+mW8LNg5eUCBmSiDEN0jLLImEnVY2wpVtqAxMGGbXxHxU9yI7RbsvSBxQHKTd<br />
tok7Sqn2syMlnAufszo+ScRXuvPWC8K51KgPxXTvBJI=<br />
-----END VOUCHER SIGNATURE-----<br />
</pre></div>Cryptomanhttp://opentransactions.org/wiki/index.php?title=Triple-Signed_Receipts&diff=84Triple-Signed Receipts2013-06-11T17:35:58Z<p>Cryptoman: Created page with "The idea to use ''balance agreement'' combined with ''transaction numbers'' in order to eliminate the storage (or need) of any account history (so-called '''''destruction of a..."</p>
<hr />
<div>The idea to use ''balance agreement'' combined with ''transaction numbers'' in order to eliminate the storage (or need) of any account history (so-called '''''destruction of account history''''') is inspired by [http://truledger.com/ Truledger] by [http://billstclair.com/blog/ Bill St Clair]. He has mentioned discussions with Patrick Chkeroff of [https://loom.cc/ Loom] as his muse in this area. The receipt itself becomes the &quot;account&quot;.<br />
<br />
Mr. St. Clair describes his protocol in this document: [http://truledger.com/doc/plain-english.html Truledger in Plain English.]<br />
<br />
<hr /><br />
<br />
The receipts on Open Transactions also take inspiration from the work of [http://financialcryptography.com/ Ian Grigg].<br />
<br />
Here is a great article on ''signed receipts'' by Ian Grigg himself, with diagrams: [http://iang.org/papers/triple_entry.html Triple Entry Accounting].<br />
<br />
Grigg's work, especially on [https://github.com/FellowTraveler/Open-Transactions/wiki/Sample-Currency-Contract Ricardian Contracts], is foundational to financial cryptography. (History will show...)<br />
<br />
<hr /><br />
<br />
What is interesting about '''Triple-Signed Receipts?'''<br />
<br />
Consider: If I sign cheque #45 and give it to someone who then cashes it, the money will come out of my account, and I'll get a receipt. And if that person tries to cash it again? No problem... the server can see that it already processed cheque #45, so it refuses to process it twice. I am protected. ''But only because the server, in this example, maintains a list of cleared cheque numbers'' (it had to store &quot;45&quot; somewhere on a list in order to handle this situation.) I am also relying on the server to &quot;play nice&quot; and only process cheques once. But what if the server ''itself'' is malicious? (Perhaps the cheque is made out to them, and they want to run it through multiple times, keeping the money each time.)<br />
<br />
In such a dispute, I'd say, ''&quot;Where is all my money?&quot;'' If they said, ''&quot;We don't know,&quot;'' but meanwhile my last receipt--with the server's signature on it--shows a balance of a thousand clams, yet the server has nothing else with my signature on it (to prove why the balance should have suddenly changed), then they are clearly liable for whatever money is missing.<br />
<br />
To avoid that situation, they'd have to say, ''&quot;The money went out from these 10 cheque payments.&quot;'' Of course they cannot prove such a claim without producing the signed cheque receipts. And when they do that, it will become instantly clear that the same cheque, number 45, was run through multiple times, and thus the transactions are all invalid. There is no escaping this discovery, since ''the server cannot forge my signature'' and therefore it cannot just put whatever transaction number it wants onto a cheque receipt.<br />
<br />
'''The point? Whether the server has to defend against malicious users running the cheque through twice, or whether I have to defend myself against a malicious server doing the same thing, ''either way, both sides are thus forced to store the transaction history forever, in order to cover their ass in the case of any dispute.''''' (You can set cheques aside, and examine any other instrument, and end up having to deal with similar conundrums.)<br />
<br />
IT'S TIME FOR A BETTER WAY: '''&quot;Destruction of Account History&quot;'''<br />
<br />
As Ian Grigg said, &quot;The receipt ''is'' the transaction.&quot;<br />
<br />
More: as Bill St. Clair has accomplished, the receipt is also the &quot;account&quot; itself. The receipt is proof of balance, ''and'' proof of which transactions are still outstanding (all others being closed.) The receipt is the account!<br />
<br />
Double-entry bookkeeping was a huge leap forward in the economic progress of the West, as it made it possible for balances to be proven and for fraudulent activity to be rooted out and pinned onto specific people. Unfortunately, as explained above, the storage of transaction history is a necessity for double-entry bookkeeping. If you do not have all of the transactions recorded, then you are no longer able to &quot;balance the books&quot;.<br />
<br />
Yet today we live in the age of strong crypto, where it is easy for the server to include a complete copy of my signed transaction request ''inside'' its own server-signed reply. I cannot prove anything later without producing that server reply, and if I do that, I will have thus also produced ''my'' original signed request, since a copy of it is included within.<br />
<br />
==&gt; '''If each of these receipts also includes a new, signed, ''balance agreement'', then it is no longer necessary for the server to store any previous transactions at all, since it already has my (unforgeable) signature on the current balance!'''<br />
<br />
===&gt; '''Furthermore, we can also prove which instruments are still valid, and which transactions are still open, by simply including a list of those transaction numbers on the same signed receipt!'''<br />
<br />
Even when a cheque has a valid signature on it, it's no longer valid after it's been cashed, right? The signature, by itself, is not enough. There must be something beyond the signature which helps us to prove whether or not the cheque is ''currently authorized'' -- not just for cheques, mind you, but for ''all'' financial instruments.<br />
<br />
Here's how OT solves this problem: All transactions must be accompanied by a valid transaction number. Meaning, if you want to be able to write cheques, withdraw cash, and so on, then you need to have a pile of transaction numbers in your wallet. (That you already loaded up some time in the past.)<br />
<br />
So by the time I wrote cheque #45, that means #45 was already signed out to me. I am now responsible for #45 until I sign off on its ''final receipt'' to close out the transaction (that receipt will appear, fyi, in my inbox whenever the cheque eventually gets cashed by the endorsee.)<br />
<br />
This means that #45 will be on ''every balance agreement I sign'', for ''every'' transaction, and will ''continue to appear'' on every &quot;last signed receipt&quot; that I get, until whenever #45 is finally closed out. Until that happens, all of my receipts will show that I am still responsible for cheque #45. Furthermore, when the cheque is cashed, a receipt will pop into my inbox, showing for example &quot;Cheque #45 in the amount of 100 clams&quot; -- and this data will ALSO be on every balance agreement that I sign (until I close it out of my inbox by signing a new balance agreement.)<br />
<br />
This is how the server covers its ass: If your balance has dropped by 100 clams, then until you have signed a ''new'' balance agreement, then the server still ''needs'' that cheque receipt to stay in the inbox, along with the ''old'' balance agreement, in order to prove the ''current'' balance! (Remember, the server cannot &quot;set&quot; a balance, only a user can! The server must have your signature ''for every clam''.)<br />
<br />
This is also how instruments are proven good or bad: If I really ''did'' authorize cheque #45, then not only will the server have my signature on the cheque, but it'll also have my signature on the last receipt, which includes a list of transaction numbers assigned to me--and #45 appears on that list! That's how the server proves that the instrument is valid.<br />
<br />
''The server cannot clear the same cheque twice without either (a) failing to give me a receipt the second time around or (b) giving me a bad receipt. Either way, I'll just refuse to sign the balance agreement. (Since I don't agree with it.) My last receipt already proves my actual balance and shows which instruments I'm actually responsible for. Any other transactions are fraudulent or already closed, and all I need to prove that is the last signed receipt.''<br />
<br />
What about the case where I accept the receipt (to remove it from my inbox) and ''then'' a malicious server runs the cheque through, a second time? This is not possible, because by then it's already too late: my latest balance agreement (that I signed when I cleared the cheque receipt out of the inbox) includes a list of transaction numbers that I'm currently responsible for, and cheque #45 no longer appears on that list. I already have the server's signature on the lastest receipt showing the updated list of numbers. Thus I'm not responsible for #45, or for any other transactions besides the legitimate ones listed on that receipt, that I previously signed for.<br />
<br />
Unless the malicious server can somehow come up with a newer receipt showing differently, with my signature on it, then I'd win the dispute.<br />
<br />
'''To me the amazing part of all this isn't that the balances are proved, or that signed instruments can be authorized and de-authorized. The amazing part, rather, is that it is done while simultaneously eliminating any need to store the account history, or even an &quot;account&quot; at all, other than the receipt itself! Wallet software only needs to store the ''latest receipt'', and the winner in any dispute is the one with the ''newest receipt''.'''<br />
<br />
Because all parties must sign off on any transaction, and because receipts are provided in all directions, the layers of proof are pretty comprehensive. For example, take a look at the receipts received by all parties during an account-to-account transfer:<br />
<br />
ALICE <br />
<br>-- Alice gets the server’s signature on her transfer request (whether it is accepted or rejected, she still gets a signed receipt.) <br />
<br>-- She gets Bob’s signature (in her inbox) accepting her transfer when he processes his own inbox. <br />
<br>-- She also gets the server’s signature on that when it happens. <br />
<br>-- She’ll also get the server’s signature on an agreement of balance at the same time.<br />
<br />
BOB <br />
<br>-- Bob gets Alice’s signature sending the original transfer, which appears in his inbox. - He also has the server’s signature on that <br />
<br>-- Then, when he accepts her transfer, he will get a signed receipt from the server when his balance is updated. <br />
<br>-- He will also have a signed balance agreement from the server at this time.<br />
<br />
THE SERVER <br />
<br>-- The server gets Alice’s signature on the transfer request. <br />
<br>-- The server gets Bob’s signature accepting Alice’s transfer. <br />
<br>-- The server gets Alice’s signature acknowledging Bob’s acceptance (when she removes his accept notice from her inbox.) <br />
<br>-- The server will also have Alice AND Bob’s agreement on both of their balances, (and doesn't need to store anything else.)<br />
<br />
Not to complicate things, but on each of the above (on each balance agreement), there is also: <br />
<br>-- a list of transaction numbers still outstanding (signed out by the Nym). - a list of pending transactions, and signed receipts, awaiting approval in the inbox. <br />
<br>-- ...and a similar list of pending outgoings (in the outbox.)<br />
<br />
Once a transaction is closed, it will be removed from the next signed receipt and the old receipt can be discarded. The user no longer has sign off on that transaction number on any future balance agreements.<br />
<br />
That's important: If Cheque #45 hits my inbox in the form of a cheque receipt, my wallet only needs to verify against the last signed receipt. If #45 wasn't signed out to me, then ''I'm not responsible for that cheque!'' The signature, by itself, is not enough.<br />
<br />
'''This makes it possible to define the terms of an instrument, to exercise it, to revoke it, or expire it, or determine the manner or the number of times by which it shall be negotiated. Nevertheless, parties only need store the ''last signed receipt.'''''<br />
<br />
<hr /><br />
<br />
''How does Open Transactions compare to Truledger?''<br />
<br />
* Because Truledger guarantees that transfers will happen in order, Mr. St. Clair was able to rely on a simple assumption: That all transactions prior to a specific balance agreement have been cleared, and are therefore no longer pending.<br />
* However, Open Transactions features transactions that may occur out of order. You might use transaction numbers 5, 6, and 7 on a set of three cheques. But the recipients might redeem those cheques in the order 7, 5, 6. Just because cheque 7 has cleared, does ''not'' mean that 5 and 6 have cleared! OT thus does ''not'' have the same guarantee of sequential processing that Truledger does.<br />
* This means that '''Open Transactions must include a list of all uncleared transaction numbers with each balance agreement''', so that when the receipt is presented later, clear proof may be obtained as to which transactions were cleared and which had not yet been processed. (Whereas on Truledger, the balance agreement ''itself'' proves the current transaction number, and all previous numbers are considered cleared.)<br />
* In both cases (Truledger and Open Transactions) the same basic effect is achieved: server and client can prove balances and validity of instruments simply by presenting the most recent receipt, with no need to store any other transaction history. In order to accomplish this, OT has to include all currently outstanding transaction numbers on the receipt, but this enables OT to support offline instruments (such as cheques) that may be presented later in a different order than they were originally issued.<br />
* The other big difference is that Open Transactions assigns the transaction numbers to a ''user account'', where they might end up being used for any of that users's ''asset accounts'', meaning that OT has inboxes for the user accounts (for receiving transactions and messages) AND for the asset accounts (for receiving pending transfers and cheque receipts) whereas in Truledger, the user account IS the asset account (you just create as many as you need, and each has its own inbox.)<br />
* The other big difference, right now, is that Truledger uses ''chronological timestamps'' for its transaction numbers, whereas OT uses ''sequential long integers.'' However, OT will soon most likely also change to using timestamps--''but not for the same reason''. On Truledger, the timestamp (for a given transaction) inherently proves the prior clearance of all previous transaction numbers, and thus eliminates the need for any &quot;uncleared&quot; numbers to be explicitly declared on the receipt. Whereas on Open Transactions, the current transaction number wouldn't prove the sequence even if it WAS a timestamp, since instruments can be presented out of order! This is why OT explicitly must declare all uncleared numbers on the receipt.<br />
<br />
'''So then, why is OT bothering to convert to use timestamps as transaction numbers? ''Because it's the only way to expire them''. The server would otherwise be forced to store uncleared numbers forever, in case they came floating back in some day. To fix this, OT will soon switch to timestamp-based transaction numbers, to make it easy for the server operator to expire any uncleared transactions that are older than N days.'''<br />
<br />
Much gratitude and respect for Bill St. Clair, whose work on Truledger was truly inspirational and who has been available for discussions on this topic.<br />
<br />
[[Sample-Cheque | Click here to read more about cheques.]]<br />
<br>[[Instruments | Click here to read about other financial instruments on Open Transactions.]]</div>Cryptomanhttp://opentransactions.org/wiki/index.php?title=Smart_contracts&diff=83Smart contracts2013-06-11T17:16:20Z<p>Cryptoman: Created page with "The concept of &quot;smart contracts&quot; originated with Nick Szabo: [http://szabo.best.vwh.net/contractlanguage.html Nick Szabo's smart contracts] Also: [http://www.erights..."</p>
<hr />
<div>The concept of &quot;smart contracts&quot; originated with Nick Szabo: [http://szabo.best.vwh.net/contractlanguage.html Nick Szabo's smart contracts] Also: [http://www.erights.org/smart-contracts/index.html E-Rights] Also: [http://www.erights.org/elib/capability/ode/ode-capabilities.html#simple-money Money example in E language]<br />
<br />
<br />
-----<br />
<br />
That being said, OT has its own, entirely different implementation... In the Open-Transactions universe, a &quot;smart contract&quot; has these properties:<br />
<br />
* A smart contract can be activated, after which point it takes on a &quot;life of its own&quot;, in the sense that it will process regularly over time according to its own internal terms and logic, until it expires or is deactivated. In this sense, it is like any other recurring OT transaction such as market trades and payment plans.<br />
* Smart contracts are most distinguished by the fact that they can have ''scriptable clauses''. (Normally on OT, a typical contract only contains data tags, and human-readable clauses. Only the smart contracts &quot;can come to life&quot; with their own custom-scripted clauses.)<br />
* Smart contracts can have '''multiple parties''', each with their own agents and asset accounts.<br />
* Only a select few functions are made available from within the script code of a smart contract, and all funds transfers go through this tightly-controlled interface, with notices and receipts sent to all relevant parties.<br />
* The script code is unable to manipulate any assets excepting those explicitly declared beforehand on the smart contract, ''and'' verified as valid property of a legitimate party to the contract. And when funds are moved, it's to a contract-specific name, not an account ID. For example, you wouldn't transfer funds from account pckjsdf9872345kj34kjhsf, but rather, by ''that account's name as declared in the contract,'' such as <code>alice_petty_cash</code> or <code>bobs_acct</code>. (This means that it's impossible to even reference any account other than ''those declared on the smart contract by name,'' since the functions provided can ''only'' operate based on those names.)<br />
* Not only can the smart contract move_funds() between these declared accounts, as its script logic dictates, but it can also '''stash_funds() directly inside the contract itself!''' For example, during an escrow, funds might be stashed ''inside'' the smart contract for 14 or 30 days, and then transferred to one party or another.<br />
* Scripted clauses can also be configured to trigger on certain ''events.'' For example, do you need a script to fire right when the smart contract first activates? No problem! Just attach it to the <code>OnActivate()</code> hook. Do you have a script that needs to fire every single day for a month? No problem, just put your logic on the <code>OnProcess()</code> hook! (And set a 1-day sleep between processing... ''and'' code your script to deactivate itself after 30 days.) You can even set multiple clauses to fire based on a single hook. For example, the main_bylaw might have a clause that's set to trigger on the onActivate() hook... yet the secondary_bylaws might ''also'' have a clause that triggers on that ''same hook.'' Both clauses will execute on that hook, based on their order inside the smart contract itself.<br />
* You can also define variables in your smart contract, which persist through its entire lifetime. As the smart contract--including its internal state--continues to process over time, receipts will continue to drop into the relevant parties' inboxes, showing the change in state, in those variables, over time (using exactly the same inboxes and receipts that OT uses already for transfers, for, market trades and payment plans... using exactly the same ''destruction of account history'' based core system, with signed receipts, finalReceipts, etc.)<br />
* A signed copy of the ''original'' smart contract shows it ''as it was,'' when the parties first signed and activated it. Additionally, a server-signed, ''updated version'' of the contract comes with each receipt, showing the latest state. The server keeps all of these receipts in each relevant user's inbox, as proof of the transactions and current state, until any given user signs off on the latest balance, which enables the server to then discard any old receipts out of his inbox. ''This is the exact same process as with all of the other financial instruments on OT.''<br />
* Once the contract expires (or is deactivated) then a finalReceipt is dropped into all relevant inboxes, after which no other receipts are possible for that smart contract. (As with the other ''recurring'' instruments, such as market offers and payment plans, users must close all receipts related to that contract, in order to close the finalReceipt. And no new receipts can come in for that transaction, once the finalReceipt has dropped.)<br />
* Smart contract variables can be defined as &quot;Constant&quot; (value cannot change), &quot;Persistent&quot; (value can change, and will persist between script runs), and &quot;Important&quot; (value is persistent, AND any changes in the value will result in server notices being sent to the parties.)<br />
* Let's say a party needs to DIRECTLY trigger one of the clauses on the contract. (Instead of waiting around for it to trigger automatically based on some ''rule.)'' For example, perhaps an escrow user wishes to execute a clause in order to ''DISPUTE THE OUTCOME,'' or perhaps an arbitrator wishes to activate a clause in order to ''RENDER A JUDGMENT.'' OT's smart contracts can do precisely these sorts of things, limited only by your imagination (and my pre-alpha code.) See the new API call: <code>OT_API_triggerClause</code> as well as the command-line option: opentxs trigger These sorts of actions are, of course, subject to the logic in the contract itself. Perhaps the contract disallows Alice from executing certain clauses, or disallows Bob from moving more than 100 grams of gold. YOU decide.<br />
* Once voting groups are someday eventually added to OT, they will also be able to act as parties to agreements, and they will be able to take a vote in order to change their own bylaws! (Each smart contract already contains a list of bylaws, and each bylaw contains a list of scripted clauses and variables.) This will enable corporations. You can read about it more here: [https://github.com/FellowTraveler/Open-Transactions/wiki/Future-Direction Future Direction]<br />
* You can also define ''CALLBACK SCRIPTS:'' These scripts fire automatically whenever OT needs an ''answer'' to some ''important question''. Such as:<br />
** &quot;Is Alice allowed to cancel this agreement?&quot; (Your script returns true or false.)<br />
** &quot;Is Bob allowed to trigger the DISPUTE clause?&quot; (Your script returns true or false.)<br />
<br />
As long as you provide the script, YOUR logic can be there 24 hours a day, making decisions for your best interests, while you're off sipping cocktails and getting arrested at Occupy Protests.<br />
<br />
<br />
-----<br />
<br />
A SIMPLE EXAMPLE --- &quot;Two-way trade&quot;<br />
<br />
Here's a sample &quot;OnActivate()&quot; clause from my very first (test) smartcontract, which implements a two-way-trade (where Bob doesn't get his clams unless Alice also gets her gold at the same time).<br />
<br />
Notice the entire functionality, while bare-bones, is implemented in this single OnActivate() clause, with deactivate_contract() being called at the bottom.<br />
<br />
<pre><br />
// These are the amounts being paid by both parties.<br />
// These amounts are for different currency types...<br />
// ...Alice is trading 140 XYZs for Bob's 100 ABCs.<br />
//<br />
var alice_pays = &quot;140&quot;<br />
var bob_pays = &quot;100&quot;<br />
<br />
// Stash is a function that only works inside smart contracts. It takes<br />
// the funds from the denoted account and stashes them INSIDE the smart<br />
// contract (in the below example, into &quot;first_stash&quot; and &quot;second_stash&quot;.)<br />
//<br />
// Only after BOTH stashes are successful, do we then unstash the funds<br />
// to the OTHER user. i.e. Alice gets Bob's funds and Bob gets Alice's funds.<br />
//<br />
// NOTICE: You cannot use actual account IDs while inside a scripted clause.<br />
// Instead, you can only refer to accounts by NAME (the name that was chosen<br />
// for that account when the smart contract was written.) OT will resolve the<br />
// name to the appropriate ID, based on the contents of the signed contract.<br />
// This way, it would be useless to come up with some sneaky trick for slipping<br />
// unexpected IDs into a running script's code or data, -- since it doesn't operate<br />
// based on the IDs! (Of course, the normal client API operates based on IDs, but<br />
// the smart contracts must operate from within their &quot;sandbox&quot; on the server.)<br />
//<br />
var bStAli = stash_funds(alice_first_acct, &quot;first_stash&quot;, alice_pays)<br />
var bStBob = stash_funds(bob_second_acct, &quot;second_stash&quot;, bob_pays)<br />
<br />
if (!bStAli || !bStBob) // FAILURE<br />
{<br />
// Somehow, one of the stashes failed (technically impossible,<br />
// unless one or both of them didn't have the necessary funds...)<br />
// Therefore, we give the parties their money back.<br />
//<br />
// IF Alice's stash was successful, then unstash back to her.<br />
if (bStAli) <br />
{<br />
var b01 = unstash_funds(alice_first_acct,&quot;first_stash&quot;,alice_pays)<br />
}<br />
if (bStBob) // IF Bob's stash was successful, then unstash back to him.<br />
{<br />
var b02 = unstash_funds(bob_second_acct,&quot;second_stash&quot;,bob_pays)<br />
}<br />
}<br />
else // Success stashing funds from both parties! <br />
{<br />
// Now let's unstash across, to the receiving parties...<br />
<br />
var b11 = unstash_funds(bob_first_acct, &quot;first_stash&quot;, alice_pays)<br />
var b12 = unstash_funds(alice_second_acct,&quot;second_stash&quot;, bob_pays)<br />
<br />
// bSuccess is a variable in the smart contract itself. That is, it's declared in the XML<br />
// of the contract, not inside this script proper--yet it's still accessible from in here.<br />
<br />
bSuccess = true<br />
}<br />
<br />
// Our work is done, so let's shut down the contract.<br />
// Receipts were already sent to the parties' inboxes when<br />
// the money was moved. Now this deactivate will cause a finalReceipt<br />
// to go to all the parties.<br />
//<br />
deactivate_contract()</pre><br />
Of course, that isn't the entire smart contract, but just the onActivate() clause. Here's what the entire smart contract might look like:<br />
<br />
''(Subject to change, of course. This is very new code.)''<br />
<br />
<pre>-----BEGIN SIGNED SMARTCONTRACT-----<br />
Hash: SAMY<br />
<br />
&lt;smartContract<br />
version=&quot;1.0&quot;<br />
serverID=&quot;tmHvLZxb13hW6OyH1oHKTmKd7fTMRsUfzqPE6KCwSjl&quot;<br />
activatorUserID=&quot;&quot;<br />
activatorAcctID=&quot;&quot;<br />
lastSenderUserID=&quot;&quot;<br />
lastSenderAcctID=&quot;&quot;<br />
lastRecipientUserID=&quot;&quot;<br />
lastRecipientAcctID=&quot;&quot;<br />
transactionNum=&quot;0&quot;<br />
creationDate=&quot;1323862266&quot;<br />
validFrom=&quot;1323862228&quot;<br />
validTo=&quot;0&quot;<br />
nextProcessDate=&quot;0&quot; &gt;<br />
<br />
&lt;scriptableContract&gt;<br />
<br />
&lt;party name=&quot;party_alice&quot;<br />
ownerType=&quot;nym&quot;<br />
ownerID=&quot;T1Q3wZWgeTUoaUvn9m1lzIK5tn5wITlzxzrGNI8qtaV&quot;<br />
openingTransNo=&quot;37&quot;<br />
signedCopyProvided=&quot;true&quot;<br />
authorizingAgent=&quot;agent_alice&quot;<br />
numAgents=&quot;1&quot;<br />
numAccounts=&quot;2&quot; &gt;<br />
<br />
&lt;agent name=&quot;agent_alice&quot;<br />
doesAgentRepresentHimself=&quot;true&quot;<br />
isAgentAnIndividual=&quot;true&quot;<br />
nymID=&quot;T1Q3wZWgeTUoaUvn9m1lzIK5tn5wITlzxzrGNI8qtaV&quot;<br />
roleID=&quot;&quot;<br />
groupName=&quot;&quot; /&gt;<br />
<br />
&lt;assetAccount name=&quot;alice_first_acct&quot;<br />
acctID=&quot;2K3LoD1UxsJLO0FAfng0fgqnxnXScO8rM2eO5tdDTOE&quot;<br />
assetTypeID=&quot;mNS1ODAXQoSXpWJfC5awE9zAXCm9aVfiE0WQGsIOw4B&quot;<br />
agentName=&quot;agent_alice&quot;<br />
closingTransNo=&quot;36&quot; /&gt;<br />
<br />
&lt;assetAccount name=&quot;alice_second_acct&quot;<br />
acctID=&quot;A6CcGwNiTtEPQnv7HLUcmf0QFaCGy862pb1SJ3zVqIU&quot;<br />
assetTypeID=&quot;SjSYAUzN1RLjGre0kqDJynFos1MRYzrxOOenHY0Lpjd&quot;<br />
agentName=&quot;agent_alice&quot;<br />
closingTransNo=&quot;35&quot; /&gt;<br />
<br />
&lt;mySignedCopy&gt;<br />
eJytVsuyokgQ3fsDszXcGt2CbzvmdgQiKj4ABZ+bGyWUUAoUVvEQvmM+eArw9rV7<br />
bvREd7Qb4VRm1snMU1RW/vnrU/4bShNZqeryRJFGVX0prA1RVYy1IBrFcmUKqPOl<br />
qgvLQ6XyN/UACUXshwSYYaUaQ0IR9l9q/GeuVqlSSBgij15qoTeNF8f7iW85u66a<br />
Tnk8nRve3OqdjeWabs7ZTZO6czHRLy7zY7FQDEJMNrR0f8YE0wwfmAtoqEPfgs+G<br />
7+APlmtoogBBP/zB+Bv+ZM/y8Wm+JfaVyHup5dmYBIIcGIEQsgxbzVa/22y2e2wp<br />
Bi6yxgR773iz/4YbuPT34T3UCDYhpWUIrlb9mtfQJCgIwcmFb4XM0YAVNq36wGOG<br />
xfMri2VCFgcnPiRGGrAFP/XegJy4wa9ayXFnQ2ODwSb2Bx7vZvK8E/qdRDbc7J6R<br />
iSL3byHY5m4B9JFvG3mqCuPYyjOhyPahJeIgZVRjZEHrpXYGLs03BlHoYIIy5iTY<br />
rF4vNZD/fSPmR16BU1aFx6tp4qgAmmWuhcMjq++dLQxp4b2GAYGUPUyRR6F7ZuIh<br />
UW6BynXBl30LMWoRcL+tsUL8egEIduGj3zbBUaAUtGrVRsGUUhg++L8Rzqm+nhGh<br />
jDbTSqHKUjLNeWuBR/zmTmcLlRsLZ9/mzvbNv/t73VT7ZNmEaie0RoYq5V557LyD<br />
uaun6Lw6EvYrrO+D3ewsdkAiDTJhL3oDsD0jidutJlRWk/Ywd81LoHxQP9PF9Ltu<br />
dv8vEQpN7Fs/ZiJ0RXOSKMgIJW3lx73pYmN6Z241BuIkZcIOTrw+a2Xbm7z5MRP9<br />
oh+ETabw68VlQiB3vY1mqT/GlF+uDxm5qyr0pwduEVysX8qk88ikUZyDjw/HCZ9+<br />
ejQ+0Dv3m3Ivt/otsZeuf0Tqv6FftvvH6v1jkvyge9zP+Xwswj+mrJ8QelfTKXVB<br />
8uDkAeS/FgAtu7oFBOXf5vc+iy6I6NP7FOPr0ypw3RMwc4QrLhjfjhihl5rpAFTq<br />
In6EfCuDHpn5pVDeFxF8V2BYKPmEcXkp5kZM7/kdS0OW4iMRs+DzprPymoSvJVr7<br />
WoGz++B64aMkE5YOMCPV3l/SFRAbw7WldlfT7mwROShbiMJ0PLquumtrdE0W/Hhu<br />
upO9AOUKlrddXjPhEPhnt6c18ZADu06Pc3SRWn3UPHXCJVu73Ui0CmRe1q04yzyp<br />
PVOO3HwW1StEdzUqHAYm8JS2vr3eDo7SXMueRfdyHaKbqpvta7a1dkn/kMrHdCi3<br />
juJtl9j75N5ZuLByOE5WzjlYS5ebrOuhODH7Ao4Vb97tDOqZ0Wg0LkZfmneMVYra<br />
g8wemGNbCx1KtHAj7QdGhQ/Gis0ZaHAZp5G2uCY7uJbqm/u2GfSuXtZtL2dHUp8S<br />
W9BT6yAiEiTjkyxp4whh7aCZleOtr5B01OgNnRvoZM0wOHhJiFVJaK+WTkeTYh7t<br />
9u2hakM9Gc6cwwjU1b7c0r3lIp2H18qUh3yvqZ5GS7U+rs+UULnNZ8c232zJy+vw<br />
fBtlVtzn6QvTZdm5vLMOU9ajrybB/utbcwtV50b/7fdD24WCi6ePpwtQHsQFE9JD<br />
ZTRkc12tWsDfRpPGk10Z7XneY8jzxPg8Khbzo2Bs1lI5NG7LwfBLVWUf4arxPl3R<br />
Kve516mI2POYor9UnTAMvjQaNgqd6PTZxF5jDF0XJ8wlhi4kjTzAp+cAjQRdUYVF<br />
EIYRkba9OE41p5mQlZUe45AY/pQL5w3tgi1qKzJRHGl9H9rOAS1321nUbp2ycO91<br />
vIrk2vz67nKX7hpFbdFZBI7JT6d+hnbrqDWI/RPPdQBFCn/H4nW+OZJshMlyQEBT<br />
O5gdULG1hXZxfFc8LMYc6nnb7C7N7Fl0ObiSc2jIe+pOHCEcuTSqL+LrS1k8SRn9<br />
tHT/Ap89zUk=<br />
&lt;/mySignedCopy&gt;<br />
<br />
&lt;/party&gt;<br />
<br />
&lt;party name=&quot;party_bob&quot;<br />
ownerType=&quot;nym&quot;<br />
ownerID=&quot;1mxwHcQvxSgqWqy2e28ZREeuVVfgs0kxE41FN10TnS3&quot;<br />
openingTransNo=&quot;67&quot;<br />
signedCopyProvided=&quot;true&quot;<br />
authorizingAgent=&quot;agent_bob&quot;<br />
numAgents=&quot;1&quot;<br />
numAccounts=&quot;2&quot; &gt;<br />
<br />
&lt;agent name=&quot;agent_bob&quot;<br />
doesAgentRepresentHimself=&quot;true&quot;<br />
isAgentAnIndividual=&quot;true&quot;<br />
nymID=&quot;1mxwHcQvxSgqWqy2e28ZREeuVVfgs0kxE41FN10TnS3&quot;<br />
roleID=&quot;&quot;<br />
groupName=&quot;&quot; /&gt;<br />
<br />
&lt;assetAccount name=&quot;bob_first_acct&quot;<br />
acctID=&quot;w06QIURsSDV7sdWWvyPSxRaiv4T2MUQbJyWmIKxSmuL&quot;<br />
assetTypeID=&quot;mNS1ODAXQoSXpWJfC5awE9zAXCm9aVfiE0WQGsIOw4B&quot;<br />
agentName=&quot;agent_bob&quot;<br />
closingTransNo=&quot;66&quot; /&gt;<br />
<br />
&lt;assetAccount name=&quot;bob_second_acct&quot;<br />
acctID=&quot;vuXpQt8h6CRGcz6G5zMOXqQeIRpsOq05VLuJ5IAFS5R&quot;<br />
assetTypeID=&quot;SjSYAUzN1RLjGre0kqDJynFos1MRYzrxOOenHY0Lpjd&quot;<br />
agentName=&quot;agent_bob&quot;<br />
closingTransNo=&quot;65&quot; /&gt;<br />
<br />
&lt;mySignedCopy&gt;<br />
eJytWNmuo0i2fecrjvLpSqiLyQwudbYEZjY2MwZeUkwGbObR8DP3Vy8+PjlU3uxq<br />
Vav8YtgRe7OHFRErNvC///OP54/hBOn8ZkrCmWPfzBNtWAf1bBn0wXofBsSgz35/<br />
M+mTBwD/7MugGw51NXRBNABvU9L1eV19/oT8Bn8C3vqk2yQS+/nTUIqT4j9CBMsu<br />
hLqISC0erfIYk1frZPT2dW01jjgeZvNWbHqbrXwKhrqz+5f6jzI6ioYPWRH0g5lU<br />
cfLjxO/Cn2YaSZQ3eVINP03+Jv9h/hZP1T8/WVfnsfz86RlN1CXBU8AGQ7JFiKEY<br />
RaAoQWxDU1DkMd/V5Xc5Sn2VW/VLv0oeg9bVUdL3LxPwp7d/PXMYdXkzBGGRfE3k<br />
U9psiV3eqqDcJr4/f9lsRclmp56rpLOWZhuolvKr4Om4hejY7F/SxLLrwJ6qfYkU<br />
q3TEhwqfJatYH2snnCWqHQLnqdYkVV6l1jPU8+YjRj5LlqdVEh/qZtlcnfI4ibfi<br />
dePzu8E4ZHWXr5sOnW7p+vwpeP5986say3d5vyXh4zWK6vFdgL5CfVf4COqPynGd<br />
9O/aRtJ0Sb89iHnZJ8X12+fz1zhdSVWcb56NQfFtbMvDX4+/q4vko9xpV4/N+d2t<br />
T2/Qu6d9nwwf/n91+Onql2ve9ZvbG1TeQflCDHrElJpF7EcvKyrM09cqha9pWz0q<br />
14xUqjuhiYoPMWup3FPraftZwKdqeTYRlaVdvTbd5iJfD3gwc/uVdg/lPnCuOQdf<br />
dKGX1HnHPFWfKTj/In9RUfd/KCbxnwLpk6iu4p8joYlDJMzn3Bo4Ta8mUlTsqLzC<br />
Oh8chGXDdRMipoytTivZP0di3kyPttczYig3oUvge8vKS8XXPXIyvLV7qGpSiR6s<br />
NLf4L0WCf0RSLuY3cP4LSORlcPpxqe+pjl17tl/dSBjQQ7hOZZzq+fG2oxkfDIXl<br />
Ytt0bTsTp0/lCUzobt53DgmEk8HFpB7uHKNE+upkI8YFmqrOhnahmZ39NukWQ+YF<br />
x4WbjkYMx1sQien4qLSPraYWQJtOik64yxmy6YPt9tlsel5gBzosGfti30JCMjpt<br />
YZpMmt8QvK2t5MxTVzK/UPhIEAFgVXeqMqYEU9v4llyCsCd9y1eJaBUNZSFXj+R1<br />
lpNP586Ar5THwfN8LemhbjntmvagAJAgrRXlUNcpw2jQyoDMBPonaKEuJShfA2cR<br />
xwaPS4+RpEiQOL1PH+HqBBCKLmiCzg3A5MTySA2SxPIV2nnhqFnYzsLsA+tlzcWW<br />
uiLcl8NVlw+pNEclH+7cE+zRzrnFiFlQBeBxPXU56hz4NKq03BCEjuY1yE1SednN<br />
wT5YXL7SUZWdzRBlHuTkT0eKg9rYYMOIlAkDyE0FCxfRw8sds5f5ScDK9jBq3nJT<br />
s0ULMjmRUt8xbj4ndo3rCUoPY0wh1p4kLXhueUDH76azz0JXUysNhGBsJOAfxNDs<br />
2pQuy8uYRadbC4Kxoj+aXYgKtCfYmr0YBsGT/ihlgH0hmKVymQKDldOlNiIFHHpb<br />
oZKUk+JRuGFryNgBbQ9C5xi9YNtZCoIKZaxtCVaZkAE3NrTMVjzaN+WcXEbGgNbS<br />
KiOlMHrF30PlOoXnCRpIzLFI/1xyQZ7ARu21uIPjpLKwwBiMFaHMBDd5XaeCLJbM<br />
fXync9aSMwWr2Z6Fb9t+N8iFcblD3hxTiFKLD13ba/xeGUYgnqgN3c2Z5HvIz2XY<br />
cFXzeEol+YIVDxJrvPJM+OgOYUbp7keSanUzGKBuWJIrfjK0PVBnIGcF4UxQTqHn<br />
DDZ5SNlakFDw4Mg+SrxdOriZ45Fzlt6l2jtF5XfbX9jbDIkHfw8CyU0HYXbCSkya<br />
Bqgeej8Zr7DVTgR/HaZJJCbkdp+WNNmvGujO/XwDy06m9G2Dt46uwwDUyN7pxIT4<br />
lB5GsuYZ1b3iUwTmCyERZ43kVa2Dl2bGjNMc7fROyW7XW5ZnBd41NG+1gFQR3PUw<br />
smJT4Y3DJvyDpxyU8Y5ayUXuvcHv/omE7rEJq5ddvpEOkF2bTlvK2pxkpyOBSy2s<br />
IMgQu+B053BPPR00BysgkzfocCYvRby5SpazoZpZmJ9kWFPacSyHLt52aEjMRmBs<br />
1D2t2seii2P3pmWcllUDESGUT7MjTGgRZhqXCrM10T3Izkhidg4fSiNBWni3rEsD<br />
aI6qYuJ8QcyBi1e7FWmvpGQTnTosYWvSdE9jYlzjRQyOYdtMQ0AGSHyvoPupE+ND<br />
jgG3UR6K/Y3Ez7g/KsyicvhlvRWeiSdhp46ZyookXe+ccE8OrNr68CWFlbt/Lavk<br />
5HhdAKTUnJTCOTw8kOMg0jdSj4VMh4S8h/1ApP0GF9Dx4JGjHLYlNKLC1RzdwR8U<br />
NBbthjKBy56xiIXOudy63Zdtxc1ZRgYHv0jUocMZGFHT87bl1f4JnlUxk3PekYMj<br />
eLHuieVl5ADsRzQL7qe9EBHRPN9sJCQjuMMKqUFFhGrtDFum1scFk7TBrgdtW6nO<br />
PhWhGLrKCzjNwJUZCmdYK0KfLD8u8Uk5qfY+uHVLyEDjEEbz4OBwCJHXmEV3l0NO<br />
JFozD7rY6zy3l1nAt4x7hKDDpWevRqMJdwT2SbdKPOq2PrSUOmbhWqNMjxQSfhZI<br />
Zb4yinOxr7uge2gFZgDHKcERopRQTfXqbm9XFn2abnpwTtuY0Cz/weM3loddmZqL<br />
LN/db9ZKN2BE33Qjtj2HBzjJM+5hsFe5HdLgpV74drLDaQ9qdAWfsSHNkfa4yoYo<br />
FHtx36m0uZFOpLLDBl0idY8Ak9Td0WklyOroklnDhzHvMxIpW0QMZlXYtexFggxN<br />
i3WGP1SQuKsuoOrLfXYqFp1jLEDF09hWBCRz/ceVjyjl5EVEVYXkgdw2mQJWw9yM<br />
0JuUgI0qHrho3DZABVQ6E7lTplHtgUG0ILqh9qt9/wz8E/rj0b0J3hntr2luWId/<br />
SnKR8jGLkT49zLS9tM+DjPINbjtqne1QhO+PLWn8GYGtysR+QXKJf0dyr0HR/xnL<br />
fbn1X3Hcl+rfwnD/WvB/leFujv6a384woUu20ZusQ/bx5TItmvkwgnzaWejJ1kN5<br />
uZTS8WGWo/I389tX7n7mhMSfsNtnEL/mttPoNvpAZcTBEKKVEPD1pLqtnkhG06st<br />
jDvKKOMSzZu48Tdz238TxVdm+305hEsRzB+BlEFefXkX9C+oOUGXP6+J38F3KIKx<br />
/+FdrOv7D6NBUYRB9JTA73fdKh03fz5/irIgf4F1+jD5NXfmGD3vp6+r65h8XxbD<br />
+1IM6/p1P39O2hbs87rfD1uEH4FE7/58Bf/rxp58eUk/PTn7Y3+/IeO80qcsiEY1<br />
dW+LHhwgxohVQhcJWRmzfFUOtMizd50wYvY+Kwh/jArBpRMJqCWHQLQoYYLqWpAa<br />
WjNwcMFJODMPfUzlaIgPp22sbbtRbyREMuNpXUtuJ599+CiPINCZhdbT3j4KyvPO<br />
dO6tl51RQyrj3pXAJG9VM9rdVye+zJS3SP7CSJh/aC9z6s4PXCkSwPMFPbs2Bndr<br />
JdMcDkJE0fV0Lo8EvgdXC4Kgm0VxR9zSl3y3X9N9xKfakPWdNticu7cApOHPKWzl<br />
+xu/jJpyny+JwYH2w0Eb8l6uxO4k+x0odiltLrF3yLtm5kOJ0/gxrzVPiwC/pc7d<br />
wkIkk7UBvqLDRu/moVY5eqefMlzjJiS/uDtGTRNzZuTMYwNQpSTMLE/KchzugIgk<br />
CImqIXtSQR6Uz8O5Pcr+DkEx6XRnri27bnwS6Z/79qtyz8pmG7I+6hp1dfXla3Hf<br />
Yf2c9P/r/YHtdwS/P/260RG8Vq+yAekDZf0Q9Nmnt3fxty4J9MO8l7UfW0+b5Mfm<br />
1Y9dq/dWFm3ZBvfqXzmvHtXvb+p2NLxZ3xs9/Rv8G4kDh7osN0T//pYNQ/M7BKX5<br />
kI3hb1FdQnxSFPW8qUxJkXTQ08A/fjQAzfk9BzYLNDPU3F5BWgSGIxZyVSodLKdU<br />
DumaMN5CKbK1QwUjNwzeFzvxLiddFdY+ui91G78BO2hp4Oh01+K2TfadK5G+jZ9O<br />
Gp3osmNWx9GLc3zyvYm8ioLoXJHRo3GmWjaI37fbjg/gVAQXVUJXbZGBzHGrges6<br />
oEaUbpbnknmYWtQFUWW9nUlTuUifX8njzuyfpu7/AMB4n1M=<br />
&lt;/mySignedCopy&gt;<br />
<br />
&lt;/party&gt;<br />
<br />
&lt;bylaw name=&quot;main_bylaws&quot;<br />
numVariables=&quot;1&quot;<br />
numClauses=&quot;1&quot;<br />
numHooks=&quot;1&quot;<br />
numCallbacks=&quot;0&quot;<br />
language=&quot;chai&quot; &gt;<br />
<br />
&lt;variable name=&quot;bSuccess&quot;<br />
value=&quot;false&quot;<br />
type=&quot;bool&quot;<br />
access=&quot;persistent&quot; /&gt;<br />
<br />
&lt;clause name=&quot;activate_clause&quot;&gt;<br />
eJx9kj1uwzAMhacuOgXjyQaC/BRdO6QH6JLuhizLCAHFDkQ6RdDkwL1FKclGXAeI<br />
oIV61PceBanfl7P2oB0aW570hSCsd8i2b5tMBanqqruQpI1ISdvzzmE4JNZ0KJu+<br />
rSlPsAY9camN4SVkqYhN2RImdsXI+eiqOSc4kzVdWw8YyIZyBI3ZCqWwgXwx5Lle<br />
YZGQhfpREjqISStCGc8AovNmK659+zT///jT8EK5TQyi49zg9cFgPthsrPtUEX9T<br />
1pFNg0Ti9jFyuPLkwWeRE+UxV2p7kmz64MJZr+HrgASydYCirpwFbIEPFuioPYPc<br />
Zq8NryD/7Bhqa5z2tpYmwtoOEA4QMh5PEv1iWX4BOgeSwBJhYDa+O8I3SmMLyKtk<br />
H1e172ObDMO+F+JNtNqKJZ4123IMkBfqDzdv81s=<br />
&lt;/clause&gt;<br />
<br />
&lt;hook name=&quot;cron_activate&quot;<br />
clause=&quot;activate_clause&quot; /&gt;<br />
<br />
&lt;/bylaw&gt;<br />
<br />
&lt;/scriptableContract&gt;<br />
<br />
&lt;accountList type=&quot;stash&quot; count=&quot;0&quot; &gt;<br />
<br />
&lt;/accountList&gt;<br />
<br />
&lt;/smartContract&gt;<br />
<br />
-----BEGIN SMARTCONTRACT SIGNATURE-----<br />
Version: Open Transactions 0.75<br />
Comment: http://github.com/FellowTraveler/Open-Transactions/wiki<br />
<br />
CoABiNsgHCRFOVBFgU80CqPUnMYpb+IMLmBWMroLSVEkHBuUojcIcAGXMBqKxy96<br />
tjBD0GLb9TINu9ehVKGyyqcNKcxb5QlQQbKpkFiEELAB2mhtJsTQlsPZaa6e+KWg<br />
0OhmgwbNVHohbKUwyJAgrPN8FHlguw2uW+dJ/3gX5huctLA=<br />
-----END SMARTCONTRACT SIGNATURE-----<br />
</pre><br />
Many have asked about my choice of script interpreter. FYI, I'm currently using [http://www.chaiscript.com/ ChaiScript], which was chosen for being cross-platform, clean, easy-to-use, and integrates well with C++.<br />
<br />
However, the design of OT is very modular, such that it is very easy to replace the script language. OT is coded to the abstract interface OTScript, and the actual Chai integration is done in a subclass called OTScriptChai. All you have to do, to replace the script language, is just make your own subclass of OTScript. To do that, copy the OTScriptChai class, and make your own version such as OTScriptLua or OTAngelScript or OTScriptE, or whatever floats your boat.<br />
<br />
In fact, each Bylaw stores the name of its script language, so you could technically have 3 or 4 completely different script interpreters running against the same smart contract! (I do NOT recommend this.)<br />
<br />
Bottom line: the point of OT is to be able to easily swap in/out different storage, different network transport, and yes, a different script interpreter. This way OT can best adjust to everyone's needs, and focus more purely on its financial crypto aspects, abstracting all else away for others to worry about. The best choice for a reference implementation such as OT is something simple, clean and cross-platform (like chaiscript.)<br />
<br />
<br />
-----<br />
<br />
Here are those links again: [http://szabo.best.vwh.net/contractlanguage.html Nick Szabo's smart contracts] Also: [http://www.erights.org/smart-contracts/index.html E-Rights] Also: [http://www.erights.org/elib/capability/ode/ode-capabilities.html#simple-money Money example in E language]</div>Cryptomanhttp://opentransactions.org/wiki/index.php?title=Sample_Currency_Contract&diff=82Sample Currency Contract2013-06-11T17:02:11Z<p>Cryptoman: Created page with "What I find interesting about [http://iang.org/papers/ricardian_contract.html Ricardian Contracts] * They provide '''a consistent ID for the same contract, across all servers..."</p>
<hr />
<div>What I find interesting about [http://iang.org/papers/ricardian_contract.html Ricardian Contracts]<br />
<br />
* They provide '''a consistent ID for the same contract, across all servers,''' ''without'' needing a centralized directory server. (Since the ID is formed by hashing the contract itself, forming its fingerprint.)<br />
* Since the Contract's ID is its ''fingerprint,'' this '''prevents tampering.''' (Were someone to change any contract, by even one bit--a 0 or a 1--it would also change the contract's hashed ID, which would fail to verify as a fingerprint.) The Nym ID, similarly, acts as a fingerprint for its public key.<br />
* Furthermore, the public key of the contract's signer ''is embedded within the contract itself.'' This means that '''anyone can read that public key out of the contract, and then use it to verify the signature on that contract.'''<br />
* From then on, '''users will also encrypt all their future communications to that key,''' and/or take advantage of whatever other trusted keys and rendezvous points may be described in the contract. Whenever the user sends messages to the entity listed on the contract, he has pretty good confidence that only the contract signer, with his private key and passphrase, can both receive AND open the OpenSSL envelope sent by the client.<br />
* Ricardian Contracts '''encapsulate everything you need to know''' about a currency (or a server.) Such as the connection information, the currency symbol, the entity's identifying information, its terms and conditions, jurisdiction, etc. These values can all be ''set'' by the issuer, ''agreed'' by the user, and ''enforced'' by the server.<br />
* '''Ricardian contracts can contain many different addresses of different types,''' such as the .onion address, the eepsite, the IP address, the Freenet address, a Namecoin address, an email addresses, WWW etc. '''Combining with these external locations makes it possible for contracts to expire themselves, and update their terms, effectively replacing the CA system.'''<br />
* Ricardian contracts also provide good evidence that, if a user was using the ID, therefore he ''must'' have had the contract loaded up into his wallet and assented to its terms. '''No one just magically guesses a 256 bit hash.''' How could a person simultaneously be aware of a currency contract ''enough to use it every day in his own wallet, for his own money,'' yet turn around later and try to claim that he was unaware of its existence? And on top of that, who could then expect to bring any legal action against the signer, except based upon those same terms? Only time will tell as this contracts are tested in court.<br />
* While Ricardian contracts are simply signed-XML files, ''they can be nested'' like russian dolls, and they have turned out to become the critical building block of the entire Open Transactions library. Most objects in the library are derived, somehow, from OTContract. The messages are contracts. The datafiles are contracts. The ledgers are contracts. The payment plans are contracts. The markets and trades are all contracts. Etc.<br />
* Many OT contracts, such as [[Smart contracts | smart contracts]] are self-enforcing, meaning '''the contract is a financial instrument, yet it is also a computer script that executes over time.''' Once it has been activated, until it expires or is canceled by one of its authorized parties, the contract will process automatically according to its terms. The clauses are scripted by the users and then signed and activated onto any OT server.<br />
<br />
I originally implemented contracts solely for the issuing, but they have really turned out to have become central to everything else in the library. Today even escrow is now available in OT purely in scripted form. (Without requiring any changes inside the OT C++ code itself, users are able to create their own escrow agreements in SCRIPT form, and run them inside OT.)<br />
<br />
Here is a sample currency contract:<br />
<br />
<pre><br />
-----BEGIN SIGNED CONTRACT-----<br />
Hash: SAMY<br />
<br />
&lt;?xml version=&quot;1.0&quot;?&gt;<br />
&lt;digitalAssetContract version=&quot;1.0&quot;&gt;<br />
<br />
&lt;entity shortname=&quot;Gnome&quot; <br />
longname=&quot;The Gnomes of Zurich&quot; <br />
email=&quot;gnome@zurich.com&quot;/&gt;<br />
<br />
&lt;issue company=&quot;Anon-E-Gold, Inc&quot; <br />
email=&quot;gnome@anonesilver.com&quot;<br />
contractUrl=&quot;https://e-silver.com/cash/contract/&quot;<br />
type=&quot;currency&quot;/&gt;<br />
<br />
&lt;currency name=&quot;silver grams&quot; tla=&quot;GRAM&quot; symbol=&quot;sg&quot; type=&quot;decimal&quot; factor=&quot;1&quot; decimal_power=&quot;0&quot; fraction=&quot;mg&quot;/&gt;<br />
<br />
&lt;!-- CONDITIONS --&gt;<br />
<br />
&lt;condition name=&quot;backing&quot;&gt;<br />
DIGITAL SILVER GRAMS are payable to bearer in physical silver grams,<br />
at any exchange provider supporting our contract in any denomination<br />
they support, or through one of our direct agents in 1000 oz bars. <br />
&lt;/condition&gt;<br />
<br />
&lt;condition name=&quot;audit&quot;&gt;<br />
Silver Grams are audited monthly by highly trusted people.<br />
&lt;/condition&gt;<br />
<br />
&lt;condition name=&quot;purchase&quot;&gt;<br />
In order to obtain Silver Grams, you must<br />
purchase them from an exchange provider or receive them in trade.<br />
The issuer only accepts direct bail-in of physical silver from an<br />
authorized exchange provider.<br />
&lt;/condition&gt;<br />
<br />
&lt;condition name=&quot;redemption&quot;&gt;<br />
In order to redeem Silver Grams, you must use an exchange provider.<br />
If none are available you must make sure you trust this issuer<br />
and make sure this contract is enforceable in your jurisdiction,<br />
and make sure you are trading in a BASKET currency so that you<br />
are not entirely reliant on a single issuer.<br />
Silver Grams are redeemable to exchange providers in 1 oz coins.<br />
&lt;/condition&gt;<br />
<br />
&lt;condition name=&quot;rate&quot;&gt;<br />
Issuance and redemption will be performed at no charge.<br />
&lt;/condition&gt;<br />
<br />
&lt;condition name=&quot;buyback&quot;&gt;<br />
The Issuer reserves the right to buy back all outstanding<br />
currency, thereby terminating the use of this instrument.<br />
&lt;/condition&gt;<br />
<br />
&lt;condition name=&quot;liability&quot;&gt;<br />
Silver and its maker, God, are solely liable to perform according to<br />
the conditions specified in this contract.<br />
&lt;/condition&gt;<br />
<br />
&lt;condition name=&quot;mint&quot;&gt;<br />
Float - the total quantity of Silver is created by God.<br />
The quantity of silver that enters the market yearly is strictly<br />
regulated by His wisdom. <br />
<br />
Any server operator using this contract will not issue any more<br />
silver digital currency than he actually has in physical silver.<br />
&lt;/condition&gt;<br />
<br />
&lt;condition name=&quot;privacy&quot;&gt;<br />
The purchase, redemption and trading of digital assets normally<br />
are done on the basis of strong privacy.<br />
&lt;/condition&gt;<br />
<br />
&lt;!-- KEYS --&gt;<br />
<br />
&lt;key name=&quot;contract&quot;&gt;<br />
- -----BEGIN CERTIFICATE-----<br />
MIICZjCCAc+gAwIBAgIJAJWeuXi8XjVjMA0GCSqGSIb3DQEBBQUAMFcxCzAJBgNV<br />
BAYTAlVTMREwDwYDVQQIEwhWaXJnaW5pYTEQMA4GA1UEBxMHRmFpcmZheDERMA8G<br />
A1UEChMIWm9yay5vcmcxEDAOBgNVBAMTB1Jvb3QgQ0EwHhcNMTAwNzIyMjAxMTIx<br />
WhcNMTAwODIxMjAxMTIxWjBeMQswCQYDVQQGEwJVUzERMA8GA1UECBMIVmlyZ2lu<br />
aWExEDAOBgNVBAcTB0ZhaXJmYXgxETAPBgNVBAoTCFpvcmsub3JnMRcwFQYDVQQD<br />
Ew5zaGVsbC56b3JrLm9yZzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtiu6<br />
jU/R2Zm3AAo1jA4z/IVHyAnIFzp4kUNkLjEQ6bKG31PRaTcZTLPBkXsnQIFPx1Ky<br />
u9q8T9gjiKPAEurtPyoDdT99aWP1NREcg4/RJ2naWOEAXGh21PP22x31bvy6lOrv<br />
KqOSBfNTL43PEj0dKMIl0MNywzsVZGDqKXTStG0CAwEAAaMzMDEwCQYDVR0TBAIw<br />
ADAkBgNVHREEHTAbgg5zaGVsbC56b3JrLm9yZ4IJbG9jYWxob3N0MA0GCSqGSIb3<br />
DQEBBQUAA4GBAEhRt14Ys7jhUg0mDKMMgZLLs8cbDNFqwoJynLVNgJUdlvwo/nzZ<br />
Mk0wWVw8ucaDdpSBufUx4G3h6KkTTKOAbkvncRGdCiqywvOjKIbUczWMDdJ9uE5m<br />
5zGVZZ8C7EqaIIrv0OpW8WSryOCXvCFhLfKuZteELGmCCX2tQE9TqIsr<br />
- -----END CERTIFICATE-----<br />
&lt;/key&gt;<br />
<br />
&lt;key name=&quot;certification&quot;&gt;<br />
- -----BEGIN PGP PUBLIC KEY BLOCK-----<br />
Version: PGP Desktop 10.0.1 - not licensed for commercial use: www.pgp.com<br />
<br />
mQGiBDn6yYURBADM3qphMoDpvpp3Lk2KW0bpA+i1ne6Hwm24lW9w1dIJrw8CEc+S<br />
vAEhoGOAJNTO209NFYxcM+sA8XHp5aJpFHSbI536sfzbSVe3/MwdJ8JZXtbzcbHv<br />
ToBs1wScGTet2SGL6I9S3p7XUfprCYezBPRMCPOTxqR8pptotYOGXZoPZQCg/y0q<br />
CZjPJclqDY8Hf0X+DWnOMAkEAI4GnOpSq838/oElDAuZcLOvpTqTZ922pG1EJQmj<br />
Vh4P6br3ocrWnJSonkqFPLjihsVwGumO/hkyptrgqRV/vR9BmK1LKz901VaXbXPZ<br />
Lcns+XAg5sXxZcz87Dl4AduTF59ahHkc2bR7HqrvzRkXoQ/Q4ViLOifFISXXPKx8<br />
3OazA/9Ip4W+gr8e/oub7MQFJZcyOfcN1KDFIjnObVIabpIlKPcTeEHGvd/WUHOJ<br />
PQQr1+WGZY1W9UjLo171ssL2/x2bXaqJ4Ukgf4aQpRb5lUqekCKgine6eUA1XjTw<br />
J+a/J3xP54/iEuqdDZYGuX5j0/EJCqbY7gggPNkDNH82XdfQ+7QzUmFjaGVsIFdp<br />
bGxtZXIgW2NlcnRpZmljYXRpb25dIDxyYWNoZWxAd2lsbG1lci5vcmc+iE4EEBEC<br />
AA4FAjn6yYUECwMCAQIZAQAKCRC30ABpXpgYMFTFAJ0WqZwUXbD0H7YCGR7rI8jB<br />
Rh8E2wCePBrQBC1+shZrXCY0proYCkYfWdA=<br />
=UObU<br />
- -----END PGP PUBLIC KEY BLOCK-----<br />
&lt;/key&gt;<br />
<br />
&lt;key name=&quot;serverCertification&quot;&gt;<br />
- -----BEGIN PGP PUBLIC KEY BLOCK-----<br />
Version: PGP Desktop 10.0.1 - not licensed for commercial use: www.pgp.com<br />
<br />
mQGiBDmhGRERBAC9F7VF7ZNcwhffdFS2Sg0AcsF9gdhEEggZmBT1ezM5BYEO4lvN<br />
EJjezFilNxMLE3mP9E95mtRUEEtIx4ViyAGjVPwRBVQA2BNf+rbvCReBhhlJTFkN<br />
GOSHd65k4mDCflJAn7EX2OpST9tEAhpBs82w4OxlHIxmnav8iyD0O07sHwCgzYJI<br />
Xv3TEqERh0eDPEQ80MqGYEkD/Aj12tRhZYhYlVtEmJ4MrET9Ezuyhn8kQv89iBNK<br />
u2mN//LK4cqfJos1SJ3qXT16AHQQvfI0AUsI1ZQ+piq9pZ+sUMwpRnoQHM5SKux5<br />
UYcIM9aklW0zYAt+WjyrQBhN0eW0uzF40NVZHIH592dz/1RbNKf0hSDKBeCERTxk<br />
/zRDA/9rgvwyclIq4VTgA9AgwHC+JrKwbtJsawb4eYZPSbDe/pl2bQT9haTuLBKs<br />
Olz57Er5Vto6DWb1hs8gzb107u7CGYholr/tyjiPRhDvOcVQpZudkCE/1UXpawT/<br />
P4tPUvrBIVNK5SmHVRz6nsJxMxYm6Pr14+t8mgS1jrr/TxFTW7Q+U3lzdGVtaWNz<br />
IE9wZW5QR1AgU09YIFtvcGVyYXRvcl0gKGRzczEpIDxzZXJ2ZXJAc3lzdGVtaWNz<br />
LmNvbT6IVgQTEQIAFgUCOaEZEQQLCgQDAxUDAgMWAgECF4AACgkQKfOLUygtdArw<br />
3QCeJ8bEfVFS2etPkFus6esJfZ0+2OUAoK4AIIjFB+9CsoEkCn4dJBRTUKen<br />
=L806<br />
- -----END PGP PUBLIC KEY BLOCK-----<br />
&lt;/key&gt;<br />
<br />
&lt;/digitalAssetContract&gt;<br />
-----BEGIN CONTRACT SIGNATURE-----<br />
fm7l4FyMW7p0ayZcBwq2JHGnSzRIwS75tvkNxpEnrvcahwv68RKFmxDr7Hz8000u<br />
d9oOznZpjga17gwSlTS1AsiX3GAix5CLCZLenAV6dUUsgEBOK2kCnB/6gc8c5FVP<br />
QH0mF0ICfxDPSY2Y0/lXVww8URis0mmHz3F+NX9S9B4=<br />
-----END CONTRACT SIGNATURE-----<br />
</pre><br />
[[Sample Cash|To read about the cash tokens, click here]]. <br />
<br>[[Sample Mint|To read about the OTMint object, click here]]. <br />
<br>[[Messaging|To read about messaging and OTMessage, click here]].</div>Cryptomanhttp://opentransactions.org/wiki/index.php?title=TestGUI&diff=81TestGUI2013-06-11T16:46:41Z<p>Cryptoman: Created page with "Click here for the [https://github.com/FellowTraveler/Moneychanger Moneychanger official page] and SCREENSHOTS. Moneychanger is a test GUI for Open-Transactions, written in J..."</p>
<hr />
<div>Click here for the [https://github.com/FellowTraveler/Moneychanger Moneychanger official page] and SCREENSHOTS.<br />
<br />
Moneychanger is a test GUI for Open-Transactions, written in Java.<br />
<br />
-------------------------<br />
<br />
See also:<br />
<br>[[OT-Server]]<br />
<br>[https://github.com/FellowTraveler/Open-Transactions/wiki/opentxs opentxs command-line tool]<br />
<br>Write your own client using the [https://github.com/FellowTraveler/Open-Transactions/wiki/use-cases OT high-level API].</div>Cryptomanhttp://opentransactions.org/wiki/index.php?title=OT-Server&diff=80OT-Server2013-06-11T16:41:49Z<p>Cryptoman: Created page with "After you <code>make install</code>, the OT Server will be named <code>otserver</code> and most likely will be located in <code>/usr/local/bin</code> You can probably run it ..."</p>
<hr />
<div>After you <code>make install</code>, the OT Server will be named <code>otserver</code> and most likely will be located in <code>/usr/local/bin</code><br />
<br />
You can probably run it simply by typing: <code>otserver</code><br />
<br />
If you run it with blank data, it will walk you through the process of creating a fresh server. You will want to make use of the sample contracts in the sample-data folder for this process.<br />
<br />
You can also copy sample data from the sample data folder, which includes pre-created server and client data, allowing you to instantly get OT up and running without having to create anything. Just copy the sample data folders for server_data and client_data into <code>~/.ot/server_data</code> and <code>~/.ot/client_data</code><br />
<br />
<br />
-----<br />
<br />
<code>make install</code> creates the <code>~/.ot</code> folder, including the server's folder: <code>~/.ot/server_data</code> (That is where the otserver will look, by default, to load its data.<br />
<br />
The main datafile is: <code>~/.ot/server_data/notaryServer.xml</code><br />
<br />
When you first start playing with OT, be sure to keep an eye on the server output while you are running your client, so you can see what is happening on the server side.<br />
<br />
<br />
-----<br />
<br />
See the <code>include/otserver/OTServer.h</code> and <code>src/otserver/OTServer.cpp</code> files for the bulk of the server code.<br />
<br />
<br />
-----<br />
<br />
''See also:'' The [[TestGUI|OT Test GUI]] The [[opentxs|command line test wallet]] The [[API|OT API]] and [[Use Cases]].</div>Cryptomanhttp://opentransactions.org/wiki/index.php?title=List_of_Classes&diff=79List of Classes2013-06-11T16:34:21Z<p>Cryptoman: </p>
<hr />
<div>Open Transactions is, at its core, a class library. I hope to have documentation for all these classes sometime soon.<br />
<br />
In the meantime, be sure to read the [[API|detailed notes on the API]] and the [[Use Cases]] for the API.<br />
<br />
<br>USER / PSEUDONYM <br />
<br>'''OTPseudonym''' -- Primarily a key pair. (Public/private keys.) Used as an identity; also manages lists of request numbers and transaction numbers for that identity on various OT servers. Often used for signing and verifying signatures on contracts. ''A pseudonym may have many asset accounts. A pseudonym may be registered on multiple servers.'' <br />
<br>'''OTIdentifier''' -- A 256-bit hash, usually of a public key or a contract, displayed as Base62. (The Nym's ID is a hash of his public key. An Asset Type's ID is the hash of its asset contract. The Server ID is a hash of the server contract. Etc.)<br />
<br />
<br>CONTRACTS / INSTRUMENTS <br />
<br>'''OTContract''' -- Most other classes are derived from this one. Contains the actual XML contents, as well as various data values that were loaded from those contents, including public keys. Also contains a list of signatures. <br />
<br>'''OTScriptable''' -- Derived from OTContract, but enables scriptable clauses. Also contains a list of parties (each with agents and asset accounts) as well as a list of bylaws (each with scripted clauses, internal state, hooks, callbacks, etc.) <br />
<br>'''OTServerContract''' -- Derived from OTContract. Specific to an OT server. <br />
<br>'''OTAssetContract''' -- Derived from OTContract. Specific to an ASSET TYPE. (May be registered on multiple servers.) <br />
<br>'''OTBasket''' -- Used in basket currencies. Derived from OTContract. <br />
<br>'''OTInstrument''' -- Has a date range, a server ID, and an asset ID. Derived from OTScriptable.<br />
<br>'''OTTrackable''' -- Has a transaction number, user ID, and an asset account ID. Derived from OTInstrument. <br />
<br>'''OTCheque''' -- A financial instrument. Derived from OTTrackable. <br />
<br>'''OTCronItem''' -- Derived from OTTrackable. OT has a central &quot;Cron&quot; object which runs recurring tasks, known as CronItems. <br />
<br>'''OTAgreement''' -- Derived from OTCronItem. It has a recipient and recipient asset account. <br />
<br>'''OTPaymentPlan''' -- Derived from OTAgreement. Allows merchants and customers to set up recurring payments. (Cancel anytime, with a receipt going to both inboxes.) <br />
<br>'''OTOffer''' -- Derived from OTInstrument. An OTMarket has a list of these. <br />
<br>'''OTTrade''' -- Derived from OTCronItem. These correspond to offers on the market. Anytime an offer processes on the market against another offer (a &quot;trade&quot;) then the quantities are updated here and saved as the latest cron receipt (with a copy going to your inbox, along with a copy of your original signed market offer.) <br />
<br>'''OTSmartContract''' -- Derived from OTCronItem. All CronItems are actually derived from OTScriptable already (through OTTrackable/OTInstrument). But OTSmartContract is the first/only Cron Item specifically designed to take full advantage of both the cron system AND the scriptable system in conjunction with each other. Currently OTSmartContract is the only actual server-side scripting on OT.<br />
<br />
<br>DIGITAL CASH <br />
<br>'''OTMint''' -- There is a different mint for each asset type, plus a new version of that mint replaces the old version, whenever a new series of the currency is rotated in. (This is necessary to allow the server operator to occasionally destroy the spent token database, which would otherwise continue growing forever, with the operator forced to maintain it forever.) <br />
<br>'''OTToken''' -- A basic unit of untraceable digital cash. Tokens have denominations (1, 5, 10, 25, 100, etc) and OTToken works together with OTMint. All of the Lucre code in OT resides in these two classes. (Coin, Bank, PublicBank, etc.) <br />
<br>'''OTPurse''' -- Since an OTToken can only have a set denominational amount (1, 5, 10, etc), it is necessary to carry purses full of tokens, in order to withdraw exactly the correct amount that you require (such as 8734, or 98, or 139, etc.) Thus, OT users will more commonly interact with purses than with actual tokens.<br />
<br />
<br>NUMBERED ACCOUNTS / SIGNED RECEIPTS <br />
<br>'''OTTransactionType''' -- This is the base class for OTLedger, OTTransaction, OTItem, and OTAccount. Derived from OTContract. <br />
<br>'''OTLedger''' -- Contains a list of transactions. Used in messages, and also used for inbox/outbox. <br />
<br>'''OTTransaction''' -- The basic transactional unit, including a transaction number(s), and a list of transaction items. <br />
<br>'''OTItem''' -- OTTransaction contains a list of these. (Usually two.) There might be a withdrawal item and a balance agreement item. Or a deposit item and a balance agreement item. Or a transfer item and a balance agreement item. Etc. (All transactions require a balance agreement.) <br />
<br>'''OTAccount''' -- The class that handles the intermediary file for account balances.<br />
<br />
<br>CRYPTO UTILITY CLASSES <br />
<br>'''OTEnvelope''' -- Encrypts/decrypts a piece of data (usually an OTASCIIArmor) using a Nym's private and public keys. <br />
<br>'''OTPassword''' -- OT is endeavoring to use secure password storage in RAM. <br />
<br>'''OTSymmetricKey''' -- For password-based crypto. <br />
<br>'''OTAsymmetricKey''' -- An OTPseudonym has a public/private key pair. <br />
<br>'''OTSignature''' -- An OTContract has a list of these. <br />
<br>'''OTASCIIArmor''' -- Takes string or binary data, and then packs it, compresses it, base-64 encodes it, and returns as a base64-encoded string. Derived from OTString. <br />
<br>'''OTSignedFile''' -- Uses a Nym to sign any content, and then stores it as an OT contract, including the file path information inside the contract as well. <br />
<br>'''OTCachedKey''' -- The private keys of the Nyms in the wallet are encrypted to the cached master key (as their &quot;passphrase&quot;.) The cached key itself is randomly generated and then kept encrypted to a symmetric key from a key derivation algorithm (from the user's passphrase.) It uses threads to erase the cleartext portion of the cached key after X seconds have passed. The user will be forced to enter his passphrase again after X seconds. <br />
<br>'''OTCrypto''' -- I've started the process of moving all OpenSSL-specific code into &quot;OTCryptoOpenSSL&quot; which is derived from OTCrypto and accessed as OTCrypto::It(). This will make it easier, in the future, to swap other crypto libs in and out of OT. <br />
<br>'''OTKeyring''' -- If configured to do so, OT will cache the derived key (used in OTCachedKey, above, to unlock the actual cached master key) using the system keyring. Currently supporting: gnome-keyring, Mac Keychain, KDE KWallet, and Windows DPAPI.<br />
<br />
We should always endeavor to use standard protected memory APIs and authentication agents (such as gpg-agent and ssh-agent.) We will endeavor to use our own crypto as a separate layer, wherever possible. We will endeavor to use random memory layout, and code obfuscation, stack smashing protection, static and dynamic analysis, clean out the buffer overflows etc. Security never stops!<br />
<br />
<br>CLIENT <br />
<br>'''OTClient''' -- The primary class on the client side. <br />
<br>'''OTServerConnection''' -- Manages the client's connection to a specific OT server. <br />
<br>'''OTWallet''' -- Manages client-side list of Nyms, Asset Contracts, Server Contracts, and Accounts.<br />
<br />
<br>SERVER <br />
<br>'''OTServer''' -- The main class for the OT transaction server (transaction.exe). <br />
<br>'''OTClientConnection''' -- Manages a single client connection to that server. <br />
<br>'''OTCron''' -- Manages a list of Cron Items (that process their terms on a regular basis, including payment plans, market trades, and who knows, maybe someday: Ripple orders.) <br />
<br>'''OTMarket''' -- Manages a list of active offers, and processes trades between them. There may be many markets on any given OTServer. Derived from OTContract.<br />
<br />
<br>FOR THE PROTOCOL <br />
<br>'''OTMessage''' -- Derived from OTContract. <br />
<br>'''OTMessageBuffer''' -- Contains a list of OTMessages. <br />
<br>'''OTPayload''' -- Derived from OTData.<br />
<br />
<br>BASIC DATA TYPES <br />
<br>'''OTData''' -- The base class for binary data in OT. (Like OTString, except for binary data.) <br />
<br>'''OTString''' -- The basic string class for OT. (In the C++ language, the standard classes aren't meant to be used as &quot;first class&quot; classes, but need to be wrapped. OTString is built around its interface with other classes in the OT library, and it is easy to swap the internal string code later, without impacting anything else.) <br />
<br>'''OTStringXML''' -- Derived from OTString. Used in conjunction with the XML library that OT currently uses for its XML contracts. (irrxml.)</div>Cryptomanhttp://opentransactions.org/wiki/index.php?title=List_of_Classes&diff=78List of Classes2013-06-11T16:33:12Z<p>Cryptoman: Created page with "Open Transactions is, at its core, a class library. I hope to have documentation for all these classes sometime soon. In the meantime, be sure to read the [[API|detailed note..."</p>
<hr />
<div>Open Transactions is, at its core, a class library. I hope to have documentation for all these classes sometime soon.<br />
<br />
In the meantime, be sure to read the [[API|detailed notes on the API]] and the [[Use Cases]] for the API.<br />
<br />
USER / PSEUDONYM <br />
<br>'''OTPseudonym''' -- Primarily a key pair. (Public/private keys.) Used as an identity; also manages lists of request numbers and transaction numbers for that identity on various OT servers. Often used for signing and verifying signatures on contracts. ''A pseudonym may have many asset accounts. A pseudonym may be registered on multiple servers.'' <br />
<br>'''OTIdentifier''' -- A 256-bit hash, usually of a public key or a contract, displayed as Base62. (The Nym's ID is a hash of his public key. An Asset Type's ID is the hash of its asset contract. The Server ID is a hash of the server contract. Etc.)<br />
<br />
CONTRACTS / INSTRUMENTS <br />
<br>'''OTContract''' -- Most other classes are derived from this one. Contains the actual XML contents, as well as various data values that were loaded from those contents, including public keys. Also contains a list of signatures. <br />
<br>'''OTScriptable''' -- Derived from OTContract, but enables scriptable clauses. Also contains a list of parties (each with agents and asset accounts) as well as a list of bylaws (each with scripted clauses, internal state, hooks, callbacks, etc.) <br />
<br>'''OTServerContract''' -- Derived from OTContract. Specific to an OT server. <br />
<br>'''OTAssetContract''' -- Derived from OTContract. Specific to an ASSET TYPE. (May be registered on multiple servers.) <br />
<br>'''OTBasket''' -- Used in basket currencies. Derived from OTContract. <br />
<br>'''OTInstrument''' -- Has a date range, a server ID, and an asset ID. Derived from OTScriptable.<br />
<br>'''OTTrackable''' -- Has a transaction number, user ID, and an asset account ID. Derived from OTInstrument. <br />
<br>'''OTCheque''' -- A financial instrument. Derived from OTTrackable. <br />
<br>'''OTCronItem''' -- Derived from OTTrackable. OT has a central &quot;Cron&quot; object which runs recurring tasks, known as CronItems. <br />
<br>'''OTAgreement''' -- Derived from OTCronItem. It has a recipient and recipient asset account. <br />
<br>'''OTPaymentPlan''' -- Derived from OTAgreement. Allows merchants and customers to set up recurring payments. (Cancel anytime, with a receipt going to both inboxes.) <br />
<br>'''OTOffer''' -- Derived from OTInstrument. An OTMarket has a list of these. <br />
<br>'''OTTrade''' -- Derived from OTCronItem. These correspond to offers on the market. Anytime an offer processes on the market against another offer (a &quot;trade&quot;) then the quantities are updated here and saved as the latest cron receipt (with a copy going to your inbox, along with a copy of your original signed market offer.) <br />
<br>'''OTSmartContract''' -- Derived from OTCronItem. All CronItems are actually derived from OTScriptable already (through OTTrackable/OTInstrument). But OTSmartContract is the first/only Cron Item specifically designed to take full advantage of both the cron system AND the scriptable system in conjunction with each other. Currently OTSmartContract is the only actual server-side scripting on OT.<br />
<br />
DIGITAL CASH <br />
<br>'''OTMint''' -- There is a different mint for each asset type, plus a new version of that mint replaces the old version, whenever a new series of the currency is rotated in. (This is necessary to allow the server operator to occasionally destroy the spent token database, which would otherwise continue growing forever, with the operator forced to maintain it forever.) <br />
<br>'''OTToken''' -- A basic unit of untraceable digital cash. Tokens have denominations (1, 5, 10, 25, 100, etc) and OTToken works together with OTMint. All of the Lucre code in OT resides in these two classes. (Coin, Bank, PublicBank, etc.) <br />
<br>'''OTPurse''' -- Since an OTToken can only have a set denominational amount (1, 5, 10, etc), it is necessary to carry purses full of tokens, in order to withdraw exactly the correct amount that you require (such as 8734, or 98, or 139, etc.) Thus, OT users will more commonly interact with purses than with actual tokens.<br />
<br />
NUMBERED ACCOUNTS / SIGNED RECEIPTS <br />
<br>'''OTTransactionType''' -- This is the base class for OTLedger, OTTransaction, OTItem, and OTAccount. Derived from OTContract. <br />
<br>'''OTLedger''' -- Contains a list of transactions. Used in messages, and also used for inbox/outbox. <br />
<br>'''OTTransaction''' -- The basic transactional unit, including a transaction number(s), and a list of transaction items. <br />
<br>'''OTItem''' -- OTTransaction contains a list of these. (Usually two.) There might be a withdrawal item and a balance agreement item. Or a deposit item and a balance agreement item. Or a transfer item and a balance agreement item. Etc. (All transactions require a balance agreement.) <br />
<br>'''OTAccount''' -- The class that handles the intermediary file for account balances.<br />
<br />
CRYPTO UTILITY CLASSES <br />
<br>'''OTEnvelope''' -- Encrypts/decrypts a piece of data (usually an OTASCIIArmor) using a Nym's private and public keys. <br />
<br>'''OTPassword''' -- OT is endeavoring to use secure password storage in RAM. <br />
<br>'''OTSymmetricKey''' -- For password-based crypto. <br />
<br>'''OTAsymmetricKey''' -- An OTPseudonym has a public/private key pair. <br />
<br>'''OTSignature''' -- An OTContract has a list of these. <br />
<br>'''OTASCIIArmor''' -- Takes string or binary data, and then packs it, compresses it, base-64 encodes it, and returns as a base64-encoded string. Derived from OTString. <br />
<br>'''OTSignedFile''' -- Uses a Nym to sign any content, and then stores it as an OT contract, including the file path information inside the contract as well. <br />
<br>'''OTCachedKey''' -- The private keys of the Nyms in the wallet are encrypted to the cached master key (as their &quot;passphrase&quot;.) The cached key itself is randomly generated and then kept encrypted to a symmetric key from a key derivation algorithm (from the user's passphrase.) It uses threads to erase the cleartext portion of the cached key after X seconds have passed. The user will be forced to enter his passphrase again after X seconds. <br />
<br>'''OTCrypto''' -- I've started the process of moving all OpenSSL-specific code into &quot;OTCryptoOpenSSL&quot; which is derived from OTCrypto and accessed as OTCrypto::It(). This will make it easier, in the future, to swap other crypto libs in and out of OT. <br />
<br>'''OTKeyring''' -- If configured to do so, OT will cache the derived key (used in OTCachedKey, above, to unlock the actual cached master key) using the system keyring. Currently supporting: gnome-keyring, Mac Keychain, KDE KWallet, and Windows DPAPI.<br />
<br />
We should always endeavor to use standard protected memory APIs and authentication agents (such as gpg-agent and ssh-agent.) We will endeavor to use our own crypto as a separate layer, wherever possible. We will endeavor to use random memory layout, and code obfuscation, stack smashing protection, static and dynamic analysis, clean out the buffer overflows etc. Security never stops!<br />
<br />
CLIENT <br />
<br>'''OTClient''' -- The primary class on the client side. <br />
<br>'''OTServerConnection''' -- Manages the client's connection to a specific OT server. <br />
<br>'''OTWallet''' -- Manages client-side list of Nyms, Asset Contracts, Server Contracts, and Accounts.<br />
<br />
SERVER <br />
<br>'''OTServer''' -- The main class for the OT transaction server (transaction.exe). <br />
<br>'''OTClientConnection''' -- Manages a single client connection to that server. <br />
<br>'''OTCron''' -- Manages a list of Cron Items (that process their terms on a regular basis, including payment plans, market trades, and who knows, maybe someday: Ripple orders.) <br />
<br>'''OTMarket''' -- Manages a list of active offers, and processes trades between them. There may be many markets on any given OTServer. Derived from OTContract.<br />
<br />
FOR THE PROTOCOL <br />
<br>'''OTMessage''' -- Derived from OTContract. <br />
<br>'''OTMessageBuffer''' -- Contains a list of OTMessages. <br />
<br>'''OTPayload''' -- Derived from OTData.<br />
<br />
BASIC DATA TYPES <br />
<br>'''OTData''' -- The base class for binary data in OT. (Like OTString, except for binary data.) <br />
<br>'''OTString''' -- The basic string class for OT. (In the C++ language, the standard classes aren't meant to be used as &quot;first class&quot; classes, but need to be wrapped. OTString is built around its interface with other classes in the OT library, and it is easy to swap the internal string code later, without impacting anything else.) <br />
<br>'''OTStringXML''' -- Derived from OTString. Used in conjunction with the XML library that OT currently uses for its XML contracts. (irrxml.)</div>Cryptomanhttp://opentransactions.org/wiki/index.php?title=Sample_Purse&diff=77Sample Purse2013-06-11T16:20:50Z<p>Cryptoman: Created page with "Whenever cash tokens (digital bearer certificates) are exchanged between the client and the server, they are stored in encrypted form, inside a purse. This pur..."</p>
<hr />
<div>Whenever [[Sample Cash|cash tokens]] (digital bearer certificates) are exchanged between the client and the server, they are stored in encrypted form, inside a purse. This purse can then be stored to disk or base-64 encoded and attached to a deposit transaction, or exchanged for new tokens, etc. Or you can re-encrypt them to your friend's public key and send them to him. Etc.<br />
<br />
A good wallet software will periodically scan the purses stored on your hard drive for each asset type and make sure none of the tokens are getting close to their expiration period. (And exchange them automatically if they are.)<br />
<br />
<pre><br />
-----BEGIN SIGNED PURSE-----<br />
Hash: SAMY<br />
<br />
&lt;?xml version=&quot;1.0&quot;?&gt;<br />
<br />
&lt;purse version=&quot;1.0&quot;<br />
userID=&quot;&quot;<br />
assetTypeID=&quot;XUHBvdsWAEmErZMzHaRKaNPaAVsUvKwL4uLY4nOY2s4&quot;<br />
serverID=&quot;44FmyPAgrmGu671RywGnhrt8aR6tzmNFn9WKQ92BXn&quot;&gt;<br />
<br />
&lt;token&gt;<br />
AAAAgFRofqqN/HNHy1hblXaPxZGUMtma79fT8m/XCaC0fGN/Vdu+S6NUTyQnWIS1<br />
U2N5C76xFihETjT8P//BgvKq2loTloZqbKTT60URrY8s7ZkuyQYeu8TGqjJDwfd0<br />
/sqCGUMs/8n5NjJ1F3hqoe7Dzw2ptjabVHoHWn3s3vpFFMxJ8NyBauVa4RGT51mP<br />
9VBwk/Zzx1YqrOY4/i1nQ5MGlimB5q+qGGjIhD5L2YLyShTiwyiOaGUL+cnldBji<br />
NgwWuk8FIBqgbpmnlupZshPI2svgjca1vqRkCBKfSv5YT7MqyFVR6CG/f5Dxx7rm<br />
in0Il00+4CT6liiBji2mxsYBar7LhqDaZ3zlqwIKGM0qOAiPsormFkmd1JJaahph<br />
Y5fq0eXRLGrBDh5cpMb0ip/uw3rpRpdqTK0VxBBjlHRAMbdGcdP3hOsBTlCyN2GW<br />
nT2hTejbkM4IGDhKcosSLNOjYfgLSqVVoxIqSgCM7bV5hfjYqqFvGjClF6wTvQLE<br />
roxAHPuuFOpBR+VAg6gv/vc+ewIu7zDJGKhVRoFy6Apcp9hW6MY8+pfG+r/CZNVx<br />
HAeN++kFRsoD49+geVWsA/+qF8gYMZ8kNdWGviQ3aCtcOFnmDx0dFOZkrOzwUbs0<br />
G1I5EUoTIlqcbasVY6wZJpIniTjHJORboGD1I6f0Ew0SZ30J1x28J3IzX9ctubaD<br />
p8WbeEztN9pBSfEYgUH6iSgDbhEQwRRvzJW5ihFZUlocfQMFRIr+U4NPBtiYTa83<br />
p31WUBqn5gP7iA8rPNNxe0h1LdUohzGrUy0FYQdAVeoiXfEnHSMVvkzOsrQB7ofS<br />
2MhSPJGHZadG2/0GGVkorpZ+vqLQbpcXFRWjN3fRKSjrJwg42i6BVLQHI5X4WdNA<br />
2dwXlvR/DErhxogOI+sWPbv3rPJJ0TXWVnHYXElC7z6bs2Bogbsn9ypDUJ08NW+7<br />
VtFXz2Pqh3fliwuIfq8ObevxJr/YjT8W2Dtj6lbibU4qtOUNHhxH7geEip4ydFWl<br />
G9Ldww1RsREzMElybEc/mFbd6LdfZH63k0kx1ZxFqij8H0bW/asymPB1DO+Um1jo<br />
ZvoUxmQPoIk6IdFOxz79i+CmwikSTwv946gBCVzHffIR+nVyOJ9n/zmw/im5ZFye<br />
VIzuY08WB8pLQdpkJsavDDST9XFoHNhlVAj4+B1JR8ERO/4H5zmYIQKE75SoVuty<br />
OXwlmcbTTj5Mle1CVDqKmA6WlIXF3Et+8CVudKdSmjGlwT6vqZvEyW57dY5GblDq<br />
DZ+PWbdMgJ64alktHLTFLq5KR32MBqU+w+zn+E7MUVuC/3D/Nw+nqCf9SU/BPo+t<br />
M1CVYxjkELfNbQwJAs7i8ueHg3PzvMcAS1f/+mqM3mS68HYrSTJUhDUTbxzG4S9p<br />
yCTXs2vVYzvd5zhSliQHnKNyDS3xuHGsK+rgp0W+qXg7sj4HLz2M7Q4m13yPXZRI<br />
x6ekk0Vqwcho9ernOeE1xCC/zmr6rv4qDjsCOODrP3W030F0cnu53XGkUA8Nd9fs<br />
CQVSsCLe+gFafgx4SufiGePaWnetus1pi+XDRG6gkSm6fICLK0+yFEdkaygCR1Kd<br />
eGEzrb+smPY9sU5ApizxUEtgZQOv9L6SiXJ6hW0f7eH6O64J1yDGdgJ3V7+/rhYP<br />
Hwag9tlRu5xOy1BpIBKv7Wy4MuZLohkLM/6ewhWtCx96wmxmx/1YA9SLqYhpAbBx<br />
81IMzqNKs2Vy7IVjtluQYQEXaGr6rM3yEQbdJcbUTeu15TLTdASkSRv3R7x/aG19<br />
Ok2sFenPWKyRgMcW5ienrXAvwWDWYcDBo9f62FrrMA2YfTr/d0oTia9RUtGVeVYw<br />
nree9QDQl2R0BCeXpnFe406dS0Q+yQ3cnXcXTU7v/1EBn6mb6sxmA43cC0NDkgBF<br />
Y87BJiR9rsgZiUsG5KJ+P4fZeGE2Iyl5kyw5vJut+018UDE/79wzXPTIJAgst1/a<br />
D/8yRFoOAyrCOsAGnd8xoHgpl/vdYtL1Owa6Tgbq4bUxFyYdcQ9mW8YvAKNRgQck<br />
LM6hl053VsPwAgE9xXiJEamyHwM=<br />
&lt;/token&gt;<br />
<br />
&lt;token&gt;<br />
AAAAgAQvUUIIxjvSkTV4UHeHfKG0nQR1CD+f2Xr30vZBgRHmRZ1e3B3hVSl6CFBV<br />
Mqqjz2mBSoZikIqfzIe7xMByzs/VrC0JnSPkhlOSWBuuS8VhBdXdwzKyUYMN8ohd<br />
SMZA59omTjJ2vl+wOHAZWqjdpXrduFiV4m/EyPNeE9I4rNkcEBfJWYH57hCut3og<br />
Vdb6/hB4lqsVFpspryQs1jo/9U17XMq0nILNRAMstIwpmoXxcJT/yyweleou77cN<br />
VP50CDbIUwZmfE4i3ICohDcVKTDlprgYpvaqEQGEhgZI6t9+lvPkIg5BkoJzX+Et<br />
PKynT8inL1milxAZhrRAHLQy0i/fKZapG2hvjjetCE66oovKcLs7mWSFbCPEddcP<br />
74ssyHpr5TdRt6fE4yTF2wzzthvadr3CbRmdE4UqdLYQwa0wcb0i+kAWNYTTICgQ<br />
8Zo0hMfyDUOpAAxQ3CJCQYQ0GXalxFa9cE5JBv2uiSkqaDTdLKkMtazDh+XSWJh9<br />
cdfGpR3SLnfJD+LLPnndJcbWc7fEDA6NCNOVSsxEokypS1V28ZOyQrQ4/uszktnU<br />
6r8CKmrtgt8PeMhK4mK4IuTYKfvmC3i8vn45LwtQ6LQfrOxciEuOm51IIO/ou5Yk<br />
Te7C+WDy9GhnF83T1EaxSjGMZMM3i05CmiGy9GSZ44H4Xetmc33Prvx6cVQKAkVR<br />
Or91M8Q0zH65Clcjay0JkC1XUO2AjjO9GHhseNGx0jL0TipmcpJ9DHQl0bz0l+Qw<br />
3KsubpOx7S/r59r66U+Ul9GGyukT7Tu4PrFYpd2ntLLSG7AqvT6P8p//ShIxCiRd<br />
f4A6K72UyFP6rjHJz0LKI5EZA/D/RCfG8LluCg8IgO69e0RATJ9IhMyXys+nWhDB<br />
kh+hLoYOQviLpCH6z8DCKw8hPk8fCHi7oKUkf8TkriJWBKzB0OLdk3Si1aML7OfZ<br />
7YLQ72K6pfkLEwtJW2hTvmnK5g1pX3SevryIVSvk4ZZq8QzL/xQ7MIFW4otYMiWi<br />
ZjpmIDtY4oFdz1XHQt865FmvOjP0P/7Mx1fFwnls37EKVPBts3zZPm5IvzQf0YWk<br />
u4LeP1W0XJv3J2t88QDo/pUk7E6lgXUVtcv5LxzX5+qk2Vn4IjGfDiNRhsVfHeUj<br />
jkiLHmp0lVBJ1a76cH1scrYSedg6d0k3uHn+kj/t5dqQtCBeFGKOYhCW2VL4Ge5C<br />
6TAWphhWf6572ci6M/tBOvNR5Sx2aT1GFQxAUvre2/sAzbqnm8OSWNtc7UjrV71L<br />
pq/xn0tapFZOW5ZMkNaGQAnPWLYw7ekgPh4vGXzwUwGh0M2PYznDZrsOiPeTk98s<br />
sub3GcC5KGBCY2u/uhbkKtr2YpzNQeJoMnZyaBKWFRdt7bgfgu7JKQkJS1pBBgei<br />
ALckue2ndaKvdpWBon8kQvyE6kjjRsQVQNhOQNgJF2BPSIyXpHaYep0I6um8x8Du<br />
UrYgBcUohS768Zb7SDEfz4F37KULvEZX9ARjTiIXyVzJn5RKWgNBNd9SkxDN43xA<br />
QTLuXde8KQyyYzTngzzpNkolVFkZoxWsUbwel2YIki5ebTFK79iEx7aG31E4JXXA<br />
HZvieg2vhVuYBdQb8e1XezcTbZpieH816qV5kArdgQIx3IfW/5EyLcYob3g9aq4q<br />
5T6PjpLZKyP6nIWf0DKYY3ng0hOWTceFUdzRKJLIPs1+nAJFkXhHzr629y5jDRwr<br />
X45w0isFVG5qc6rTXpaxbN0Dm+QxXPVIVhXZLq0SXxMhz+gvJO41cKo0pLbMxEDf<br />
Rm9eEMm4afJdqUTfWxYvA8suz5RR2HCNO7Y02vs4ur3m8srL/zO19huAWf2kXEaf<br />
KrNcD6KXxHJmry/Rk79FjKimA7eQ/IIRe4YToqPdI41JiegnajQWXZUNhAuI6TOe<br />
Y+urIjyWjKMz7w5ETGiiWyAWvRfuhasvTIMSSxZMTgFFFsghi1Z9zh8QOQWH4RzQ<br />
14TsJdplIihUXGDI65xuJuGd6Em4f4AB+UEqpa/wNvNaZQPbBplcB5p6uDELgTtr<br />
UW0agpt3qwWCC8a2LxiygEBwaGQ=<br />
&lt;/token&gt;<br />
<br />
&lt;token&gt;<br />
AAAAgDkwXuHxrPHUFwlBM58S1rHHzHaNY65hcjIvtPg561A/BOuJF7y//+RRZYdb<br />
1/HtpkE6FliYfMvBlKPqxNKl1RrfadCEtBxwf9yHIvvKsUdHPS0CaeqM2Iez/vIX<br />
r+tMJB1+tRQ5iScJTRxt9WPWVBF8WyOH3pPtzFZPlhmdAfTGywCQjtR8oJK7Pd4Z<br />
NxygYcF7+bRA2ylgFaLzQWBgC8J9aXW/HUjSXkX1cDlJ6hYrYMFdh4nkVb1wtRfH<br />
bHgob2+uVr/w42ySd4aE9EPmwbhDUyLShvqNV/xBehl869j6jiylLK5mpqyv+T7E<br />
+N5zWTe0L1hDi6MqcIpb00IZaNEp1YowzqV9Pm7K7ZOKYraA9zV3JbHaYw9UWLSa<br />
qUSvet+vOxRLJIV/MaQj2iHAMxvPbFE3Ft2DH2tyDTUqn0kpB0cIv4uKViYBXBpc<br />
c5dyMBeBCJCQV50hznnnid5SWblT1wVPlgb7A/vS5QjzDg3efmCZBGQ2bRHXWXov<br />
PvEmQlvHNdxKnxQeghLHlrAIdfzLddb7YVxEk9bwXdqaw0qoPcucO+IUEtYCbuls<br />
/b1Fp0OGdyUOODK0I8/sx0kYyYJDxWcW4xEBYpTzuly1HfnF5/qBND+Mw0N3OPQN<br />
X9VHrLh3pm298Lod7PgIk1mSlHOVc/EzaUNW/Weud+3HwQMWNA3swCPD1E2ft9Jp<br />
xoQsIsePwk29OvLL2+EzpAWGRrIo71NbcuL8S5e5el333UtRhSkAp8C8FxA0P0AL<br />
Hrp2SVYx3fXF1pwkH2cKo43DpmQz29mBphmNV8L6s+1MhwoAm+uFz2Wa0F37T872<br />
J5DCm/GMmWLvjJH6j3u+UxLYyPUNhJi9m970dthgq7lS63R9CNuRLJ+TJZdV1jVx<br />
Pa+J3y1lcHBvxdUW1Z8MEz2eq24iSK/DsvH4c9XnBdH/hAq122WtOstDaFW9p+sf<br />
sHf/sDZ73XqQ71eKCaDA9YEf13/gI14qv245jTTGYHO0YS9VRuTq60PYyQlmCdL1<br />
SI1YrHuqVFBVJHNvaP0wPilawOgU0a1lNliB6mID6UkJfD2oMPo2BgainPOKzTxQ<br />
Vte5GEsMUNnXiiGce++mHzKrTdVuFZLnuNviwrx73yueA7/j1W7AnccpvhLNaFqS<br />
mvYAuVCl45COVuPMIB3bFRk9Yyuh5AnlJ87xzighaXGuj96S3oyMp9vWDx1xAw4j<br />
PppmZaBk/amSEK4ETA/EMNczM0yBI6LoSIEiJ27ZFUmyp0LXxOrPAq6aVq5f3i5D<br />
fcX71kFK3j4G7x8ZyOAJIPIQCr3fJl1P6zP8BGTsWI+s79ubjOh1TqKnz5h4K331<br />
3CqfwvDfOVorYwvN/fzJ2LyiDldGnnDNmQgZs9nP869c+l2h+um+UU7WWFS3UsG8<br />
h60ah4l6jwrZ/mb7G8Lix6cLHOcc6vUTml6jb5iJCyrNK7EbP/lvIGAJADu0+sS6<br />
WuoPM6gdtuogyoWRtuv1zbRvtnf5BwUgLbjVxUu4G3ws8TbpxTe2KZCSgWsNVC0Q<br />
vZ5SD3ac+/BoYx6Ts93CBuUFnIKByUQ7/BmLw0laBM76s2hss5x6HuVysrDp4C6J<br />
j/imHJ3Oz7OPWzyB+uPNwcKAVykGIEYgRE6QGhfQ0ilFVGpvtC6q8DV2EVa+FfxY<br />
6fz0vB5T9XBu6E0lW1KXG7UZqaCstYxRoLMjL49HOwsQKDDKYAvGvMDYTItFTB2R<br />
biw6sF3e4MS3njrvMYpUWClTzIt/I8LRckojI3onuQkAiFYZ9TzI9ElMQMuL08Rd<br />
fEIlGtj7Zk+cE4Uu8N3z19YxrSDrUTQEbgmVlEvrDyGQvz8jtxKf4q4Ph60MHUsO<br />
JIM6+1VKVZHWSAGKi0Msq7RQkD/9+jrXn9a9zAMQ5AK/Wlc78eBa2tOhw22dATRz<br />
Hxwz6Y1NDPrqIdfBk32e1YEJYzI/gvxXvk4i5XVcwoxv13hP29OdUGnqXyQP064t<br />
HRChU8YLhFCP2G3TxqmZGI4grmUFJs2k7DHlrnrLTZXBoSITUIAQJNaTDlJ8TnaH<br />
dtCtIJn8bmFW7cl4ADQyWcwCo00=<br />
&lt;/token&gt;<br />
<br />
&lt;/purse&gt;<br />
-----BEGIN PURSE SIGNATURE-----<br />
FXiCi1+/4GZjRF8otTamzdkxtvoM30V6WYuboR+nY0tAtNITz4210NVVMvOS7AQe<br />
bLW87EdmoUoSK7No1YSLSX7/5LV194PzBV2dOewJ8mzBTjn+Offpt2L5KukBz4Hg<br />
G7YCD4pR3EgSiQusaLmPNPCrBT9FTdWlKm6uKCLF0do=<br />
-----END PURSE SIGNATURE-----<br />
</pre></div>Cryptomanhttp://opentransactions.org/wiki/index.php?title=Sample_Mint&diff=76Sample Mint2013-06-11T16:18:06Z<p>Cryptoman: Created page with "Mints now have series and expiration. See the token page for more information on this. The Mint is uniquely identified by its [[Sample Currency Contract|Asset..."</p>
<hr />
<div>Mints now have series and expiration. See the [[Sample Cash|token page]] for more information on this.<br />
<br />
The Mint is uniquely identified by its [[Sample Currency Contract|Asset Type ID]], as well as its Series.<br />
<br />
Each token is signed with, and verified by, the Mint Private Key for a given AssetTypeID, for a given series, and a given [[Lucre and Denominations|denomination]].<br />
<br />
You may also find the [[Instruments|financial instruments]] chart interesting, including [[Sample Cheque|cheques]].<br />
<br />
Sample Public Mint file:<br />
<br />
<pre><br />
-----BEGIN SIGNED CONTRACT-----<br />
Hash: SAMY<br />
<br />
&lt;?xml version=&quot;1.0&quot;?&gt;<br />
<br />
&lt;mint version=&quot;1.0&quot;<br />
serverID=&quot;44FmyPAgrmGu671RywGnhrt8aR6tzmNFn9WKQ92BXn&quot;<br />
assetTypeID=&quot;XUHBvdsWAEmErZMzHaRKaNPaAVsUvKwL4uLY4nOY2s4&quot;<br />
cashAcctID=&quot;khlj2LLL9EYxPimNR4yAYDDzO5QzSg7LSxxsGc1RpsP&quot;<br />
series=&quot;0&quot;<br />
expiration=&quot;1289641563&quot;<br />
validFrom=&quot;1281865563&quot;<br />
validTo=&quot;1297417563&quot; &gt;<br />
<br />
&lt;mintPublicKey&gt;<br />
LS0tLS1CRUdJTiBQVUJMSUMgS0VZLS0tLS0KTUlHZk1BMEdDU3FHU0liM0RRRUJB<br />
UVVBQTRHTkFEQ0JpUUtCZ1FDNVg2MGNib1BQVGVaQ2pRUE9qSHBaRERiYgpNOVl6<br />
UlcyV3EvUHJIbDE3alZIa3hLMVgvbHdhM3NTR0hFTUFvUlp3SDFNa2trbTViWEow<br />
ZUpQWit2RVh6S0ZwCmNCeEZFODVBbXNibEM4U280T3dVY01HelQ0OTljQWl1aWsz<br />
bkdTR3hJbTE4K0NpOUdCNG5GVnNudXJkRzIxakgKck5MeEwzbVVwaHc0VzdwVkl3<br />
SURBUUFCCi0tLS0tRU5EIFBVQkxJQyBLRVktLS0tLQo=<br />
&lt;/mintPublicKey&gt;<br />
<br />
&lt;mintPublicInfo denomination=&quot;1&quot;&gt;<br />
eJwVkSuSGEAIRKP3NAx/xApg4CCJSKUqYk3un1mDAV5D9+9P+fj6XOI2tcvL4lN2<br />
qfBim+CEMRMkyVU7VClpjB0gZeZnK2bW9+gykIe9ctBwhTi7M1IOX4AcXcm5WaDH<br />
TQOYlLrqsJ7XJOccCQe23lZOSC6ra3isRFN5+pZ0Mx8hndo4hYC5b8i3VCqqvCoL<br />
5xuFW1eE34H0aHTWiTW80hmhFvab5KlK0bMfX/9+/v3z69OuQmTuYgl4O4YfJb7p<br />
53pLc6+5h08XwciuI7eekETCQ7ShtXjekBYuzaFvm+D45CV+ojvOxSWh0FujoKhr<br />
zwqxTjQAKwC4ju0n5oVgbEuEiwO6qNiig0M7PY8acQbeNiabBNRluGF07zx6HRSJ<br />
pve0+IsPjUrtfa+ylyPtxH3CjttuntONHz/+A0jneKM=<br />
&lt;/mintPublicInfo&gt;<br />
<br />
&lt;mintPublicInfo denomination=&quot;5&quot;&gt;<br />
eJwVkTluGEAIAFP7NVzLUbhgOR6SFFGkFG7y/6w7hLhm+P15Pr4+F44VFKqDXIF7<br />
pKyYtJTJDbI7NwD8rLrDgVmujA5XPJy2WnfvK2zrMLIIyCSdTFcFPupDfg+/WBjd<br />
lzGkfIIdGU/wdTwiXbxsbze8pQIh7UnObEFXGyfSizKIi/l40FA7YN1jzEl1bkK+<br />
0R2nvvu8Aaf4zGsl45C882IXLQizqTtSbaB8P77+/fz759dnYCbbTWrcTptccHtW<br />
hHc3B0FGdQQfH0OKGx8862a09Xj5ZcejuWRSr9+nKIXz3mSREw8BTMcTYVcD72KE<br />
apzjtfJ8jHY3jcnY7DoTty88RwlUaM9W3qeOl4jntk9+S8DkiJ5SwRKV8VFy6IFv<br />
ViFpReEg6vMe8l6CUZgPtZ9pvJOlKvIOO/zx4z8HN3ew<br />
&lt;/mintPublicInfo&gt;<br />
<br />
&lt;mintPublicInfo denomination=&quot;10&quot;&gt;<br />
eJwVkTtuGEAIRFP7NHwWFgoXfA/iFFGkFG5y/2yERAXMvOHXp3x8fxrphnvqsBnb<br />
BhN1IZHtjkNC9uqMvX7HZ9hpp+IcbQvsWYUJldfORV4WNLLZqNEbIAP6Nvf2PXz4<br />
Sii/IdeSuCXzJBEXXN74eile466aVJzDmbQtTBLb2E80XGP42FuUdDi25JFcjONG<br />
MKw6dPfREDv6YPUEkR6C9dFOE31oZ3GtTF/lx/ffrz+/f37iBmRpEWcLnmC2UoAS<br />
v3kFHJD1wSKpkV8DfVcHAcRishLu1aNEjCQFJD2eh7v1GkZTgEJYPelOkQZ/aZ21<br />
zmocuaduHjT1U0ms/lwb6jNbUDYRL67Fzq22rVuFo2wuGU+8OVJlC/QhefJxzOKT<br />
HFLSpF0wa2Av/8Xr9z/YeV99egCdeSmfO/z48Q/7rXjd<br />
&lt;/mintPublicInfo&gt;<br />
<br />
&lt;mintPublicInfo denomination=&quot;25&quot;&gt;<br />
eJwVkTuSEEAIRI33NMDwDTYYYDjIGlhWGWzi/cWUhoZ+/PqUj+/P4YfddAQKB0LE<br />
rA8j+hTnC28pISd6yVnnoW4ZwC+dVkOPq3Myhh43MKiQTKBX3sy1Nqdw364LM5BG<br />
5O9qm7El3Zl6LS6Ajq1xQlgv33HByBPM0A23QCL0hZkfzSpYjabLV9r7ehpjRLmS<br />
X15Z50BQ13x4z85DscV1OIPTBP2sytGQ/Padj++/X39+//w0u/4wH6Q80rtObBbD<br />
0pKb4UFEiRZ2hJU5A0DHPHF27YP6UPpAUvviM1fz6AGt2wC1cCjWKq2rzgypBakm<br />
w3lMiHIAix16YyRSXJuNX3uEnmjKk8ta4dmVJQpeUdNxeOOtuG9jSLxX1Alvk8oK<br />
I3c34P+PFcwDOEeOdqAED8iiEaw0OEijHh8//gFfh3gw<br />
&lt;/mintPublicInfo&gt;<br />
<br />
&lt;mintPublicInfo denomination=&quot;100&quot;&gt;<br />
eJwdkTmOEDAMRannNHEcb8UUXg8CBUKioOH+eFCkKPpOnuyXn5/08edTqei8eAYZ<br />
u7D1dLkDBReO9PGcG/iwuDzqgeIAOvSb27NnljdIDFENlK9f8pbRzsl3gs/z8oua<br />
gWH11D1fXXAD7hilcOQUhOulZ3MnMvRUrN17U+Jrj6mKiYDwSvnJ7MM1Vmo6pawI<br />
OFm5pGifx2B+z43cRtSa0s7YeXnlCy1TLqbB90l8/Pn7/fevH58PykAkRZGUXWd0<br />
I6yQNKape5ZnxGkCATGP2Hs7lUrDvvh6upoq6j61ffo1ertiH7IEUOKiNTrx5Esp<br />
H163dasQqgi6gtbL3oYRPC2iE7rasUry/0icvMYFmWV/p3WODHKTaC0lZMbuESXE<br />
PLpsXsrpCeOyBqv1ccH0Qmm/i74GodlgKOR8fPsHQoN5fw==<br />
&lt;/mintPublicInfo&gt;<br />
<br />
&lt;mintPublicInfo denomination=&quot;500&quot;&gt;<br />
eJwVkTmOGCAMRVPPacDGWzGF14MkRRQpxTS5fzxCAmTJ/Mfz70/6+PqMl3ZGxcEU<br />
uOeOJt0Uy6ehB+pdm0YGo3fxosaWnOBYO0VgGTu3kaXQVhCH5OT0dgKfXQihqvaG<br />
Bp/Iq/cOYdaINT3gy+190jFVieOWHZXEC2fSrxXVxDt4DvGYB0bkzNVO6dR6haGV<br />
EGd5KZoXqWEMibUX94gz0cTeA4lwo5uNAdhIpiQ+vv79/Pvn1+fCHkE/Hbghdgsq<br />
gsIPFzjUwZeLVSpdeZ3y+aM9xlKdTcno1G7iF1h9BY6IBEqZLXDGserCgstqMEG+<br />
XNi4ILwPmVfA829PcGcQRe9TH8UVm7Be6LVAie23aMVsct+5oPTtTd+DcGmpSdab<br />
UyCcPR472gDzc7YPvO294oy4B14Y7pgVIsEnP378Bwj3eOQ=<br />
&lt;/mintPublicInfo&gt;<br />
<br />
&lt;mintPublicInfo denomination=&quot;1000&quot;&gt;<br />
eJwVkTtuGEAIRFP7NMtvgcIF34MkRRQphZvcP+sOidEM8/j9KR9fn31Tw69sXCjr<br />
Qc2qRJaB5os3csvg0iWr67lRgOlJ55SqoBjuTZtOaC32veYDtXOAdxfZCYy3MrpX<br />
Ym5EO4JT5gHw4bt1pCcJjiWvHx864SXmm8zeW2NyG5Gr2iwEuutsPvMJ4KIIwrEE<br />
3SAZLeETbGDo4FKbB6uBXC91xX0pqdJ6S5/G6ePr38+/f3596ogrC74qyiCx0G8/<br />
FwEK3HQqagOt/NztI/5dbQOec68/bEvzTeSSGgmehtEHhhoFSHNeg5g9hOo3681J<br />
Xu/wp6Nu28O8gKin8UKE5TZLCZWkrSe+TzjHTD7CdeC0gCZgcJic5pfFl0MDOZu4<br />
x0LX5jQVSd3zmjliiUbaMwMlAODHJl04ieHjx3+APnju<br />
&lt;/mintPublicInfo&gt;<br />
<br />
&lt;mintPublicInfo denomination=&quot;2000&quot;&gt;<br />
eJwVkTtuGEAIRFP7NHyWX+GCZeEgSRFFSuEm9w9uaNAwj5nfn/Lx9emoV6XcGZwT<br />
fbClLjHhtckpCJ8XfSrwaFwA9Zs50oeroXTlDl0jRO8JeRCrHTAUTJmi1hBI47kr<br />
USHkKHOPOecMwBRCnyERJCTFvWpyW9ruxGFAYQYaP10gUpzRWFOlymIhnB73TvbT<br />
VRDmN/d6FQ8eeO4oei5einie1l34iO7dr8yIXO7H17+ff//8+rQYyVeP/JKb6ll8<br />
TNJawxf3ofpAUmImNQXWFRV0LWkF9/tUvHbuFnKcoBHD8pluIntY+/Sbq14sT8I2<br />
5o53ZA6f5EWE96xlkc3CKZRgv2IwYhh75rD+OnVS5AEhCPJMxVx2T3J/0ANSY9fc<br />
IH1i093gtg7Z0tw4z71NLzfV7Xp7+eZbZJ4G/vjxH41PeBU=<br />
&lt;/mintPublicInfo&gt;<br />
<br />
&lt;mintPublicInfo denomination=&quot;10000&quot;&gt;<br />
eJwN0SmyHUAIBdDotxqmhkZ8wbiQRKRSFfFN9p82OLhw+P11Pt9fd4Uiuk2OMbKG<br />
hgnvHOyIe8ZG9Dr1lM9YW/jEhbBcFRcYn2oUzBSOVy9odpoTNk0hwfAGAeFeXkIA<br />
RqvyJWJGQExXhXR6QbHMQkorUCJvFYlIzSRfpgzodfRpnL6QYnfKarzco5iMZxgE<br />
R6svkloYTC3iQeW9fratT4Q4VSbLXNoSYvt8//v598+vr2srKw7zzp7F6nMnHErv<br />
Y8g8Haunn4X5ixI1xHgdGsCTR9XrKlw8TsKAztivBfXYkDwkF8sXeQWe2tZGQdtu<br />
UeTaXXQlerTJaVfflmehzL3rTeirSXfWD5t5abicTkTt5ZY4FnHI4spLV7Yn8ryL<br />
IefVo5h7twGcrZ9jzlOw2ocn/eLoTXjP+Pz4D543ePg=<br />
&lt;/mintPublicInfo&gt;<br />
<br />
&lt;mintPublicInfo denomination=&quot;100000&quot;&gt;<br />
eJwNkTuuHUAIQ1Pf1QwM3+IVMMBCkiKKlOI12X9o4cjY5vcXf76/IqnfrTCOvu5i<br />
eLkvxOs4wyB9b542pqOS6YwnkPAhDPANa3EyCwXQ4of1KL09MNlKTyUHAEiagHW3<br />
apuQ8VGdkJCaxaVJV9QqmH0ySQT4Oc5TPO6VETxYtmjcwrx9bsGwU+0gH1RncaBW<br />
r3ex9IpY3N9hwjk14iPjpKmx0/QkfevO+LF+vv/9/Pvn1xcZXFNCR+7I65sdGxeF<br />
BkMclbppidWMfUvUZUXsMV8xJ4HeItrUzDbOsXh4r1zgGI98JyWyD1iZoZsoZuna<br />
Himu9XkCKAWDqcn7LpuxOS4RuAi/apgX0FQbRq8OTGyLZ4+CZ8I+CJlId3WKwgAM<br />
grrUVrzIkV6O44JQiQo4S2cQ00DaWHx+/AdnIXhp<br />
&lt;/mintPublicInfo&gt;<br />
<br />
&lt;/mint&gt;<br />
-----BEGIN CONTRACT SIGNATURE-----<br />
hLl+yVFoiI9JQlHwhRFMP95kCJ3clvRkIu4vRjOjWNil1LyncwFSysGvMayBjAHJ<br />
0X/BV03xjrtKGk1clB2C551uy0SXUL65C6IIjDKv+eREMZ31jNCDHhWCLUSb3OgZ<br />
4CcLgj+da5M8VrdtFjKSyOMqH47wl9awRiLqNKjX7n4=<br />
-----END CONTRACT SIGNATURE-----<br />
</pre><br />
The above is a '''Public Mint File''' which the wallet will download every time a new series is released. The wallet uses the public keys to generate prototokens (for cash withdrawals). The '''Private Mint File''' is stored on the server side, and it also contains the private minting keys. These are used to sign the tokens (while they are blinded), as well as to verify them later when they are spent by the recipient (after being unblinded by the wallet.)</div>Cryptomanhttp://opentransactions.org/wiki/index.php?title=Sample_Cash&diff=75Sample Cash2013-06-11T16:10:27Z<p>Cryptoman: Created page with "Nick Szabo wrote: ''Meet the greatest simple equation since e=mc2:'' '''gSf(m) = S(m)''' ''S is a digital signature. f is the blinding function, and g an unblinding functio..."</p>
<hr />
<div>Nick Szabo wrote:<br />
<br />
''Meet the greatest simple equation since e=mc2:''<br />
<br />
'''gSf(m) = S(m)'''<br />
<br />
''S is a digital signature. f is the blinding function, and g an unblinding function. The blinding functions are usually based on a secret random number called the &quot;blinding factor&quot;. m is another random number, a unique identifier which can, for example, refer to an instance of some object.''<br />
<br />
<br />
-----<br />
<br />
Here's a sample piece of OT cash:<br />
<br />
<pre><br />
-----BEGIN SIGNED CASH-----<br />
Hash: SAMY<br />
<br />
&lt;?xml version=&quot;1.0&quot;?&gt;<br />
<br />
&lt;token<br />
version=&quot;1.0&quot;<br />
state=&quot;spendableToken&quot;<br />
denomination=&quot;25&quot;<br />
assetTypeID=&quot;XUHBvdsWAEmErZMzHaRKaNPaAVsUvKwL4uLY4nOY2s4&quot;<br />
serverID=&quot;44FmyPAgrmGu671RywGnhrt8aR6tzmNFn9WKQ92BXn&quot;<br />
series=&quot;0&quot;<br />
validFrom=&quot;1281865563&quot;<br />
validTo=&quot;1297417563&quot; &gt;<br />
<br />
&lt;tokenID&gt;<br />
AAAAgGZdHsse3IXV4VTvm78X5uFwrmSuc116m3dSS2ueXbAKQnSeADKyUoBa8Dem<br />
isNgXcjfbfVKsrVAPR3kNd9xCFY4uR7nMBSOHKrCaUSpUVVgB8IOYtgOmPQTXiuE<br />
wtJrxofv947QBuP8RnVvf0ZVt0xLL6zlbpk3UW4iDIr0HXmuQQ49q/vJdWJjSHRF<br />
Q/nt0BN5mxFiSbXyKr7no+QC0u7Sr78jYI3Itn67J3uaMmxBmA4JrIrHse36ABuW<br />
zxecCkTNki9Om5bl6c1QgM/N1gogWX3n4o7Zz+7Dw7zt1e/7nG6AYlOT3kfpXNnT<br />
8xojuyaiSINDQOoJboc0tq2CnX+ma6CNC7bQKtN69SZJs14DseqKquWe7gwCHPTo<br />
ewSsKeRmTjzxDhjnFNLRRJGhC4bvH/tZD0UE8EY0X83mvQiNJ/5on2SxTxanJXNt<br />
iCj3+Uczaa0CQ1fQ6ubrwbpeWgZRzB3CUtHTsLVhPSBkEnRbndyFEehfb6rKyEqs<br />
kfEaa1LdiBj/MctrP6EBbGcrmixnr820KLXmFNjDhhybeFNK/cTRuYw7cWra4/S9<br />
F4QViwCmlLToMwOCYmwMpm//HFn4eQSLsMcP+gVAXme9YmVTlEKupQGV+EbJ/gnO<br />
prlZxQ==<br />
&lt;/tokenID&gt;<br />
<br />
&lt;/token&gt;<br />
-----BEGIN CASH SIGNATURE-----<br />
GAry6ydopTPrPMs1V+9EPvszmZQsRkOtqm+5QeUywyEyOUoFuJJfHhPxMWPbupf/<br />
cq+vBf0JwK5yy/XA2Pzom80TPTry4JpxXckx/JcmyUikhocTY01sDZNcXzEfBvQJ<br />
kIeADfmw/4/adTjHhVCy4k+OdGFvdIwfNIdbVfsfKfg=<br />
-----END CASH SIGNATURE-----<br />
</pre><br />
People have asked why the denomination &quot;25&quot; is human-readable in the note. They assume it is only supplemental and the actual amount is somehow stored in the Lucre blinded data.<br />
<br />
BUT IN FACT, the Lucre blinded data contains ''only'' a Token ID. The denomination (&quot;25&quot; in this case) is necessary so the server knows ''which'' minting key to use when verifying the note (it ''definitely'' won't verify if the wrong key is used.) Similarly, the wallet needs to know the denomination for unblinding the note, during the withdrawal process. So that number is there as part of the protocol, and the note will not verify if the wrong denomination is substituted.<br />
<br />
Decrypting the tokenID (from Lucre and stored on the Note):<br />
<br />
<pre><br />
id=A4C05DF4C43B77EBF02309502E5FB3F30C5811886254DD8B9B0C2791<br />
signature=9F29D79A07D48D467874DE7F76B5EF02646835A47DD576221612DA1A9C4A531C<br />
10DFF2BECB5EC72D13F2C1DE3EB885636085F09CF33F80125BB2EA3CEA01EA6B112125E29E<br />
796FD889CBA467B1F5B9BF4FA2FFEA8AB4C111D84F4E7236B70A42CE3137FB23DEBE79FF37<br />
B6C161A3F77009EF714E8D0CE528B5572DA58155D59C<br />
</pre><br />
<br />
<br />
-----<br />
<br />
All cash tokens have the exact same expiration dates as the [[Sample Mint|mints]] that created them. Tokens are sent back and forth between the client and server by bundling them into a [[Sample Purse|purse]] and adding them to a withdrawal or deposit transaction.<br />
<br />
For example, a certain currency may be in its third series, (SERIES 3), with ''all'' tokens valid from January 1st through June 31st, and the mint itself expiring on March 1st.<br />
<br />
On March 1st, SERIES 4 would come into operation, with all tokens valid from March 1st through September 30th. (At this point, the Series 3 tokens are still valid as well -- the server would accept both.)<br />
<br />
In June or July, SERIES 5 would come into operation, valid until December 31st, etc. Around this same time, the Series 3 tokens would finally expire.<br />
<br />
Because all tokens for a specific series have the exact same expiration date, the date cannot be used to track the cash -- thus, it remains UNTRACEABLE. Your wallet software can also compare the tokens to the Mint public file (for the correct series) and verify that they all have the exact same expiration date.<br />
<br />
Once a specific series has expired, the spent token database for that series can be DISCARDED and does not have to be stored any longer by the server operator.<br />
<br />
This is fully-functional now, and makes it much more practical to operate a server.<br />Wallet software can automatically do the job of exchanging tokens if they are close to their expiration dates.<br />
<br />
Opportunity for wallet designers: If your wallet is unregistered, you exchange all expiring tokens and keep them for yourself. But if user pays registration fee, then you automatically exchange them for the user. Nifty?<br />
<br />
NOTE: the tokenSignature Lucre data no longer appears in the spendable cash notes. It's used to unblind the token after the Mint signs and returns it (during the withdrawal process) and then the signature is '''discarded''' because it's no longer needed and because it could be used to trace the token. You may notice the Open Transactions cash notes are a little smaller now, because of this fix.<br />
<br />
I kept the below signature decode for historical reasons, since this field still occurs in signed tokens, though it is removed by the time they are unblinded and become fully spendable.<br />
<br />
Decoding the tokenSignature, from Lucre and stored on the signed, (and still blinded), note:<br />
<br />
<pre><br />
request=2331FBA771EB4DF7DFCD3D4DFD9F3DA5F43A90C7A00EC599C557E8C82D9679BB0F<br />
2AEF36ECBCA3C551B5C7E134C151AC93779415E695C5CDDD753DE245DF31904EEFC1D3E3D4<br />
64E5DB27E80AE65355004DC869CF47BBDCD2B79EF2F23A0412826EE9794E9B8BA07E03C417<br />
A59EC2CB74195FB2714E1CBAE49EF89D5A672CA6BA<br />
signature=8B29439A2CA05CE28C416A8C5395123468A8E8505C1B2FC1568910B27759B652<br />
971240C975D1422C9ADC35368A6A6B439F1D4614C52713A82C9B662E9099121324DD4BEA5B<br />
76AD123F9912AB43A47AC590FC1DCED905C10B72B418107FD709D57D8DEC779896F48989C7<br />
2171D01BCB15673CCF36B2FFCC29B9D986FCFE97E689<br />
</pre><br />
<br />
<br />
[[Sample Mint|To read about the OTMint object, click here]]. <br><br />
[[Sample Purse|To read about the OTPurse object, click here]].</div>Cryptomanhttp://opentransactions.org/wiki/index.php?title=Transactions&diff=74Transactions2013-06-10T22:41:14Z<p>Cryptoman: </p>
<hr />
<div>Let’s say I want to withdraw some cash. In that case, my OTMessage will have an ''OTLedger'' attached to it. <br />
<br />
Here’s what the message looks like:<br />
<br />
<pre><br />
-----BEGIN SIGNED MESSAGE-----<br />
Hash: SAMY<br />
<br />
<?xml version="1.0"?><br />
<br />
<OTmessage<br />
version="1.0"><br />
<br />
<notarizeTransactions<br />
nymID="Bg2QrSTomOEU5ICfvhfYfBYxQZPktDSnaVPpMLYxUnz"<br />
serverID="44FmyPAgrmGu671RywGnhrt8aR6tzmNFn9WKQ92BXn"<br />
accountID="PhmhKernutijMa2XXxH1dZnTluIDQUVn1tifSOq9H4x"<br />
requestNum="274" ><br />
<br />
<accountLedger><br />
eJx1eMcOhEqS7az5iqu7Rd1415rbUuG9p6DY4V3hC/v1Q08/ad4sBgmJTIjkhMnI<br />
E/G3vz0XK0iK+YenSKbA/6ELvCS4/5r+GyAna/2PP7yX8QGA/0yybNyGn17kVbH8<br />
sRfL2ozDX38if4f/BP74XVPx1599sa5JVTzj//exwv/1J0VQJc4QaFZkGEEXdJmg<br />
NFrkZF4iSYGSCEaUGVngDFkgDEEWBZUiCJOSyTNgcDghGTKnk4zCUiQnCzpPspIi<br />
4RzJ0IKhGATDEQKDEwIm0wRJH1ESJhP6uRkSQbKUydMHzbYWy39DecTKkiQSqizS<br />
JEsSOE2TlMLKnCRgDC1IEoWL5xEpceSRT9G0wJKcIB4EDJLjJZElKYE+utFUBlN5<br />
wiBlmmcPyjyhSQLFmSwlCzjFErIsqJwkSzLFSrpIGZxgkJTI/wQeIPu/seBZhuc5<br />
AT8iCZUzGZXDzwpwATN5Uj4/LrMcoRkMe7RmEpgqqTxHkCKnH3tQeYGgGVOWOV5g<br />
GZpTcA7nVAKjD8oCpeESfWxb5iVMEPhjcpLGn6m0pFKMynGUYZLH+MWff/zzcepv<br />
SYY1yX6PK/8JFOrJhEZmLUJzleEG4tu0wS5KJzTym0uup0XW+WUmpek3Ac7SIDLW<br />
UuNeoLK9q8L0CBjrtUdQyXOT2kDy6325PC4T1G2Yh0xcfU/nBRThr+wugtJmLhmq<br />
kld5MT5iMO76dXkAQg1iZ4Z9wDbka3UB9ZYpAapcNesPZtw5CCJU4e1ZxuEl8esr<br />
wWyfu1djxk0fE10TAKPncUL05eK25uOq5jvxK51Oy52SC5f3C5dVwehz1XV64ewm<br />
JR6CWPUn8Wgadzy/LwOoNkGpMsF9xeZZGx6mvXpfiFCIV7rKy66O/iD9kNrTjrDb<br />
6h9D82m19a61sWos/Gp6YOWPL+fWvPEgxYujUNrewmzllPr882V1of2wbNAeQ9dU<br />
PWz/VlONXm92PD2WHK4PfAFt2HiOLPRN1hntIik3b8yP/lmrS9ndK5J6Vp36U9Jr<br />
RDrwXI2hcfG+1g/dNV0tNh1Ai66l4q2Pl9g01n7tYHR7wzpAs7bZt0B+tY/aaRHs<br />
O3MQV01sDHOO18179FZhGkTFBVoTPwzCkzLI6U2YuXuOP3rM8s4NnCwtb1phOr+S<br />
1PQQtrK78Sg3LQy0Dn7BY6kZUEAYE2YYMx2285QK3fdJgNiRrF8SwgVjf48R5mHt<br />
wNfBD198SHmp5XAU/VCGWtuaFyQCQS/ANbmMA72C2XiQLpj5rYHKwen7ycjPd7Eh<br />
8RsWkDmVMwK755vh1dMqfZP8UseZACqJGRCzvB6vJGaO1N0gzGi2iJ7jj27cvj5y<br />
4AanAtemb8MJ1HmGKPWFyAdHxXjkpwK8MKfyNqpS+Yrg+DAiX9s8NcZwFQf7s/Eq<br />
TnFQS6ETq+12UcFtjWC1xfSxMBu2Gd2AedYl9atjx94PcH3t19crBoEJ+oEBub0u<br />
Use8qawlUZ8Zz2i3IuR3iBo2IKnsyboBA0zypj194DnIR0QrWZC39yVNdw9PZupW<br />
h5uJcftY8zTLiLPMIib1Iwd/UJHoPJ1+wwvwqwwMql/aFUrl/ctvN5G2Zm1jt1Dg<br />
iv5MhJ91M/xivhKO2AsqIPupa8Q8J32DIS8dA5iinheiWs7aCdyRLxPMnKQk0OHC<br />
cIJNvsUlGsN5xTJlFof4KkA76d4MSBInu27SggJROpvDxNHSN1I8mtz9MmXPDxHZ<br />
zs45xi6Vj3Ua/6erjpLkbQ7XyVG83vs59VESweMFvA5Xmhclz/RdUHFjZXU3VEOz<br />
Ykzk2+I/CCWpGcXSboMDzRJq9Yuv16U/IYHi3UzgASDXhlJ/2SYMrUQfwpV60eBn<br />
YpBrO5zhNddGIBLpF7axo4ulkeWk2KEkbqW3uuk8Bs+BrvFOqjosb9bZhIUhvxw/<br />
bnTAXKh7Wwe+Y4p4MWc/UyB763X2Uj+2yi3oWFphlvnLBIgCy3O/Of3k8SdX91sj<br />
AluA1beGXq4P0fFsKq/tQ5yb9C6ggA9f7GeHE4xmt+kqWQMCCDUMjbwtilc5D2J4<br />
OJnp61lm09rN4tD2K+IsIfz+jDM7vZ50oZ7YGDCjrfXoAUPvNyDbR6+ebtblBQ/f<br />
jlTinM9rE37SUlN6+BpfYJZel/vpfm+QFfA3wTCKRF2K/c6a9AUCdYOyTX3WOOTk<br />
jEjaoNNQ/DftB9ZupeUYm5fr2k+mKyVKtmsqtGShXJ9g1vw2HnusBE7Csbsskklh<br />
Lcm+VTr0+liv078sqctFc18CJRXAJNbvBcd17ddyPF4nmUlLt7h5QQfE3YruohCn<br />
P9G+39pNfTRmpj2yWre0tcUBGmqJyqJLfH9gz1xP1vbWV9eOPseVnwFMgWFzl/WX<br />
GawQhcTYVDUo3nJb/CbnPDknuX7Y7Thc/ZxYBWXT8hDz/f6G1VXEO45iPQ3IrmPS<br />
jnA7PY0mFLhkaMyj7TTXZwwl13yb9PDNufLw4TaM70azbAm9TVdnPVdEMrkMeEKn<br />
9fGPNQwMHCwnuI9ORrCq/3WabFCcxLwNLxb1pvrG2WJTQ6jHUl1RDg4ZV9QEFZCL<br />
onP8xFc3LXvi2h+rmbuIq4TtEwc0KsdgFjBfffmFNJoR40tivDvjGKhT+8jN82oA<br />
qldjGR1SYmImZ7miimHpOzzKR2nIOglC22H69t32EwsqFZHDXaGRHgzzG/IQYjON<br />
BaidkINz6KUPDWwXyLiwcq+BO8YVvcW7qaoTo83VI2lYT7YkIwqNF30/U9ln4gbU<br />
9RPwPUUtBMo+5psS5aKsNHSwA4lF9fU5c1zpHoc9m+6rFupImWjo0qhm0Qqe44Zw<br />
Ky4HEH0yFQqugYsYXgdK1mSIJGc7lN/+L/cm1vV8zzQ+Pd6n8l5eLKd8iRAh81iE<br />
uW2VKmDsiwMy59c2QQMuhUTGgSSSBxeCmeVymt/LcjqSzEXDUyKYOMP3j5t29zkJ<br />
Bfbb3LwMfME4oxDHEBXurHyv6nEkh+Od7lw0DZks1Hrcl7SWIQJtxyUHZmVtZ3Hl<br />
03wuFJ+tEehDi+bNwgvOu2pR9pRs541bacTD0ojXDIox6S/jDiv63A8iHu6qzj1v<br />
7hR8SAJFjgfAraRuZ2LWtz+9NO7SHhflhmEfqIXuMhJzdY9vhoMpfoVS0YhIcxJf<br />
k/5dIXxTb3sHaCFLZNuthcRpEt92BuK3Zu1ViKbKetxIarzhBouv3ENeTXF/32So<br />
UX3Gqecx5YsAAugKGzN1NUfAwBf34QvLJuFUOrwZ+sYUejhfzSGhEGwsEX9IF7aH<br />
l/HjP7UrBeq0v30gUEdGpXPWsOyNMlvWxuUW+SnTXVYE6zVEF5UVo6LR3emuwmhI<br />
E2eCcFyenuXBZ90NwDm23BV/UrBi33cXheTLUshYRdlN1o/fy7qyrVUZPbFogtMI<br />
iE3P0hyWnq8oqaaHVQOWpmWTiVdXbqPZKO42DucNnkhF5/wJ0YVL9joOQyjvNuKQ<br />
uCt0pbv090tTibAfMucEipFRzNHaVUgnZCHn6p0Q6JG/MGndtFSqnqCcKLmvkcxt<br />
LwZOKLgI8BHExZ5506jlAp5KJ63tPy44TD8Adxw27L5OXoRVWrchODsTLaRG69Sb<br />
j6kqCRNtztTYBcmXaQyIWgKFC36rmLi/3KI0il+u/O4IvgId1moQPWHdcfGeLWpZ<br />
PrMfDYY+fzUrcfK8G58YfUcUsCLl5a1unMb+x7qQT5b7+zDLbPnkTvnN/xy8i3jz<br />
u7M74Q1hBXqdHp0ZT1jz2QrG1wBCsBxGTW39b0J8jxbmzsFrxTtGfLfiKDfpQ2qb<br />
12S1jbqUHwqAeg4zIJde191iDGsJ4N4SnWds1tYEdXvgqLWtQpJzOpkeFjX3IR/a<br />
P/cc5h4CtRZqwogIfLDnjVflyhGoDdCLOX96VN3o/iQM4Z2Jv93ysLCfjq+nwpwr<br />
Zsmo2WSR6Duj7Mu8NthFv5kjIEWltjagJkuLD6YRpNNBzl4HaIeMAva3X6w1IXzp<br />
qvadH3jGF5vWjSALO2Rdk3Y/4bS0iK4qwOis9+OTn4RC6/e1u9fW3QXKlbJtFT2I<br />
X0jjR4/3ZkYsrG+TMNN7ZllmnmW42jqblYHwBz018PUdNAddJkc6NaEqP8amnki+<br />
mfXXNGJErYYD+vROuB4kMRqb8KaWOyk7TPv+iyOB4rSuO8J94aXHphzJrwEtCEf5<br />
Ldq3Ue5I8y4oItkq3kWQx6/XL0ZnW32q7mhI4QIYbqPe/VUXPF2/uq3U9aU9OPBk<br />
gkTPXmXLVJixTC/S8bpXlQiqQOu/r1Tyxxlw1EN9H4pztAkp6O/kIHVs00Pe9rBZ<br />
MhiwuvOvUno/wp/Ac3go/MPkQlRysQ/58yVpDnD/KaSBuXv94Nhttm4Db5EVzwt8<br />
ai0pqWQTpNmrnVjzthNqJk/MUhJ+ezse9lT9X4kD5ZP8zoDA4ZNnPZQC3yQf1CS1<br />
BVEuVkvScxG4/Bn2noxBgoVv6k7IIlA1vRUsQhaTXCmon0sB/EufZm1sPbPqff55<br />
VxDCR+7TdacDi6n9fiRkxmhoTSab31ndBc0xUaG7Wg8ZNDMWAEvuXzFCO+xxFwht<br />
SGQU+6v/CfbP6Kfyoj7EjG3yacNr3FjfwjMhK3m97y5rGyKl8BuIrm5Rz6g3/eUT<br />
iJM1vXlVmYfuC94IbwiRdoexaTJY1WdM4fNDjhVO8AwQ9iUTCBwB1dJ5n45w3w3X<br />
JWkJHZC4DI8aCEpN44LFMspmdALBgk8rdvUr+6rZq2pFKvshArZCAGd5T4iUM7TO<br />
uvHAem69S4oaiHd6vKICRgSHGZU60dQzvbyyrnbE0uWOM6pKvcJgBYEiKF766Mjc<br />
3dV4i7UuTEr1FVt6FJ+w8jXnh0FzKLrYCpKdRxB/WMNtsdqgdsVeFdAGouK4jiKl<br />
kQKkhd9FCMlPvW6yD1BjF+tnp8uTNptY5Uu9oJG6fPz0a9nmDZVyUhxZHCinLy64<br />
gyTf0kRk1vkFp3CY3iGBLYR2J2IvE/0wBOCqF1IzB/fO+UhAyVtI2lu5OBwQXkhc<br />
9+9ZT6hfosyCpG22XIQLhcV3LbmWbTDJr4Oe/X6KmQES9oI0rr5akWeBKLKBANvN<br />
H+nqNen9Pqr5w9SCtsvXpRDLPkimj1IM9NpJCdIYl6IV8GI6qEIgOpEgaEzsCwOu<br />
Uj5KocQ3qjyvOSWinZJ5yEoZH3wIUf8paR46euklUeNGEhlUTr5O7zBfjU8A5yUO<br />
RFhOcJ9vjB4UpafqN/VjtrwGnAloERZxRHReAs+YoN68uo90RnqyeY0JUrUqMJzc<br />
OwAJV63sipXgDOQd5apu9ofg4PwGmZUOw9FntJNKYSnQmonfU+UX+eXSZdDQVJgw<br />
/ekBpehrPtwEjW4zROtmgQFmHl3w7jgz6BEcZ5PgR4u8+vG3eb6BPhttCkdzzzdf<br />
LmUyBZB5gTW6iN+4NG9BW3uODUHTih4FD9mM9oKg1eY/+kPo/voL+E/ofzWxnvH/<br />
6lT+E/jb//Q4/93c/O9W58sPXOHfbc73v3uZ//jDmorhD/9/Vlv/gP+OwwA39n0x<br />
/P7xR/37Tf+AoKr51Vv692zsIbH4fsfjEdmLb7FA/1rgb///AtDRdA0A2DKEVUJd<br />
n5QGe9e8ChIFGu6ps5FkZqwoYlPbjN+ii72Ayl7hu1C8ecIWvsw/SchyGPBqjTZk<br />
znBj/c34vLy1tZ1J1fuQ+YZrHMKrv60aWlheRNavFzkl0/RjZslE99llRnABpDuH<br />
DjZ1zfbhLRETTLPsxHn1fV9qSGikS4S8SUTWamrZX/+2mGDy/4e9gP/4L4nKO0Q=<br />
</accountLedger><br />
<br />
</notarizeTransactions><br />
<br />
</OTmessage><br />
-----BEGIN MESSAGE SIGNATURE-----<br />
Version: Open Transactions 0.40<br />
Comment: http://github.com/FellowTraveler/Open-Transactions/wiki<br />
<br />
yTr21U8Xldvs+nhDgLQsetWJEtbZQZ+wwaMTzCWQNiVO+vMVbqq0M0rL5M1i//Im<br />
j35PTAFgHA+StTx5gTPgyWsyPPwveIG5zD6sOUli2nLwZ0w6kR1CJsCmVLqhN3Vi<br />
tsEq708GsIY8A1YGSppnVTN6FJJWd6bapmtpHebfzWA=<br />
-----END MESSAGE SIGNATURE-----<br />
</pre><br />
<br />
You might notice that the ledger (in the message above) looks like a bunch of gibberish. That’s because it is base64-encoded, which makes it very convenient to attach it to the message as though it were just another “blob of data”. <br />
<br />
But if you run it through a base64-decoder, then you can view the ledger:<br />
<br />
<pre><br />
-----BEGIN SIGNED LEDGER-----<br />
Hash: SAMY<br />
<br />
<accountLedger version="1.0"<br />
type="message"<br />
accountID="PhmhKernutijMa2XXxH1dZnTluIDQUVn1tifSOq9H4x"<br />
userID="Bg2QrSTomOEU5ICfvhfYfBYxQZPktDSnaVPpMLYxUnz"<br />
serverID="44FmyPAgrmGu671RywGnhrt8aR6tzmNFn9WKQ92BXn" ><br />
<br />
<transaction><br />
eJx9WMcOrEiyfWu+4upu0R28a81tqfCm8FBQtcN7KLz5+qGnF9Orh4SUJBmRJ08o<br />
MsyvX/fDCpJi/HAVyRD4H57zMNwH5ymm8de/X4AczeUfP9yH/gaAfy9T1M9RslRD<br />
/2M5v9nvn3u1lOkU7VH7E/gRJcmw9ovC//5JEVSOMwSaZAlG0BmdRyiNZimZ5kiU<br />
oSSCEXlCZjhDZghDkFlGxQjCxGR0fzA4HJEMmdJRQmExkpIZnUZJTpFwiiRoxlAM<br />
guEIgcERAZNxhMS3KAmTEX2/DIkgScyk8Y1mnbPpv1BusTwniYjKszhKogiO4yim<br />
sDwlCRhDM5JE4eweIjmO3PIxGmdYlBLEjYBBUjwnkigm0PtsNJXAVBoxSB6nyY0y<br />
jWiSQHEmickMjrGIzDMqJcmcjLGczmIGJxgkJtIbyo1k+xsMniR4mhLwLRNRKZNQ<br />
KXyrgDOYSaP83jlPUoRmMOw+NhPBVE6lKYJkKX0TQqUZgiZMnqd4hiVoSsEpnFIR<br />
jN4wM5SGc/QmN09zmCDwm3OSxu+pOKdijEpxlGGim/3sBvMPIxpr9/snTeD3bNU7<br />
WZ5NWZ9k3vD7J/zzx5+3wasl6/4EMvVoX3S3jnDhUt4rT/IAJfnwemnfWKjjNy/F<br />
UmE0h6ron8s+cow6R+cTjM2HUxTTaoDqzeu1ZV0E1qbHc53zqz9DJxOfTN6l7wxa<br />
J63M/9rAgiOaNd1hknEq2crFSQToRZjAYHURUxI0hNTP0a/kSMFGmeFDUwg9S6Yg<br />
SWd7djXgbHyX0ZwMXTKuSJZ34J4+mxiSgCIQ2OI8aOjkvFI4PK5BKrNT3Wcnuq2u<br />
qqLGJlL3wvmn0hyvylSenE9Umn9+CvhebQNz7cj62T9oxXvOX1twFK3n1bHSHLM0<br />
9aV8SLnDC/T1FOar1VSl6NRvWx9pksQCq5ouYOqpqH1QrqF3GmoC0Y2F5kSL8V0r<br />
tgM3/hAKyWGfztdzRaGuisjZReI0g8Yp5Tckq0A9lG41Pr2E1vxLK5qqami31AL3<br />
9ehqr5grxhQURoDfa3NpGaUL0eMQUuHzFrXoWqs3cIqFnZye+PakV9+65xBsuGr2<br />
XbqNnpC8GlXIS86vTfbBxY5XPQvCQMvGf3wviTtLJQIadjd0haweAVvxpmXaX0oy<br />
AwRGqrIdcLvEJ4MsBLRWJWNg9N1lj4t/267q23bku0UKOEhJl4syyLHc524kq54U<br />
HhMIhlBiWWOaLnWs7A8+Yp91yuwQnAqhMUF5bl0P3wkZGoBCGZQ7GCs8uhikS94d<br />
kiSx7gwOSqLBaB0/TfoYRXw0CWLSuk+VZ75A9xmq7+BzLhcAJYPJCr2ofOWccTrp<br />
FEBDCtqbYdZYdJvzK5UPE0JVK2yRT/8ZqNIAuY5xuGVe/UDWABYv0a38BupyfBM/<br />
5JWWMdjeeAfqnFWwQcNTLccP8KzB4/uteZca5TmxZcPbyGIzJx3oU9oPKm2w0/VV<br />
HPwmJxRckdeD0zQGf4CTDKp4x8GifS4sZy+cbyyRYktV+BE4V599IG7yIPVcibA+<br />
hi2Bihxh4/Qd9F6P+Qi7DlbmnBPjGrwoiARRPweIfG7HPh7WOHEfswFKKTjZom3f<br />
x5QPkcXH6Esf6mjIk2yYOAxTyOGkdFNvrUIbE+aZLzr44LKtjCD4hacN8GzFuSUk<br />
Zks2vFEZbtFPzVKz7YK9q8S6gsubjPFn/nhG7cXyFVY0SNsxBPSsAkjoTCCfYn+b<br />
nuRrstcMBEXW5oigh+FzHjetpQxxCQayt3zQQChVyRe7P8HnZDmvV0JsF4kC7BSK<br />
cywpKwWuxSK85I0f983S8PbdLq326sdupLWVCRHnYCu3DkoNfj5LjbsQsxs1GNCc<br />
0/TjT4YOnn90Urx+voQc5BJTlQicnIQaNzMSZFLiglZcrP7nWLZGhg7Q4/MyXiUg<br />
dFFQwtFAkprvaRPYOiqkXCgEuYZU82HZ+cU9lLrtW82c5oAG9SzcC9/kJmXRddgn<br />
gAiOMk1f3FcHcdIJFWfTQD2DXbWBQa18PWbVTRjYZEJ7X6nzg2XLUnqV/S15uNMr<br />
hQWC0d/ALni0Pe1orBHmK+v3CemODRbJL5oPCho6MOXTK6X72ZrLvxbHT9Zi+LLx<br />
TSIJeE7Pwqz7FHefgK2nPUGB2LsjN4RGzonvcpzyhEhXIp8/yK7irKeDCCnWueyQ<br />
FT6bEeCi0eZ0sn7HKH/66qPWHVTtdSpBRSTSNMYm4mbHvfyBCIl5W16dZF0CusGg<br />
omew/NqAup/n4GW5cC+61dUy13NfrxNlyOQk66dFMSIX05xWVtCpvRGc/EBlizDH<br />
l+Zc71QMFICxgTSgm41d0Zv8kR2bW9cWKm4TGKj95UKv4GQ0BHKvB4IYiYy24qOo<br />
mWO8DNeSUxzgj2BxGPQV4ObXD0Go4h9239btcCwOXYzfrxD0kgkRxzCxET/G+FCD<br />
+uf7zQp9sVTpAKCyKnqVdMMPw2O2vH1ZChm4uMQ3ITg27Xo1GqaZypLls/4uJzPv<br />
8EcaHPRhEaQiaTPQn5tscjyeFNJBSCo6KDMRUrTIzndgpZmzz6WK7mcCJxwpdrE+<br />
2s0Mq7yiwU90yCYDeOP60bGwSq/lZ72wQlKQ6/W+iOF4fzA3vWyMtDYhRGUJpvVT<br />
UJo9J8dBMOPu7NjBP4Hj1tIpzfg5BSi5kXfg9J2XzkLRI9K1iZcEEwySLcdUYsvM<br />
QwudRFtGUs3lVkXW6AOI6ZJ2BuHLwtAOycujJ9LaO85CK5/BbxfNnrmDg7Gh8nsK<br />
rijBapDJsCu8BXZkuC4DMD5bFQxtEXy4GPsonnWHvP1Q64REkfRrmzAKJ5WmncQx<br />
eo9INoOvJ/L5HEdChv5E8oDy3GsuKbGgqPWp7Hmh1cRjy90a70eU4o+4Fm9V82OR<br />
SJ8ajPTQiawNTU+v40MPmhaA5OfOzMEQv9Xr6K8L7VDZ7gaWaKqcJZR+6ANMn1Jf<br />
eR+lgZ5zlCrIiITfsDvQETI/wOsM5m5OzZeVqO7rrYqTXnMLqlKOaQddkoKm4VX7<br />
s1fySsRZbZTYOy1YcdTvnqHBfSsAHVDtQ4kXDNlvBv5SnWg+SkLXxcD5OqxjEMlM<br />
W+fnoKJjTla5lwj0CxnSjFzZ1TRgC7RamW7uqsasPMhfHlXI2SQ9n1yLhhkrMnsf<br />
4SrXxxZNhOp/kvUQJhPJ/GQxQcLWehCY6cmwqmC3RwE7seJa9F10wBxz4gfsC52P<br />
8rNqYm2Ju8mx5MEVcFtvOS3WmpwlSJ0CRFcaoKP6eaLv9Ivrqsi3y8V9wU6FIhOu<br />
h6fODUpo+8bnHcAw+PW9I+mzTesh5El8ghTQt+xZyBbhiEHEv/OypKzxfNrj1LJI<br />
oQsz+6AtG2/slAvRyukze2CfHPOem+4y1iTXgaWq9FeOlia9pVqBB9qqH0gukPBH<br />
Wt/613ylnKQ2rpQGxKEgfYMuJx1duNhlNMZ1Jgnw/YmQWsw65oMuEV7rzafk3Kly<br />
Aw+Fpssv1Cl0rm3pd1dyn2e5QItrKliIzXKSy/X6BgZvF+D4yAtZ2qPJfc6Xnb0e<br />
nzMhvTsLESLLykufLLrjwC+x9UaLcAfj9g3MrpA6QSkAgaEJE8LtlGfDwxUC7FI4<br />
FEwja6ELVaw6L3uLWDPS3qGM9+gzdlIfSt5Tp+xnTjMdcLW2GR3Y6tTGGqU4Tc07<br />
qkAt0ZRiuku+zFBFxy+ScyGagHN+8ByjpBNzPa7q6x3OIaDuVQS3530lGC+Hx6lq<br />
EC4pSOOAx4uGT+KGJj+2CZJf6SR10ftMPvaoUa3WV7za6eUJKLjEO5HFadIe7tR7<br />
DALpqKojSNgmTDEO5e5EYHmbsv8UO9hTmo5H9Mi8KH6itxgze8C9XeLRKm/M89oe<br />
B6vlFX2k3MZ1+/u1XMevAmtEPtMmpfy7Y5q3uHxP0sZiOleSN/OaAVzkcji5b74z<br />
XykrJxXmNTrYUFpOpVDJIqnkl+z1DMEXKzWZNN93gmc9eTDnd3eQUgmc1BAH510X<br />
grkSYk5RViCkabf/w/Frne5E127por3ZH2Bc8a/0ET8IPgtfmgivggs1gPFWfPI5<br />
xfzp1Gd98LBRZnBSRhvGIJUFzbwAXe01EQ9oIhaKJxbySfhgv1OLHkCMggJyWUs+<br />
eUeALoQHCzkh4j3jR06GhyZOLXZx0IlNqBaBC22rPI1cxwUZYBMRj3hM7vIPsI+P<br />
Xewyweb81e+8Ety5EatJyz6mU2MvFhqYmHpKqN3gTGmEK6LHwtLyruqu2Gd6FoB4<br />
fpl4ERnGHzGp5cOxl+pWnpVW53r5KzaFmH5mnnU+sLeGiqUzvCT1U7HuW6PufrQC<br />
Wy1ZhmVqLa7taIqEGKuPHeWr73ZzhGROPM9atk/AtGxFcM+5Pr1iRLsOXSO+21u+<br />
BkqYGymKGVVwgqY9hEKvHyyI5rvnGNT279/Av6G/K9R78I+y9k/g1/8aG//oaPy3<br />
yfHwfEf4u7fxyqb5Xv7HD/Ob9T+8/ymYf8D/wmGAG7ou65c/fpTL8v0DgopqKdf4<br />
X3d5CYlZ2w77LbJlbTZBfyn49U8F0F41FQAED9N+LiAkYGxXLauSiN+7hJE9CHmQ<br />
60gjHRFgEQn6zXdJLNmwEQ4Du/NgL00XYoPagIB7+Oq5tZ9kedyR8fUi87Wa9mxS<br />
fFTKT0iUiLP95jRcUM+cS8eDRoq92wUwxia4wj1AmotuSTM2YHmpWoNvduTHfH6b<br />
1qr0K8eZV4GquUjhSQP//ps2weD/P9KA//sPDYLsGg==<br />
</transaction><br />
<br />
</accountLedger><br />
-----BEGIN LEDGER SIGNATURE-----<br />
Version: Open Transactions 0.40<br />
Comment: http://github.com/FellowTraveler/Open-Transactions/wiki<br />
<br />
PH/3gEhhx7K0SyqsEG7+MRxLBXGNcBFF3pjiolekZSU7cAWVeISqp3rDfdYaWBC3<br />
AjMjW9xWuBTuMYASsjPQpJLmW9lWsZW0sTusK2eOSX6hAA6pappt9qGN2vqR9o+r<br />
Gzd/wBbRNj9INX9UpqHQZdglVyJW5K6R5WDN5XOsNKc=<br />
-----END LEDGER SIGNATURE-----<br />
</pre><br />
<br />
As you can see, the ledger above is just another contract. In OT, you can have contracts nested inside contracts. Inside this ledger you can see there is a single transaction. Upon decoding it, the actual withdrawal request appears (below.) <br />
<br />
Notice that this transaction has a "Transaction Number" (in this case 854) attached to it. This is a security device, similar to the request number:<br />
<br />
'''Every transaction request must include a transaction number, and you may only use one that has been issued to you by the server.''' <br />
<br />
Some instruments may be written and signed offline, which means you will want to have a supply of transaction numbers in your wallet, in case you want to write a cheque or sign a payment plan, or whatever. (NOTE: these transaction numbers ''cannot'' be used to trace the digital cash transactions, since the cash tokens themselves are untraceable, and cannot be linked from withdrawal back to deposit again. But the withdrawal and deposit _will_ each have a transaction number attached to each message. This in no way violates the untraceability of the cash, FYI. That is, just because you used transaction#5 to withdraw some tokens, and just because I used transaction#9 to deposit those tokens, the tokens themselves are still untraceable, and the server still has no idea whether I got them from you.) <br />
<br />
'''Transaction numbers are important because they are what make it possible to prove all balances and all closed transactions, _without_ all parties being forced to store their entire transaction history forever. Instead, parties can prove their position in any dispute, simply by saving the _last signed receipt_.* Nifty, eh? [[Triple-Signed-Receipts | Read more about this]]<br />
<br />
Here's the transaction:<br />
<br />
<pre><br />
-----BEGIN SIGNED TRANSACTION-----<br />
Hash: SAMY<br />
<br />
<transaction type="withdrawal"<br />
accountID="PhmhKernutijMa2XXxH1dZnTluIDQUVn1tifSOq9H4x"<br />
userID="Bg2QrSTomOEU5ICfvhfYfBYxQZPktDSnaVPpMLYxUnz"<br />
serverID="44FmyPAgrmGu671RywGnhrt8aR6tzmNFn9WKQ92BXn"<br />
transactionNum="854"<br />
inReferenceTo="0" ><br />
<br />
<item><br />
eJxlV8muq0gS7TVfcfW26DXzVKpbEjbYDGbGgNkxJIMZzQxf37yqRZWqkZCIIOPk<br />
iYDMjPPz53ldxLusfznyXReFL9fmdYe/urKhf8muqP0a8BOSorH47cvhtRcE/V5O<br />
oPma9h58/1jLqUiHaI3qH9DXOEXTPH7/GMBnBuN0eqYhascomcqu1efm+wdLkb/G<br />
gWEBgyx8/yCThExTCk1iOmJSLmFSlMJJFKBcGmV4DLIkxViOILCU5iKUyZg0xTCQ<br />
sjRHMynA8ITLspQERIKnDJqiKROhOMthAGfRDE8zLEszlKJIgmJpljxdccbEBJOS<br />
OMdFKZ2Ck8w8/kWFSbEky2gqYjIQR0kUoXEcxQyRpTSFEjigaRwF5yOWkRhHY/HJ<br />
johSiqLTc8KUzKgkiik8ShKWSVAmjTgsi9OEI9E0YukzKe7MEaAxEdEZYFKazuiY<br />
yFgQcyTFYTGVnlSyoWv4JOnmdvqTEcVkJEfhCUjOBACbRTiLg5N2hkUApzGCyhIa<br />
kBwNMI6iAWBiDOPOQp7GOW101ihlo4Qh4rN6gE2jJGNo9MwSBxzDYQSJUQQaUSgd<br />
R1h8htIoHbHnfSaHJTGXxr++X/cPPqddtjbIwADaBLjd9w/0dEXNr/ffPzAURX98<br />
/XH+Hm03gT8goGzHwR6663myWx7G8+auqZkdAqF4qO55rKmZifeUE8ne2Mw+Lsht<br />
26WrPXTahVfCNyRdrW/od+QvNOj3aJqipGhAO/2JPXl1ZnZo7hN+Cm9RCtsuUWHK<br />
B4h2vhpWJtxpcUXDIl9NBnNYWJsei0N80rjHbA+yj+xppjDS7qHscQHNTv6gvOrM<br />
nd8UWiKoQduVgxDvHc70i6zACKK94A+rH+J4mC0FQytBCQtCUNtaIQGiXZECSMsU<br />
bkfWdTSG5PZNQG+IHa3qrpoMnMbDa3zxBHCRy3Ck4gg5c1JZx+1ZerexAPqrCZOk<br />
hGWyBgllYxrfoaPDb2VMojaofceorC33I6oy7MOMlPgKqc9LftM+ACevha/0V4dk<br />
LlFsl5G9vcv4kJ9CtMyKPJevz0Tzh3mgCfke9UsDxLalzBDi3gk1lm95/LiW/EmO<br />
frbUvrL6VrQue++FBQC5Wn00ysqvKl7NFtWo6nPU+N17JIftQny+LrPRVVc5vz62<br />
BrXFsbGIu7+ugtEVHvDqwvPK4lYltlKVnqmq8Ku9X1RxBiSjWhK0LLhKCz1OmqK0<br />
KRyOUbZe2oTUxmGbuZp5HWfG9ih10cy5Jbks1WeGcS+PbguUZxtvkH/x+TDfhbuG<br />
XS2+G42WGGkpyQ53uqI6HgI56uX7kZBBsVCAIjlnlKOrsW8+MeXwgUOCrItMM0U5<br />
a0aeKMtSVm/CGy/gykk/n93zjN3/lHzAsJSc90O9XQwu7yZ3etthTiQphD0mMiIB<br />
WqUv+mWAln8RKBNXfuBUnc6Sqk3aHV8DWg8/x3IZnIhSZvkzUztRUcugopBbvz66<br />
TRnB0BSLFwU50PLQr/WFnSqCoXNfCFYhqrfc5du5fsZ1wJ4BTM+16FjfHR6i4sOa<br />
S2avRmHMdd1UrpMqKmx7jTmJ57a61kkNvF4OmCVUo5X5svtVmGPzE2v0+IMe0HVv<br />
jnssWVPS0nFSizl9zLwuzy296cy6jLP79FCb8CKhi/yKY146Z/hl19xp8CSTyIN2<br />
03o6N/iIBwIMkfAexvSjjP2Fvr+WJnzS/VWy9K1/SzA11NcH2lFAgj9xqzNSPHd4<br />
DxWtR92VW4OpUX+/iDAQnljloxtR8gqppEWnGO/5xorBaDqb4oj+MZppegMtPJGx<br />
/hignJ6SXZ9D3QHvpB71oCbh4vEWxvKzVkK3KOItefsMYhrOfm4AdWx8xP56IGKs<br />
nyvHOCD4cgGx5GJ2oIs5X78FBsbYD89ynfGi8ns545RGbS3nawOe3iTgk4y2oerN<br />
Y4MxmB0J8uhZuz3gGI1zVYz5oxYZ3SdzQ36PvEX2HG08MyEIkwf6qoEObmymBoUy<br />
xerNmIkqZyE/cbh4m+rpstmP22xaMKrDGEO+Wcvf3J5veOxKXRcKtq6JfHlJ1uaZ<br />
FdtdmN5UHEolocVT8r6PwmCP2iU94u7+eLfR4+bNJDwd+u25BK/O9Bu0vWQaNSS9<br />
9UBig98P5DXtNwqFyjm1YUXKmEcIGMzvr3746IklrFqaYq1es+VL1ZZxxc6XUr6D<br />
ILwjCch3WgjMrhnDElKFxvfSj4nq27DxbjFEcIsAtG6U7oNdxM5elXOTMjbxMWkl<br />
/HLw9sWobYJzxnzz2m2HQmoB5kifB5InonW3MrdUIYxhN2ysadI1q1XpXmx2q/OZ<br />
VyWsmsdOVPcJSVYJFrMjCt2J7ROQWmcd+ONTiwLnIfiF4BKqGBEBJu42UmLXNCpi<br />
2o2KZ7Fz0/QY90p7mFOAh5MMFWRpRBRN5cs8PyZx7axscuHnG52p/NGs1zezkk+l<br />
lKhdvSuJbBHoHpD2I6sO6TU6ugk9qi6eYxXuHjxvar5JUZcuxErO1eUctO+5QKn+<br />
s8rNPiWwQqE3y3gztMwFR+f3RbA0UEmU2DsJO3lh4ScxtfWzWCvnPRl3lOCPEGmI<br />
azdW2qJZL2Ydp4MJFDltzCp+mJ/aO0joLMCoIXQUNZYW00+pUTxcnevKn/1L5ZWd<br />
MveLgHP5RFWaDYfhh7PqyLQqrlB1gMEsBA8PQ4kQdCX2iRneQoBLC9YskmzNucfM<br />
tiiMVf2hO8vdKg4WKuMx1fE60ZGuYMpOVdCGJkSGdW5xI1nk2ty8az4Fme83CmO6<br />
Dny16KbBROA8h1DKnOLGRtiok0ogKMHV2RgMCll8YmhCZLht/tSOI3X3sHcfHjuY<br />
oTwE0bxfgHGwarSLszQeVAZyc6Te2MEaPPfhU6gmxx4zFlTqP5SoN+bN3Qi1jc27<br />
10/r3EXvyHsNT4I5+md0XEONel/z2IPjfhnP5ue6Qw/eDT8ybRdU/cYrmIwyf89m<br />
zlQOax3uRjNuad487sw2I/l5khFdwGUH97gmDtGRz1KE4CUWLqacmFfMbijzYXsX<br />
Jwia0lymIkNVRD47ioEzGWdbWD4gkDcbk86ZQO+6pGy6MFTZrU3Aj2KjMu4iw8tL<br />
I4GDRaPCKGwXw7YqWWGxiixWcBkXd3C2C/LitYOHULFm0TIkmD1MaOz7Dr8vb3On<br />
SXNCAlIY3TTln4+itVaZGfQ4MQppPSRUiWPq1ZrvGdDYm9kYFtpy6Q3b8fIcY9Vs<br />
4FCf0cQ36yfu7Pf6I9VqR3ohPRiI7ctGJ6p6nMe14tPdO9dfww5DBTHoOsYmx6Gh<br />
y7obWy0e6+fIX3Rghi+/KKdUI0bVur4rNQl8gl8ybo04IUzdAbA5DeXVKF0uES/k<br />
NYIU6LrbDyRjyjxD0Nhe0chav391iP/sDE/zlzr5A/r5t7D5t6L5U+nw7tMW/9I2<br />
HhjGU6D89mX0oP1y/5Ys4xf6XxKFrl3zC/y3r2Ka+t8QJD81zxz/N+ka5Abqc586<br />
QxZQgwH5BfDznwDIWlYlBKGtwqdrkQtP2WO3JyG2Qk49hNXu1MbEtlDSJSu3ZrLg<br />
Fyp9btF99Uq3GlDXqnGjlHsIlMCnHpFkgFdZsDBRZ0TuXIPM9DGGnrguwvkJwUau<br />
vjGPNPOKl4Kw2d1X3BMqm7UJYlvREcscTTPtvZW9lBi5CLsjyTgq2mm2uaDmwlDj<br />
h0Cq779qJ+r/rwX/XTnoP/8DmLqWjQ==<br />
</item><br />
<br />
</transaction><br />
-----BEGIN TRANSACTION SIGNATURE-----<br />
Version: Open Transactions 0.40<br />
Comment: http://github.com/FellowTraveler/Open-Transactions/wiki<br />
<br />
WAOQLt+/E3BmituIcFp/XHHT/1A6uq81m5W3a6+UkptcPHNQ1C3+myxBzKMEbN7v<br />
WCAUJyvlZctANwqVV6fuirwerIU2Gfy/FG5ylpf80g7LfCdqx81gwmwE+b3r0i4T<br />
GsgmtdeBWBDGiuWpexfxsypklPiMzf49Vg2JfF74ck0=<br />
-----END TRANSACTION SIGNATURE-----<br />
</pre><br />
<br />
(By the way, you can decode these things yourself using 'opentxs decode' at the command line.)<br />
<br />
In this case, the above transaction contains a single item: the withdrawal request. (Transactions might have multiple items, covering additional functionality such as server fees, balance agreement, etc that may become necessary for each transaction.)<br />
<br />
Here is the withdrawal item:<br />
<br />
<pre><br />
-----BEGIN SIGNED TRANSACTION ITEM-----<br />
Hash: SAMY<br />
<br />
<item type="withdrawal"<br />
status="request"<br />
transactionNum="854"<br />
serverID="44FmyPAgrmGu671RywGnhrt8aR6tzmNFn9WKQ92BXn"<br />
userID="Bg2QrSTomOEU5ICfvhfYfBYxQZPktDSnaVPpMLYxUnz"<br />
fromAccountID="PhmhKernutijMa2XXxH1dZnTluIDQUVn1tifSOq9H4x"<br />
toAccountID=""<br />
inReferenceTo="0"<br />
amount="1000" ><br />
<br />
<note><br />
eJxzz8zNTVVITizOUFTwdPfzD3JV0NVV8PMPcVUIcHRx8fRzB/FxyHCRroMBAJZj<br />
HCQ=<br />
</note><br />
<br />
<attachment><br />
eJxtVlfPo0gW3Wd+xad+RT3k1JqeERgwOQfDG6Ew0ZhgwP71S8+MtLvS3qdbp1RV<br />
RzfUPd+/nyZIV9X68tWrJYlfTuj50i/0O6RkS/3jy+fNBIJ+//MY+q8NzEszPn5+<br />
w35Dv/35xwk/X/MC/heHvtZxzfoo61/gRFD0F/RawKyKP7+dbrYsYA3eT/BrzdEs<br />
SuckQzFUiVFsheNYmZcci+I4lec5R1MAo0sSAxib40RelWSOkQxgWa5kORzPaJbC<br />
KUBgFMqe24ChWJpCS47BabRiaRxjibzIUDavuJIuiYqt6AzPz0c4jsNBmeEnn5PZ<br />
9jc5sijIsqTQIqczpuQKpkQpnEQBypVZheegKkqM5QgCK2kuQ5mKKUsMAyVLczRT<br />
AgwvuOokCIgCLxm0REsmQ3GWwwDOohVeVlhVVihFkcRJkiVPKK+YnGBKEue47KQH<br />
vv2K6Dp24PEHxJ9215RNiR3HnbZnfTMPCsu7RV5KvMPun49fdNu77TBLoxXJUnbx<br />
WBWAZgyDGM1CQAosOn3s6HcfzTtC0N2ZeIapIGzc4Xhv5e549SsIaCOyxW3tg+z2<br />
DINE7mtag8PaVEIIHflxDj2h+kSdqqyVVOyWqiAX785IgprlxBO9gotTtjRZg3cd<br />
1Lt4a4e0kdY6YOenAY307bkWXSkoN84KR4RoAle6NZqzvBrSa5JuIqu5y3k5vrK0<br />
TlYqNR5OXrmhvVaXgeMgZWlNv8tk376gWDXwDalxgTAnulUblX8YqN7p9n0slGSA<br />
5bzQui7yksDsgNNPJCtKEJ8nCb9HA9xllN4MeYYSeuH0M6JuByWkZg1uU1mNbq0z<br />
CymzGbHQtcn6bclEg6zuANIun6xN7wvsuTUV0R3VaDoaWk97YN9OWiomG6eU4caV<br />
yPQUSF+zbr3eraDjrsdqJspB6GYvmZU6pCHQNxpjH+5rlCL0o5eH+qbnN7Hbuo2p<br />
hnV5GJFm1KapGBE+eDU1kW0x3iAJ4JdhoJOjuF8EXsPSxJSEWzsPddFen+t4bNLr<br />
g6tcyNuZNSejclsNXl4+hLjDsiqwkDovJEFcjW7/POSybp1lbOqEpCz/EbNJpCOz<br />
+BBebHT1RXNEgAljD7+18qA89oOY5gGiu25M5xn9WMr2dFHeW47Mx0KFV8XsXuSH<br />
V6uMFL+b0bgKEbAzlE7NW4gOIjsAQ4p96OUfDXZcL0YleNeF8fKXhJtbKFOu3kg8<br />
WcS9bxtltBxRLFuPQ+0N+174j8QWxTpAmA1C5Cv5+QCcIBYHQxVPk8oB7pPJS5K4<br />
vVJgppaZXyanvdzboGLjnaLFVu4+tzNFUvXYoPWm0nBfM5rcpQL/bOAyz/YtyF50<br />
iudR+JHf7LZe71WpCWZLp3vZkn658QpMRIBknibk8uBiIGeXZG/cegy6DXPomsZi<br />
KDmWVdqP0NxrxAThra+n/e0lmJoq1BEoRwJS47OxELtMi+YS2nY7Knc29OuFVnxy<br />
Z5vePs66baVE0low7FdJ3OryOR1mmdwflKHGhxRnNAfVkc8KgbSalpc44kc1b8s0<br />
G3xqX4MoQz2LqlED9V/2B39c5hs/D+3GR/i1Cdahb6TahUhy9ttLsykMLPtX2ZtI<br />
h4iOa565gvuuLtEwoQftT+Uj0u5gLmwCj7w4UJiH5yKGJcIQ30yX4RLfkzHYsSNP<br />
LkobubK+oLAAPMWP55BoZ1i9TNIgenjuh05pqwImytc+J50FQOj76I9XzoWphXvm<br />
i3i1jcZoIv8+U3tnlUhwkSjtOG03AzZ/m3CoskMvMQY7wstz7XJIdmPkbLPqlVz4<br />
qX4sM/6aamQMb6UHmJV2KulkWuWBkVioJupvD29gt5kMR+ZZq9QlaPQk9hKNe1+8<br />
+rLOJa/0w3yt7rjDX2Hv1mvHIQugV7uREDsklq6oQTxk9+DkOLtlbwt6aNJ1Jy5k<br />
x0c3f1oThF48/CmFVCgtXfWWmJ7PTS+CQ6mm1EeSUrZHfShF8a1sN4JXDJXCSx71<br />
Z82t763E79xuqlSSHoGZpTLV8rPZIrXauyBeOz8KayEuHsz5fegPs5j1z8OA9qAd<br />
l4sp1Ov0Hpq5ENmPFTx3KnbPGVptwuoajaVYrU37zpUazCZM5jCgbV+bpvs611Cy<br />
LATZqI6Rh5lj2k+4afWyfu9PJzQwrGOmsxdgmLG7xu/gKQH3oX9fz9LCcS3o4UiE<br />
+vbDBPIcPC1Rm5PLRVBSXXmiPvthf0K/I//Mr9P7Sxv8AX3/j8b4S1z8pTT4IPT+<br />
kRnR3+Lhx5f9BI+vYM4eS1asJ7J8ob+RKHQZhwE81h9f9bo+fyDIvVnrV/5bMQ6I<br />
DPp+3M8jG+jBjPy64Pt/X4DsTddAULhnQwI7rNbcOhHwzH0Jbb5YnPjue61j7x78<br />
xgHj+RbvUsbKPm+ZNu0cWPlU2SyGlqHlKo4VZ6rO/RWIOoEKNbgblJW6ojgNYry+<br />
h3rNN18czzM0vwyOxlEzwqzgY6XPZYWhitdM3sKQCjkKcXW3Avf9wa9DZdTre8g6<br />
gksHBBaADgl//h0wyRL/f7igf/0bRw0aQw==<br />
</attachment><br />
<br />
</item><br />
-----BEGIN TRANSACTION ITEM SIGNATURE-----<br />
Version: Open Transactions 0.40<br />
Comment: http://github.com/FellowTraveler/Open-Transactions/wiki<br />
<br />
0nJAdwhgDUIV8xU3EnDg5LDwRoKmP1xZHNHQgQu4hAv5dUxaGwViTkr0TQl2OiIp<br />
eieW5LaHOeYih8+3lf3gSCXfPW176t9oa2At/1s9lF7LdfVhYJ/8fGWJTaGwfuMt<br />
8nESEig0dfMjxipHcOgE+Ts47SK0oMRPv0Pv75sq3/k=<br />
-----END TRANSACTION ITEM SIGNATURE-----<br />
</pre><br />
<br />
I’m sure it’s becoming more clear how central contracts really are to the design of OT. So far, we’ve opened an envelope and retrieved a message from within, with a ledger inside, with a transaction inside of that, with a transaction item inside…<br />
<br />
Later, a copy of the above transaction item will be included by the server as part of my withdrawal receipt.<br />
<br />
So... the above withdrawal item has an attachment on it -- what is it? It’s an '''''OTPurse''''', containing the actual prototokens for the cash withdrawal. (The wallet must ''blind'' the tokens before sending them to the server, so that the server won't know their IDs when they are signed... that's how they stay untraceable: their token IDs are only unblinded after being returned to the user's wallet.)<br />
<br />
In this case, only a single prototoken was necessary for this withdrawal, as you can see if you look inside the purse:<br />
<br />
<pre><br />
-----BEGIN SIGNED PURSE-----<br />
Hash: SAMY<br />
<br />
<?xml version="1.0"?><br />
<br />
<purse version="1.0"<br />
totalValue="1000"<br />
userID=""<br />
assetTypeID="XUHBvdsWAEmErZMzHaRKaNPaAVsUvKwL4uLY4nOY2s4"<br />
serverID="44FmyPAgrmGu671RywGnhrt8aR6tzmNFn9WKQ92BXn"><br />
<br />
<token><br />
AAAAgJHvHWPPQqvphXMx51bksFsd2k1gzzSckvyjk1NJ6HENHwDxtHe0a77/Lis3<br />
H+DPlWPKgS0bk3BKQr3pUZBBv9xPRyHgPRhuTT6LVODvtlTaXpUTYFlh6J+UhMHU<br />
0oAorURBfzVkIHtfEcwNIH/CRg7EBIab3p0GeCPdj64heyhThwDXjmZiEthT8rpL<br />
o6XptckdBHX9NUo/3iTQEXiJPsui4RiYkq4frkbAFWG86K4fI5oxPbfQUOtfCm99<br />
HsjMSkaFSOC01fmAi4J9TBrYKNhLfSxL0KkKOgocHYm+FbcJkkVRYTMkePlq48DE<br />
AbYYAwVm+ka5Kimba03KcPlr/Ivx5BZMheXqdfoQhK7s4F8a3s6hM8Sjd7VmFIwe<br />
JCzajZgs+RQh5V6k5iJK0UNpOm8yPZdHM8WZ5LQWfD7l5eZurKNuyjBK2QR8JM09<br />
0vOsaNZP4LB6X618nQuoEV0zKdxIy6ry3wOKO1ILNCnLVJLhMMHLV2mRh5q4jcoX<br />
Ee2Cmm6YxcgCBAJ1ZYMEBXjrmhcjGptoxvEuz2I9UAOaNrYoHXtLAFsz3Dw+FIB8<br />
Irs433GLkwznFdhjPsoihY45NSnW8YVK/rDnBu8VGSDMo/eM+1nSjNbTdxwx3qrm<br />
6kkoZrr0zNHvpQ0ARsxaS1UHAIDagcbxRhI7EWyioLGBVeOa06ZMXU0mD8meLEWS<br />
uSxi1xGCLfBRGs7RbuE2MvUF5QKiEA4cWlSOLdVsxVWFNnxIlLOgcSnYODDhT/7v<br />
/FG4zze233sP10HRJEdm+lYqRYYWjG5er5srAsqPjCgjTf8Ww56DjFkzXPZdEfnv<br />
tXI6+lh7JFkZBApi+dbawvTau6Z2bVUzFy8vtGgfdJBMj6Zwdj4SdvAH+3Ve47pM<br />
QAeCL/lTaay2NnmKO+90tZWDUEPNNdOnUMwh/MeUXlhqwyRY1IZH5xTHxYeZLzv8<br />
8sqsJQ3JvXxfQrLKGC6HS4w8ilOxJkkjEYEJjemwGEDvhdpqxMdYgn5LIWxEWa69<br />
hVS8BTEtMNRYPDzIMXsqrLAZOGTVa0RN5h0L0SuOz2nCrXArmjvAV2GiTtmliEhQ<br />
44rSjCivH7+FSGFRq4P3VxGbaQBQyfCVmq0x6SqdnVJgercO32VRWTH7nRQ/LND+<br />
AiqCmCWgYoTw1xbYCHjVQFKs0+BeRHSWrU3jr+ICqEmDR2bSUPdOIB1DFGlb4Pse<br />
0yxlxub9UZN2RMu3ujiJ7JDAyze2g8HVBQ/VZk9JwMT8byM+UI8mlE7L8o+sptkb<br />
FQW/l5efuYCAqhnsr2uqh/oUXdRe7t6PfE/LNfbTLYN0JDKyR2i+QiqLPFA8NdKE<br />
oRE8CVowlculdhbERdSUbtfg2PAG+RXlJxxFBelIko3Dk/WEG0L3nFQx9FWaXayN<br />
nJEGw3C4kAVXSqtY/6sR2pEU5UEskfyE7lAbMRV+UEh5InYZ5OR5z5HHSNawLTuW<br />
dBuFoKph9tyvd2g9wMI5YZxTMaZF5jArMj/hIlQeWtkSVUhBWcn7NZPKnMcrKznL<br />
wTjosCMBhtqymircD8zNTpw5WQ757fvBtQLiNHNjO6SPG5mMiUYrUT6OSJqqgtrh<br />
Yss34iIPLbUaPMOp+ijKdhywpPUL11k7qy8v++7OkiSk+qYegmlyGL0S22JTl+VD<br />
ljz7TFrTpNDJrYCCBHZKHp0S8z8=<br />
</token><br />
<br />
</purse><br />
-----BEGIN PURSE SIGNATURE-----<br />
Version: Open Transactions 0.40<br />
Comment: http://github.com/FellowTraveler/Open-Transactions/wiki<br />
<br />
UwamY+P8JiXkDeA7gsUOAcsPWgSRjPOwR+y2e7RSNAQ5Lt8pXaJqw9etAZHvN76F<br />
sGDof9MIPguTDK30BhegL5NZQDDqmDWtymhtbvSDoetA6AsmPJ95r/7tezNZpst+<br />
fAJMAN1/f/xcDtQvc2SSmShUHoKhgU8PBQ6T31Tek/U=<br />
-----END PURSE SIGNATURE-----<br />
</pre><br />
<br />
If you want to write a cheque for a strange amount, such as 1291, or 87622, it's no problem.<br />
<br />
But with ''cash'', the cash tokens come in specific denominations, such as 1, 5, 10, etc. (it's a part of what makes them untraceable. Exact denominations to be configurable in each [[currency contract|Sample Currency Contract]].) Due to this, *you do not handle tokens directly, but instead, _purses full of tokens_.* This way you can have a purse worth 1291, or 87622, or any amount you wish. That's why all messages involving cash use an OTPurse.<br />
<br />
The token in the purse above cannot be base64-decoded since it was actually encrypted before it was encoded. (Tokens are stored in encrypted form.) As long as you have the right nym loaded, you can use 'opentxs decrypt' at the command line in order to view most encrypted contents. (They might be in binary form, depending on which OT data you are actually decrypting.)<br />
<br />
[[Sample Cash | To continue reading about cash tokens, click here]].<br><br />
[[Sample purse | To see another sample purse, click here]].<br><br />
[[Sample Mint | To read about the OTMint object, click here]].<br><br />
[https://github.com/FellowTraveler/Open-Transactions/wiki/Smart-contracts To read about smart contracts, click here]<br><br />
[[Messaging | To go back to the OTMessage page, click here]].<br></div>Cryptoman