Build instructions have been posted!  (see the bottom of the top/original post)

I'm sure people will still have problems.  But that's why this is the testing phase and not the release phase

I'll move everything into the master branch and create executables, when I do the first official release.  Until then, everything is in the qtdev branch, and being a tester requires compiling. 

Zero-confirmation transactions are so badly botched, I've disabled them, but they can be re-enabled through the menu options.  Just don't be surprised if you see wacky stuff... Anything with 1+ confirmations will be accurate.  My first priority before release is to get rid of the terrible zero-conf hack, and replace it with the "correct" solution.  That's my task for this weekend...

As stated before:  this is pre-alpha.  Do not put any money into this program unless you expect to lose it!  Therefore, Armory defaults to testnet.  If you really want to try it with real money (because you don't feel like waiting for testnet to download), you can run it via "python ArmoryQt.py --mainnet" ...  but I only say that because I know someone will insist on it despite all my warnings/pleadings not to do it!

Luckily, I have made sure I have a separate version number just for wallets, so I can do exactly what you suggest.  Obviously, if I upgraded, old wallets would not be convertable but would still work.  Only new wallets would be transferable, which is fine... (users can upgrade if they want it).

However, I'm not clear what your deterministic algorithm is...?  Do you use the DHSS method that allows you to compute the deterministic addresses without the private keys?  I have been looking at the Electrum website, but didn't see how it is done.   So far I haven't seen anyone else implement the determinism this way, and thus I would have no choice but to use my own method.  Armory is critically dependent on the ability of watching-only wallets to be able to generate the public key chain without needing private keys.

For reference, the algorithm I use is not terribly complicated.  The 32-byte "chaincode" is kept with the wallet (and actually stored with each key in the wallet).  You chain addresses via:


The magic is in the ECC math, so you can continue the chain with public keys only:

The chaincode is simply extra entropy added to the determinism (i.e. salt), but not entirely necessary.  I might revert, in the future, to making the chiancode deterministically generated from the root private key, so that you only need 256 bits (root private key) to recover the wallet, not 512 bits.

Btw, I really like your technique for converting entropy into dictionary words.  That's pretty slick!  I never considered the possibility that a user would try to memorize their keys, or even write it down by hand, but that certainly makes it possible!  (because I will never generate a wallet with less than 256 bits of entropy, that's a lot of write/memorize). 

I use the method described by gmaxwell, that he called "type 2 wallet".
This method allows to generate the public key sequence without the private keys, so I guess it the same as what you describe.
Note that the same method is used in BCCAPI as well.

I use two separate sequences: one for receiving addresses, one for change addresses.
The wallet recovery procedure stops when it finds a sequence of N consecutive unused addresses (default is N=5); during normal operations, the software never allows the user to create gaps larger than N.

By default, the software generates seeds that have 128 bits of entropy. However, this is not strictly enforced; users may use longer seeds.
The master private key is derived from the seed using hash based key stretching.
I do not use the password as salt because I want users to be able to modify their password.

I have updated the bitcoinarmory.com webpage with the build instructions and a short tutorial on offline transactions (but, no screenshots, yet).

http://bitcoinarmory.com/index.php/building-armory-from-source
http://bitcoinarmory.com/index.php/using-offline-wallets-in-armory

As I continue filling out the webpage, I will be moving more and more Armory-related communications to it.

That's a very good question.  I'm not familiar with that aspect of networking (in general) to know how much effort that would take.  Perhaps someone else on the forums can reply to the following naive answer:

Right now, Armory does all of its communication to the Bitcoin network through the Satoshi client.  Perhaps, if you set up the Satoshi client to go through a proxy, then you will get the benefit of having done that in Armory.  This assumes that you can still execute a localhost connection to the Satoshi client while it is using the proxy.

Will that be changed in future releases?
That could leak some info that doesn`t respect for some reason proxychains, such as DNS requests. Also, proxychains is outdated and unmaintained since 2006. I suggest using torsocks instead if you want Tor support without building proxy chains. Anyway, native proxy support is better than third-party soft, and, finally, as you mentioned, that will not work in Win and Mac.

Untrue.

Proxychains actually proxies DNS through its chains ! It also works well with TOR (also tested myself).

This fancy thing even works with advanced apps (GUI apps).

Great!  Build instructions are posted here.

If you're in Windows, you'll need some patience.  Let me know if the build instructions aren't clear enough, or need any corrections!

-Eto

Ctoon,

It'll be a while before Armory will be lite-enough to work on such light-weight hardware.  However, the beauty of the offline transactions technique (based on BIP 0010) would make it feasible to use very inexpensive hardware solely for signing offline transactions (because you don't need the blockchain, you only need to be able to run ECDSA code).  But I don't think I'll be doing that... I just don't have the experience with alternative architectures.

But again, my stuff is open source, BIP 0010 is public, and my wallet files are well-documented.   I bet someone more-suited for the job could make it happen and I'd be happy to help them.  I am excited about the possibility of the offline tx technique to enable super-light-weight, inexpensive, signing devices that could be used for two-factor-authentication-like scheme.  But full Armory might be a stretch.