Title: Open-Transactions v0.71 release Post by: fellowtraveler on September 19, 2011, 10:23:37 AM Open-Transactions new release: v0.71 Don't miss the OT video walkthru: http://vimeo.com/28141679 http://vimeo.com/28142096 Bitcoin donations: 1NtTPVVjDsUfDWybS4BwvHpG2pdS9RnYyQ (A word on donations: Thank you very much to those of you who have kicked down a few bucks to support this effort. Even $100 will pay for a half-week of my Java coder's time, and those of you who have supported the effort have helped us to produce the now-functional Market Screen -- shown in video 2 -- as well as the upcoming Basket screen, which we are debugging now!) -------------------------------------------------------------- In THIS ISSUE: *** The COMMAND LINE utility has big updates. *** The data folders have changed (Now: ~/.ot/client_data and ~/.ot/server_data) *** The "sudo make install" and "sudo make uninstall" were added. *** Lots of debugging was done in the core library. *** NEW POWER: finalReceipt and basketReceipts. *** 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 "destruction of account history". *** Finally, thoughts on RIPPLE, which is now theoretically possible within OT (due to the above changes with finalReceipt and basketReceipt.) ---------------------- Latest code: https://github.com/FellowTraveler/Open-Transactions Binaries: https://github.com/FellowTraveler/Open-Transactions/downloads (This release covers the core OT server and API only, not the GUI. An updated release of the Moneychanger GUI is planned for the next week or two.) ------------------------- Let's go over everything in closer detail: DATA FOLDERS -- The default data folders have changed to: ~/.ot/client_data and ~/.ot/server_data -- These locations are configurable in ~/.ot/ot_init.cfg -- There are also the config files: ~/.ot/client.cfg and ~/.ot/server.cfg -- I'm open to any IDEAS about VALUES that should be configurable in the various ini files… Thoughts? -- A fresh copy of the OT sample data is located: Open-Transactions/ot-sample-data -- (The cash mint had recently expired for the silver grams, so I regenerated it.) -------------------------------------------------------------- MAKE INSTALL -- "sudo make install" has been added. It copies the contents of ot-sample-data into ~/.ot -- It also copies transaction.exe (the server) to /usr/local/bin/ot_server -- It also copies testwallet.exe (command-line utility) to /usr/local/bin/ot -- "sudo make uninstall" was also provided for your convenience. -- If you ever want to start over with fresh data, just go to the Open-Transactions folder and type this: sudo make uninstall && make clean && make && sudo make install -------------------------------------------------------------- COMMAND LINE UTILITY -- Lots of updates were made to the command-line version of OT. -- After installation, try "ot -?" to see the command-line options. -- Certain default values are provided in ~/.ot/command-line-ot.opt For example, you don't have to specify: --server SERVER_ID --mynym NYM_ID --myacct ACCT_ID with every single command-line run, since defaults are provided in that file. This means commands can be used such as: ot --balance ot --withdraw 500 ot --transfer 50 --hisacct RECIPIENT_ID ===> Can't you imagine the above commands as URLs, instead of as commands at the unix shell? ===> VOLUNTEER WANTED: create a Google Native Chrome version of OT, that enables URLs that perform the ABOVE sorts of commands. -------------------------------------------------------------- $ ot -? For this first rev, here is the command-line output when you type: ot -? Server default: 8dlRJnGCjqU5jw7bZaw2AF112UrCZiFfBS9CnJrMWSp MyAcct default: sSBcoTlTkYY8pPv6vh2KD6mIVrRdIwodgsWDoJzIfpV MyNym default: T1Q3wZWgeTUoaUvn9m1lzIK5tn5wITlzxzrGNI8qtaV MyPurse default: lV6acfWoWKB7BcuIXCzvS4aSiqUOjlGgVTyepg1aAsa OT CLI Usage: ot --stat (Prints the wallet contents) ot [-h|-?|--help] (Prints this help) The '|' symbol means use --balance or -b, use --withdraw or -w, etc. The brackets '[]' show required arguments, where default values are normally expected to be found in: ~/.ot/command-line-ot.opt ot --balance | -b [--myacct <acct_id>] (Display account balance) ot --withdraw | -w <amount> [--myacct <acct_id>] (Withdraw as CASH) ot --transfer | -t <amount> [--myacct <acct_id>] [--hisacct <acct_id>] ot --cheque | -c <amount> [--myacct <acct_id>] [--hisnym <nym_id> ] ot --voucher | -v <amount> [--myacct <acct_id>] [--hisnym <nym_id> ] ot --depositcheque [--myacct <acct_id>] (Deposit a cheque.) ot --depositpurse [--myacct <acct_id>] (Deposit a cash purse.) ot --deposittokens [--myacct <acct_id>] (Deposit individual cash tokens.) ot --inbox | -i [--myacct <acct_id>] (Display the inbox.) ot --sign | -s [--mynym <nym_id> ] (Sign a contract.) ot --verify [--mynym <nym_id> ] (Verify a signature.) ot --purse | -p <arguments> (Display a purse.) Arguments: [--mynym <nym_id> ] [--mypurse <asset_type_id>] ot --refresh | -r [--myacct <acct_id>] (Download account files from server.) ot --refreshnym [--mynym <nym_id> ] (Download nym files from server.) ot --marketoffer [--mynym <nym_id> ] (Place an offer on a market.) Also, [--server <server_id>] will work with all of the above. Recurring payments: ot --proposeplan <arguments> (Merchant) Arguments: [--mynym <nym_id> ] [--myacct <acct_id>] (continued.) Continued: [--hisnym <nym_id> ] [--hisacct <acct_id> ] ot --confirmplan <arguments> (Customer) ot --activateplan <arguments> (Customer again) Arguments: [--mynym <nym_id> ] [--myacct <acct_id>] MORE soon. ------- Whenever dealing with IDs at the command-line, specifically My Nym, MyAccount, My Purse, etc… ** PARTIAL IDs ** are now accepted! OT will try to find it first as a complete ID, and if that fails, then it will re-search as a partial ID. It is still case-sensitive, though. -------- Most will continue to prefer the OT GUI over a command line utility: https://github.com/FellowTraveler/Moneychanger But a command-line is still a valuable tool, so… ** please send me any feedback based on YOUR NEEDS ** so we can shape it into the best tool it can be. -------- FOR THOSE FASCINATED WITH TRIPLE-ENTRY ACCOUNTING. (A description of the improvements made to receipts in the latest release of OT.) Warning: boring accounting details below... -- 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 "destruction of account history". BACKGROUND (using chequeReceipt as an example): 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. 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. 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. 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 receipt receipt, minus the amount of the cheque, which also features #47 -- a valid number -- and YOUR SIGNATURE.) 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 "Issued Transaction Numbers". (That is, you no longer have to sign for #47 on any of your future receipts, since #47 is now CLOSED.) IN SUM: "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." -------- NOW LET'S examine the latest updates to OT: FINAL RECEIPT and BASKET RECEIPT 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. ===> But, for Markets…. (and other recurring transactions...) -- 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.) -- 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.) -- 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. -- 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. -- 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. ===> THIS IS WHY there are now THREE transaction numbers for a market offer (say #9, #10 and #11): Because when the "Cancel Market Offer" message is sent, it requires no balance agreement at all! Instead, these actions occur: 1) Transaction #9 is permanently closed, and will not appear on any future receipts. 2) Transaction #10 appears as a FINAL RECEIPT in Alice's WHEAT inbox (in reference to #9.) 3) Transaction #11 appears as a FINAL RECEIPT in Alice's DOLLAR inbox (in reference to #9.) ===> Trans#'s 10 and 11 stay open. (For now.) ===> 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.) ===> Alice's "last signed receipt" shows her inbox contents, and the same receipt no longer shows #9 signed out -- she's not responsible for #9 anymore. Thus any marketReceipt appearing AFTER would automatically be INVALID. (No NEW balances changes are permitted, related to #9.) ===> This means that new marketReceipts can never be dumped onto Alice AFTER she has closed a market offer (or payment plan.) 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. 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.) ===> 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. ===> 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. ===> 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. I find this very interesting because it takes the concept of "Destruction of Account History" as pioneered by Bill St. Clair and Patrick Chkeroff, and adapts it to recurring transactions such as market offers and PAYMENT PLANS. This innovation is unique to OT, as far as I know. ----------------------------------------------------------------------- The same concept has also now been adapted for OT's BASKET CURRENCIES. 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. The OT client will now provide **4** transaction numbers in order to perform the exchange: #9 The main basket account's basketReceipt #10 The dollar account's basketReceipt #11 The gold account's basketReceipt #12 The bitcoin account's basketReceipt 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. 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! 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? 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. I find this very interesting because it takes the concept of "Destruction of Account History" and adapts it to BASKET CURRENCIES. ----------------- This means: ===> finalReceipt means that OT can perform transactions that PROCESS REPEATEDLY OVER TIME, even hundreds of times, yet it maintains the secure paradigm of "destruction of account history." ===> 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 "destruction of account history." ===> 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. This is awesome IMO! ----------------------------- I'm sure you can see where I'm going with all of this... **** RIPPLE **** The latest changes to receipts are what will make it possible to eventually add RIPPLE CREDIT LINES and RIPPLE FLOWS to OT! 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 "credit lines" between Nyms, and then have "Ripple Markets" where payments can flow p2p between the various credit lines. This is made possible by the new receipt code, since instead of having to sign for each individual transaction during a "Ripple Flow", 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 "finalReceipt" is thrown.) 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. It will probably be months before any of this actually gets coded, but you might enjoy the thoughts recorded. Happy September! And remember, the time is short. Your friend, -Fellow Traveler 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... Title: Re: Open-Transactions v0.71 release Post by: crazy_rabbit on September 17, 2012, 06:23:53 PM I've been looking into Open-Transactions recently, along with the open sourced Intersango code. I was curious to know if this project is still being maintained, and what peoples experience has been with it.
Title: Re: Open-Transactions v0.71 release Post by: markm on September 17, 2012, 08:04:09 PM https://github.com/FellowTraveler/Open-Transactions
https://github.com/FellowTraveler/Moneychanger http://open-transactions-tv.github.com/ https://bitcointalk.org/index.php?topic=53329.0 Also, go on Freenode IRC network and join channel #opentransactions people are there 24/7 -MarkM- Title: Re: Open-Transactions v0.71 release Post by: RandomQ on September 18, 2012, 07:51:56 AM Has anyone issued or offered a Mining Company or Asset thru OT yet?
Someone pointed me in your direction because I was looking for similar functions that OT offered. Title: Re: Open-Transactions v0.71 release Post by: markm on September 18, 2012, 08:39:39 AM Well there is General Mining Corp, but it is not yet a mining corp as you are thinking of them, because they along with British Mining Corp and Canadian Mining Corp are all waiting to see how ASICs come along before expanding into cryptocoin mining; so far the are really more to do with mining of metal, crystal, deuterium on the intergalactic scale, the various resources you can mine in CoffeeMUD or pick up and carry around and store in the CrossCiv server at individual characters scale, and in the case of Freeciv worlds the generic "resources" that freeciv abstracts all such things into.
Once ASICs are out though doubtless the use of ASICs to mine cryptocoins, probably via the Masively Merged Mining project, will be an important aspect of how players and games go about enhancing the perceived value of their various in-game resources, possessions and currencies. You can view some figures about some of the assets currently deployed on the Digitalis Open Transactions server (https://bitcointalk.org/index.php?topic=53329.0) at http://galaxies.mygamesonline.org/digitalisassets.html ; the actual contracts, likely including some contracts for assets not yet shown on those tables of figures, are in the digitalis-assets.tgz file downloadable from https://sourceforge.net/projects/galacticmilieu/files/ -MarkM- |