It's a feature, not a bug... Armory inherits all the security properties of Bitcoin-Qt by using it as a gateway to the Bitcoin network.  If I rewrote all that stuff myself, it'd probably be a disaster.  And in the end, since you don't ever need to touch Bitcoin-Qt, you can just minimize it and pretend it isn't there.  Armory is a bit slow to start, but the recent beta release includes insta-load so you can manage your wallets (like importing keys) while it is scanning the blockchain. 

If you're willing to go as far as creating plugins for Bitcoin-Qt to do this, you might as well just use Armory.  It basically is an add-on, and both importing and sweeping are supported.  Only sweeping is supported if you are in "Standard" usermode, with importing being available in "Advanced" and "Expert" (for reasons already described here).  It also has batch-importing/sweeping so you don't have to wait for a rescan between each one.  Not to mention all the other nice benefits of Armory: printable one-time-only-needed backups, multi-wallet interface, simple cold storage with watching-only wallets... </shameless plug>

Armory is based around a suite of C++ tools that are made accessible to Python through SWIG.  Things like scanning the blockchain would be devastatingly slow if it was done in pure python, but are quite efficient in C++.  Armory tries to do as much processing on data as it can in bulk, in the C++ code, so there is minimal opportunity for python to bloat the process. 

However, I made the decision early on to use crypto++ because I didn't really know much about the different crypto suites.  In hindsight, I wish I'd used OpenSSL, because it looks to be about 10x faster than Crypto++ for ECDSA operations.  I wouldn't do full validation with it (maybe only 200-400 ECDSA signature verifications per sec), but it's more than sufficient to deal with all the other operations you need (verifying only transactions relevant to you, signing lots of inputs to create new transactions, etc).

If you clone Armory from github, checkout the extras/sample_armory_code.py which will show you a few ways to access things through pure C++.  However, I recently converted Armory from single-threaded to multi-threaded, so those samples may not be perfect anymore -- they may require slight modification.  Please PM or email if you have any questions.

Ack!  Haven't seen that before!  I assume you are on 64-bit Windows?  I wonder if the 32-bit compiled version doesn't work on 64-bit Windows now, or maybe the installer didn't do everything it was supposed to...?  Can you please try uninstalling it and reinstalling it?  

I can't recompile the Win64 version just yet, because I just caught the dreaded crash in a debugger and I need examine it.  It looks juicy, though!  It thinks there was a blockfile split, and looking for blk0004.dat.   Hopefully this will be a quick fix!  When I'm done, I'll revert the debugging code and compile a Win 64bit version.

If the attacker a single private key and the same key's chaincode, m/i/j/k, he can only determine m/i/j/k/X.  You can't reverse the chain or get to other chains, or even determine "brothers" in the same chain.  You can only traverse down a separate chain specific to that key (which is not ever used in BIP 32 wallets, by default)

The difference in security model between deterministic and non-deterministic wallets is really quite tiny in practice.  There's very few situations where that difference is the results in devastating compromise with a deterministic wallet, that wouldn't also be devastating to a randomized wallet.  And then that is compounded by the fact that there's very few situations where an attacker would get one private key but not the others:  they usually get nothing, or they get everything.  In terms of users revealing private keys from their wallet -- that is a practice that just shouldn't happen.  If they are doing that, then yes, the deterministic wallet is less safe, but the user is exercising poor judgment and likely to compromise themselves other ways (they should be educated about this).

The reason why the security difference is effectively small between a compromise of either system, is because existing Bitcoin-Qt wallet behavior of pregenerating a pool of 100 addresses actually makes the two very similar.  Sure, the Bitcoin-Qt wallet "unsteals" itself after some amount of time, but that time may be very far in the future when the user actually gets through those 100 and starts generating more.  Most of the coin-stealing will occur with the coins already available in the wallet, since there's no guarantee that coins will be added or removed from the wallet in the future to risk losing them if the user spends them.  Perhaps if the attacker knows some information about the user and knows they will be receiving coins in 3 months from now and want to wait for that to occur then the randomized wallet is preferred (for the user)... but then that is effectively a targeted attack, which is expected to be much more difficult to deal with, anyway.

In reality, the biggest risk to the average user is not time-staggered wallet theft, but loss of coins from HDD loss or wallet corruption.  The ability to make a single backup, ever, far outweighs so many other risks faced by regular users.  That's not to say the randomized key model is inferior for all use cases, but the default very clearly should be deterministic one (let knowledgeable users who understand the various factors make the decision to change from the default).

Red Emerald,

Do fresh OSX users need to install xcode?  That's not in the instructions.

And I wonder if there's a way to avoid having the user manually modify their .bashrc.  I guess a short script could just run all of those commands for them...?  Actually couldn't all of this be bundled into a script?

Sorry I'm being picky, I just see a lot of hurdles for non-techie mac users...

I just posted a copy of 0.86-testingversion. 

http://dl.dropbox.com/u/1139081/ArmoryTestingReleases/armory_0.86-beta_windows_testing.msi

Make sure you switch into "Expert" mode, and then there will be a button on the send screen.  It should be self-explanatory

Yes!  I just implemented "Coin Control" in Armory, in version 0.86-beta.  It will let you do exactly that if you are in expert mode!

If you are in Linux or OSX, you can get it right now by switching to the "coincontrol" branch.  If not, you'll have to wait for me to compile Windows versions, but I can do that later tonight.  They won't be official, but since you asked for it, you can help me test it

Ay, third time that bug has been reported in the last 24 hours!  The other users experienced that when sending funds to Armory from Bitcoin-Qt.  I will investigate. 

Also, for future, let's divert bug reports to the discussion thread:  https://bitcointalk.org/index.php?topic=56424

We were just having a discussion about this on the main Armory thread.  I'm investigating right now.  Unfortunately, the new multi-threaded design doesn't handle certain errors right now, and run off into a loop.  But so far, this >10s call to readBlkFileUpdate is the only operation I've seen trigger this bad loop.  Hopefully I'll figure it out soon.

I'll have to defer until tomorrow, but if I had to guess right now,  Is'd say I could simply clone the repo onto a USB drive,  and then create a new signed tag in the clone while plugged into the offline system.  Do a git push <tag> when I get it back to the online system.

How does that sound?  (besides the fact I may not even have git installed on that system... But i can take care of that)

I think losing connection is a symptom, not a cause.  I just put a ton of debug statements in and will start it up and hopefully get a crash in the not-too-distant future.

I think the chain re-org there was a coincidence.  I, too, have observed the occasional crash in Windows with the exact same thing in the log file -- it seems to be exponentially distributed with an average of about 1 day (its happened within 8 hours before, but usually within 4 days).  I can't tell for sure what is causing it, because it happens so infrequently, but the fact that every time it says "BDM currently doing: ReadBlkUpdate" gives me a good idea of where to look.  I have timed readBlkUpdate, and it takes between 200 and 400 microseconds to run, normally.  I'm not sure what could possibly happen to push it above 10s. 

Also, this only appears to happen in Windows.  Let me know if you've seen it on any other OS.  I'll put some debugging stuff into my Windows VM and see if I can catch more info... it seems that 90% of my bug reports have to do with this problem.

Of course, I forgot that git supported that! 

However, my signing key is on my offline computer, I'm going to have to get creative... I'm not sure exactly how to pull that off.  I think I know how...

Just a random update:  I have been experimenting with LevelDB, and it appears there is an excellent compromise upgrade I can make:  it would be to swap out the underlying C++ txMap_ and headerMap_ normally held in RAM using std::map<a,b>, with a disk-based equivalent using LevelDB.  The change looks like it would pretty transparent to all code that leverages the C++ utilities (besides creating an extra directory to store the map data).   If that's the only thing I changed, I think I'd get quite a bit of value out of it (and some downside):

++ RAM usage would drop considerably;  probably from 1.5 GB (proportional to blockchain size) to 200 MB (should be pretty flat)
++ Quite a bit of data would be saved between loads naturally, probably leading to much faster startup times
-- HDD usage would go up quite a bit;  probably from 50 MB (for installed files and wallets), to about 1 GB (proportional to blockchain size)
-- Creates a much more "stateful" Armory, which is a downside;  Since I currently always rescan the chain, every load is a fresh start free from problems from the last load.  No matter what bad state Armory got into before, a restart will fix it (because the initial scan is much more robust than handling all the crazy event sequences that users can induce). 

I suppose, if necessary, I could keep the rescanning (so keep the load time high) and just swap RAM for HDD usage.  But I think rebuilding the maps every time would be quite a bit slower than the current RAM solution (gah, always a trade-off).  On the other hand, the underlying C++ libraries have become much more robust over the months, such that it may not actually be that much effort to produce similar robustness with the saved data.  To be clear: it's not *that big of a deal*, but with this scheme comes extra risks that a user could get "locked out" by a bad state of the saved data and have no clear way to recover (as happens with Bitcoin-Qt when blkindex.dat gets corrupted).

Edit: In fact, the most frustrating (and frequent) bug reports I've received, have been because the one file I keep between loads (mempool.bin, for holding zero-conf tx), would get corrupted and prevent Armory from finishing loading.  I actually built into the latest release a way to detect that loading failed three times in a row, and to just delete it.  Perhaps I'll do the same thing for this data -- delete the disk maps and let Armory rebuild them if there's a problem.

I'm pretty busy the next couple weeks, but I guess I can relax a bit, now that beta finished   
Please let me know if you have tried (and succeeded) testing coin control.  I think it will be worth a full release just for that feature if I didn't break anything else.

Yeah, I think it should be there.  I want there to be a clear path to success for anyone who is determined.  I don't expect all OSX users to type commands into this mysitical black box (terminal) to get some program they've only heard about -- but I want it to be as straightforward as possible -- no missing steps -- for users who are determined to get Armory, but have no experience with this stuff.

It's probably just a transient solution.  I'm sure we'll find a way to bundle it up...eventually.  On that note, here is a message that jim618 (creator of Multibit) sent me after I requested some help.  I apologize in advance for posting a PM in a public thread without permission, but I'm sure he'll forgive me

Do your commands work on a fresh install of OSX without having brew or xcode previously installed?  It looks like they depend on brew being installed already (I had actually installed it in my VM before, which is why it worked).  Just need a reminder of how to get those pre-reqs installed...

Perhaps you could also keep the almost-top post updated with the latest instructions and I'll just link to that from the BitcoinArmory.com page.  They wouldn't have to be updated often (and I'll remind you when they do ).  I just want something to link to from the building-from-source page, and I don't think it makes sense for me to maintain it, if you don't mind doing it yourself.  It also makes sure users are aware that it didn't come directly from me...

Some users still want to exercise some degree of due diligence on the install process for sanity's sake.  Not to mention, they may be using this script to setup an soon-to-be-offline OSX system...

I just need to dig in a bit more to see what it's doing before I can "bless it".  On that note, I just ran your 4-5 commands in my OSX VM ... slow as dirt (I think it's the VM), but it did work.  I'm looking at an Armory wallet and a couple tx in OSX.  I was at least able to get into the paper backup dialog so I could copy down the characters by hand, if necessary.

Very cool!  Thanks for doing this Red Emerald.  You have made it possible for even-mildly-determined users to get access to Armory!  (maybe I'll change the donation address to point to you when OS_MACOSX is detected, for one release cycle )

Do you think it would be [reasonably] possible to create a .dmg with all the dependencies?  Or is it a s***load of code/binaries to bundle?  It sounds like the script that goes and picks up the dependencies from brew is ideal, efficiency-wise, but does leave open subtle attack vectors (poisoning brew modules?).  I don't know ... I really want to support OSX users, but I have so little OSX experience...