I just wanted to give you guys an update on the Open-Transactions project.
I am aiming OT to become the premier open-source platform for transaction processing, vouchers and financial instruments, market trades, smart contracts, etc, for Bitcoin and other currencies.
The idea is to enable wallet and site developers by providing a standard crypto API for all manner of contracts and financial transactions. (So you can focus on the site you are building, instead of a myriad of lower-level issues.)
As I have posted here previously, I anticipate that Bitcoin is going to continue experiencing a series of embarrassing and destructive site-hacking incidents, until we are able to get a standard, community-scale, secure platform into place.
Over the past 6 months or so, a significant amount of work has gone into bringing Open-Transactions to the next level, and making it
more accessible... Specifically:
1. We have listened to your concerns regarding complexity of the OT-API, and have responded.
A high-level API has been created, which wraps the lower-level API. Most OT transactions can now be accomplished in as little as 1-3 lines of code. (The Java test GUI, Moneychanger, has also been updated to use this high-level API, so sample code is available in Java for all use cases.) We continue to support developers on the IRC channel and the mailing list, and the API page has also been updated.
2. A full client-side scripting engine has been incorporated, so you can write "UNIX-style" OT scripts. The full high-level
and low-level OT APIs are
both available from inside your scripts.
3. A new command-line client ("opentxs") has been written
in OT SCRIPT, with simple, accompanying script sample code for all of the OT use cases. (BTW we are currently using the excellent ChaiScript:
http://www.chaiscript.com/ but also OT is designed to easily swap in any other language you prefer.)
4.
Automake has now been added to OT, and Windows builds are also starting to become available via da2ce7.
I have just recorded a series of new videos, which I will be releasing over the next few couple of weeks.
(I will post links here, and to the OT wiki:
http://github.com/FellowTraveler/Open-Transactions/wiki )
On the upcoming videos:
Video 1: (Intro.) The new "opentxs" command-line interface, the OT data folders, and the OT script environment.
Video 2: "opentxs" CLI: Adding server contracts to the wallet, issuing assets, creating nyms, creating asset accounts.
Video 3: "opentxs" CLI: Sending account-to-account transfer, receiving pending transfers in the inbox, creating the cash mint.
Video 4: "opentxs" CLI: Withdrawing and depositing cash, and displaying contents of the cash purse.
Video 5: "opentxs" CLI: Writing and depositing cheques.
Video 6: "opentxs" CLI: Misc: refresh, verifyreceipt, getcontract, encode/decode, encrypt/decrypt, etc.
Video 7: "Moneychanger" test GUI: Creating basket currencies, and
exchanging in/out of basket currencies.Video 8: "opentxs" CLI:
Smart contracts. I have two working smart contracts I demo, two-way-exchange, which allows users to directly cross-exchange assets of dissimilar asset types.
Video 9: "opentxs" CLI: We also have a working
escrow smart contract,which allows Alice to send money to Bob on a (say) 30-day delay (for example if he is shipping her a guitar as an e-bay sale.) The money is stashed safely inside the contract, and goes to Bob automatically in 30 days, unless Alice files a dispute--which then automatically notices the parties to request feedback, and then notices a third-party arbiter, who has X days to examine the terms and feedback before rendering a judgment.
(The dispute/judgment process being nothing more than scripted clauses on the smart contract.) All three parties must be original signers to the agreement.
Video 10: The high-level OT API. At least one video on programming to the OT API, just to demonstrate just
how easy it has become(There are also 2 older videos already posted to the OT wiki a few months back, which demo the Moneychanger test GUI.)
------------------------------------------------------------------------------------
A NOTE on
PASSWORD SECURITY, and
KEY MANAGEMENTI have done a significant amount of work in the past couple months upgrading the OT
password-management capabilities. I thought I would update you guys on our work, because spreading this sort of knowledge is good for the entire Bitcoin community.
First of all, when passwords are used in OT they are destroyed as soon as the transaction is finished, and in the meantime they are stored exclusively in a class intended for that purpose, OTPassword. This class is careful to zero its memory upon destruction, and employs certain tricks in code to insure said zeroing doesn't get removed by the optimizer. OTPassword also takes pains to lock its internal memory (so it won't swap to disk, or at least is much less likely to do so.) I also added code to OT to try and prevent it from core dumping, for the same reason. These are the same sorts of tricks employed by ssh-agent and similar software, to protect secrets in RAM when in use by the application.
Next, the passphrase is put through a
key-derivation algorithm, in order to generate a "derived key." This is because we never want to store the user's actual passphrase, even just in RAM. Converting it to a derived key gives us something we can use while processing a transaction, without having to store the user's actual passphrase. Why do we use a key derivation algorithm instead of a hash? (Answer: because hashes are designed to run
quickly, whereas key derivation algorithms are designed to run
slowly.)Next, the derived key is used to unlock the
master key, which is just a random number and which is used as the "passphrase" for all of the private keys (the nyms) in the wallet. The classes OTSymmetricKey and OTMasterKey have been added recently, and also OTEnvelope has been updated to support symmetric keys, in addition to lists of nyms. This way you can have a single "master key" for all of the nyms in your wallet.
The master key is stored in RAM (inside an OTPassword object) until a
timeout. For example, if you set your master key to timeout after 300 seconds (5 minutes) then OT will keep the master key open internally for 5 minutes, and use that instead of asking you to re-type your passphrase--until the 5 minutes are up. After that, the master key will expire and you will be forced to enter your passphrase again in order to unlock it and use any of your private nyms. (This is just like the functionality you probably already have on your system keychain.)
Speaking of the
system keychain, the OTKeyring class has been added with support for the
gnome-keyring, the
Mac Keychain, the
KDE kwallet, and
Windows DPAPI (these are all protected-memory APIs.) I am hoping that this sort of tie-in can open up OT to alternative authentication methods such as smartcards and usb tokens (and keep that stuff localized to existing, standard APIs outside of OT.)
The OT
server doesn't store any passwords, since all OT messages are signed. Neither does the client store any, and its private keys are kept in encrypted form on disk. No secret-splitting, yet, but it's coming someday.
All right, that's it for now. Keep an eye open for the new videos, I'll be posting them soon!
-Fellow Traveler
1NtTPVVjDsUfDWybS4BwvHpG2pdS9RnYyQ
