Open-Transactions new release: v0.71
Don't miss the OT video walkthru:
http://vimeo.com/28141679http://vimeo.com/28142096Bitcoin 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-TransactionsBinaries:
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/MoneychangerBut 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...
