Cypherdoc,

I am actually avoiding having anyone move existing keys over to Armory wallets yet.  This is why I haven't explicitly created a bulk-import function for private keys (you can enter them one-by-one through the Import-Address dialog).  Plus, I don't have a good way to pull private key data out of the wallet.dat files, even if I did.  I have a script that gets some keys out of the unencrypted Satoshi wallets, but I don't know if it gets all of them.  I heard sipa has a bitcoin branch that allows you dump your private keys, but I think it requires compiling Bitcoin, which can be even more daunting than compiling Armory :|

For now, I recommend you make a new, offline wallet, and transfer a small amount of funds to one of its addresses.  Make sure it works, and that you can move money in and out of the offline wallet as you'd expect (and that you have a copy of the keys saved somewhere in case Armory/HDD fails).  By the time you're comfortable with that functionality, then I might be better prepared to help with this.  I'm still a little uncomfortable with people putting all their eggs in the Armory basket yet, at least until I get some wider testing done.

Man, this stuff is hard.  I re-enabled some dependencies I had removed, hoping it would help with the shutdown issue.  It didn't.  So I removed them, again.  Sorry!

Ugh.  I don't know how to setup these things to accommodate non-"standard" configs (such as python being in a different place than C:\Python2X).  However, the cryptlib thing should work if you compiled the cryptlib project in MSVS.  You should see, a cryptlib/win32/output/release directory in the cppForSwig directory.  It should be created, and cryptlib.lib will be in there if you compiled that project.

Maybe I really should do binaries.  Leave the compiling to only the people who want to have to develop/modify the project.

Fornit, I just committed the fix for that.  I think I accidentally only commited one of two files impl the windows-close fix.  It should all be there, now.

(EDIT:  I just fixed the swig-vs-swigwin part of the directions on the webpage.  Sounds like both of you got caught by that typo.  Thanks Matoking)

fornit,

I'm glad you were able to get it working and that the build-instructions apparently were sufficient  

The error is actually an extra build-step that is unnecessary for testing purposes.  It uses py2exe to collect everything into a single standalone directory and .exe file.  It involves getting py2exe, pywin32 and finding msvcp90.dll.  But I figured no one would really need it except for me, to build binaries for my first release.

As for closing the app, I don't know why it's so terribly difficult to get qt4reactor to shut down!  I finally got it smooth in Linux, but Windows is still unpleasant.  I'll make an effort to fix that, ASAP.

I hope you enjoy Armory!

P.S. - I just fixed the Armory shutdown issue -- right click and do a git-pull to get fixed version.  At least, it won't freeze, though Python itself sometimes stays open.

It looks like you didn't switch to the "qtdev" branch.  This project was forked from another project of mine (PyBtcEngine) and I forgot to rename the solution files until after I forked qtdev.  Everything is on the qtdev branch.  It will all be merged into master for the alpha release.

I've heard that the Satoshi client is challenging to build.  However, I have thoroughly documented the build-process for Armory and tested it in MSVS 2008 from a fresh install in Win 7 x64.  It did work, no problem.  I request you give it a shot (just follow the directions), and if you hit any snags, feel free to stop.  But I did spend a lot of time on those build-instructions precisely because I know how terrible it can be for others to figure it out.

Thanks to everyone who has donated!  You guys rule.  I already took my girlfriend out for a nice dinner on the donations I've gotten, and she does feel appreciated

Of course, I will not discourage donations, but I do desperately need folks to help test the software.  Besides the caveats already stated, and the zero-conf transactions which should be implemented soon, all major features work.  I'm aware of build-issues on non-Ubuntu-10.04, and working on better cross-distrib support.  Windows works great if you can get through the build instructions without stabbing yourself.  If the Windows instructions really are prohibitive, I might have to distribute a pre-alpha binary, but that makes it difficult to push bug fixes and have testers pull the updates right away. 

Please let me know if there's something holding you back.  And if anyone uses it for main-network with real BTC, please print out a paper backup of your wallet.  The wallets do appear to be very robust, but it's alpha, and whatever money you have will be recoverable with a paper backup under any circumstances

Conspiracy theories aside, it should be noted that no sensitive data touches the USB key, ever.  Not even on the initial wallet setup.  You transfer only a watching-only wallet from the offline computer to the online computer.  And when you spend money, only transaction data is sent back and forth.  The only thing that the offline computer adds to the USB key is a signature, which is going to end up in the blockchain, anyway.

Of course, if the manufacturers of IronKey wanted to do something nasty, they would have access to your entire system, not just what's on the key.  So perhaps it's moot.  But at least, you don't have to worry about someone else getting ahold of a key you used for Armory's offline wallets.  There's nothing they can do with the data being couriered with that device.

I fully believe in the goal of OP_EVAL and BIP_0016, and I believe it is a hard problem to solve safely.  As found with OP_EVAL, enabling a sub-scripting system with recursion in a system that was intentionally not Turing-complete, opens up a can of dragons.  Unfortunately, I've been so focused on Armory development, that I haven't gotten too deep into the discussions on it, so I can't form a valid opinion on any specific proposal.   But I do believe that the goal of these proposals is extremely beneficial to BTC in the long run.  (although, it would be nice to get my client out with the old rules before having to support new ones right away).



I've heard good things about the Ironkey.  For the offline wallet interface, the biggest threat is hidden USB-key viruses, so something with built-in-AV probably helps.  But without some kind of updating mechanism, it's built-in A/V could quickly become outdated and useless against evolving threats.  I think more importantly, having A/V on the online system and disabling any kind of autorun-on-mount capability on the offline system are the most proactive way to avoid these problems. 

But even without that, the offline wallet system is probably the absolute safest way to manage large sums of BTC, despite being fairly complicated.  Yet, I believe Armory has actually made it usable by ordinary users (now I just need to get the system req'ts down to "normal"), and hope others will help me test that part and let me know what they think.  It was one of my prime motivators for starting Armory.

What is a simpler backup solution than printing/copying your wallet once and never having to back it up again?  And the paper backup is even better than USB keys or servers, because you never have to worry about the USB key working when you plug it in a year from now, or a HDD/server failing.  Plus, a sheet of paper is a LOT cheaper and a lot easier to hide, and its integrity is visually verifiable.

Not to mention you can still backup the encrypted version to a server somewhere, but I don't see the necessity of risking something like the 0.4.0 wallet-not-actually-encrypted bug.

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.

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

The two major upgrades between now and beta will be
(1) Reverting to file-based blockchain operations (to bring memory req'ts from 1.5 GB to 100 MB)
(2) Make Armory networking-independent

For the first release, I decided to go through the Satoshi client, so that it will handle all the complicated networking protocols and full-validation of incoming transactions.  By running Armory through Satoshi, I get all that for free!

I will add proxies to my list of features to support in the future!

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.

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.

Okay, we're doing the same thing, then, just with different algorithms.  The only real difference is that, in Armory, the master key is randomly generated, and then the passphrase is passed through a scrypt-like KDF to get the encryption key.  If the user changes their passphrase, then everything is unencrypted and reencrypted with the new KDF-derived encryption key.

In Armory, I don't keep a separate chain for change addresses.  I simply "get next unused address" for change.  And while I had to battle the question of how far out to extend the chain beyond that last seen address, I believe 5 is way too small.  I use 100 which may be too large, but I'd much rather err on the high end than vice versa.  You only need the user to generate a couple addresses that end up not being used, before your wallet will get stuck.  But you do have it as an adjustable parameter, so it's easy enough for you to change if you determine it's a problem.

You can either post here, or send me a PM, the specifics of your deterministic algorithm.  I will consider switching the wallet to that format, as long as there is enough "standardization" around the algorithm -- it sounds like there is, if electrum and BCCAPI are both using it.  Any other clients with deterministic wallets?  I haven't been following other clients too much, because I've been completely consumed getting mine into a releasable state...

SORRY if anyone tried to checkout and compile on Windows.  I updated the MSVS 2005 projects, but forgot to commit-and-push the changes.  D'oh!  I just pushed them to the qtdev branch, so it should go a lot smoother now.  Sorry about that!

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). 

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!

So you are memorizing the salt in addition to your passphrase?

You wrote in your post that you don't need a recovery plan for your deterministic wallet, because it's all in your head.  If you've added salt, it's not really in your head. You will need a backup.