How much RAM do you have?  If you have sufficient RAM, it should be about 5-10min on Windows, 2-3 min on Linux.  The cases where I've seen it take longer than that is when the user has less than 2GB RAM.  For now, Armory requires that much RAM.  Blame SatoshiDice for growing the network faster than I could get around to fixing this...

Regardless, a fix is coming -- at the expense of duplicating blockchain data on disk.  I have to start maintaining my own blockchain data, but it will mean Armory's RAM usage will drop dramatically, and will also startup instantly after the first load.  Obviously a big improvement... but I don't know how long before I can have it implemented.  Definitely within the next couple months.  Until then, there's not much I can do for you

I'm running 3GB of RAM.  Also I added some other questions to my original post, maybe you can help out?

Thanks for the reply.  I've closed/re-opened Armory and will let it scan again, hopefully it picks up the coins on the second attempt.

With regards to the keys I didn't see any option is Armory to generate X number of keys? 

My goal was to have each order on my website use a different address, so that it's easy to see when an order has been paid.  I did not want to generate the keys on the webserver as this is apparently a security risk.  So instead need to pre-generate all the keys, then each time an order comes in I random assign it to one of the unused addresses.

If i'd have done this in Armory instead of bitaddress, wouldn't I have had to click "Receive Bitcoins" 1000 or so times? and then no easy way to export just a list of the addresses (without keys), for in my case importing into a mysql database.

You're in Armory territory now, and you don't even realize it.  This is exactly where Armory shines, if you are willing to consider a different route than you're taking right now.  I will explain the "correct" way to do this, and if you don't like it, I will tell you how to do it the way you are trying to do it, but I think you'll find your way excessively inconvenient.

The key here is to use  "watching-only wallets" which are copies of a regular Armory wallet that don't have the private keys.  It generates the same infinite chain of addresses as the full wallet, but without the risk of an attacker getting the private keys if they compromise your webserver.  And you can monitor the payments from multiple computers.  It's really got all the convenience and security you can ask for... if you do it the Armory way.

(1) On any computer other than the webserver (preferably offline), create a new Armory wallet.  No need to import any addresses.
(2) After creation print a paper backup!  It's the safest and most convenient way to backup your coins forever.  Digital media can fail, and printing thousands of keys will be a disaster to have to reimport later.
(3) In wallet properties, click "Create watching-only wallet".  (probably use USB key if offline)
(4) Transfer the watching-only wallet to webserver and if the original wallet is offline, also import the watching-only wallet into Armory on your online computer
(5) On the webserver, you can run a very simple script to generate as many addresses as you want, all protected by the paper backup, and without containing any private keys.  Install or download&compile Armory on your webserver, then run this script every time you want a new address (you may have to modify paths appropraitely):


The beauty of this is that the moment someone sends money to any address that your webserver generates, you will see it in Armory on your primary computer (using either watching-only or full wallet).  And if you keep the full wallet offline, you're about as secure as you can get.  If you want to create addresses manually on some occasions outside the webserver, just create a new wallet on your primary computer and use that (or rather, create a second offline wallet and import that one only on your primary computer).  

If you run a webstore, you absolutely should not be using online/web apps to generate addresses.  There's too many ways for that to be compromised, especially when there are tools like Armory available.  There's a JSON-RPC version of Armory (armoryd) available that will make this easier in the future, but it's not completely stable yet (crashes about once a week).  I'll let you know when it is stable if you want it.

---

EDIT: Duh!  If you want to access the Armory address chain through JSON-RPC, armoryd.py will work perfectly stable in offline mode (the instability comes from fighting with Bitcoin-Qt over the blk*.dat files when online).  If you, or anyone else reading, wants to access Armory watching-only wallet addresses using JSON-RPC and don't need network connectivity, I will commit an armoryd.py that works in offline mode, shortly.  It's basically already done, I just need to tweak it and test it.

EDIT 2:  So apparently it already works.  You just need to checkout the "testing" branch from the github repo.  On your webserver from the checkout directory:
Then setup your JSON-RPC process to use the username and password inhome/user/.armory/armoryd.conf (the file should have one line, "username:password").  
Then you simply keep sending "getnewaddress" commands and you'll be receiving new addresses every time.

I don't have root access to the webserver, site is just on a shared environment.  So can't install armory on the webserver (it's basically over my head at this point).

I'm still having trouble with my original issue.  I re-opened armory it scanned again, and still showing 0 balance, even though the transaction is now at 120 confirmations.

When I open the armory wallet the address is listed, but says "0" transactions and "..." balance?

And for the brainwallet suggestion, if I generate a whole bunch of addresses (say a 1000) using my Paper Backup key, will I need to import these addresses into my wallet or will they automatically appear in there once funds are sent to the address?

P.S.  Just re-opened and scanned Armory a 3rd time and still no sign of the missing bitcoins.

Not exactly true.  He could do a hybrid where he runs the script to get the addresses to import into his SQL table, but still have all the benefits of a deterministic wallet.

However as you said... if he is having trouble with Armory running to get the funds out then perhaps it is not the best way.

Is there a python script like the one you posted for backing up/extracting the private keys as well?  I always like to make sure that I can get access to the private keys in the event that a client goes belly up or simply does not work for some reason.  Right now the only way I know of is to either backup individual keys (which requires forethought) or using brainwallets chaincode feature.

Thanks for the tips etotheipi.

I took your base script and hacked together this:

The public address part works like a champ; however when I specify the correct password I segfault with:

If I specify a bad password then the verify catches it, does not segfault, and exits.

Given that 'Actual Armory' can unlock and export the wallet I am assuming that this is an issue of 1) me nothing knowing enough python, or 2) me not knowing understanding the ArmoryEngine well enough.

I know you are busy, but if you could even give me pointers that would be great.  (yes i pointed it at my FULL (not watch only) wallet).

I had saw the function def; however it was a case of not knowing enough python (just enough to get into trouble).

However I am now running into the problem of converting it from a binary string into a base58 string.

I found the section of code where it outputs in the GUI, here; however despite having the "from armoryengine import *" line, I get the following error:

I can find the definition in armoryengine.py, but I am not sure why it is not importing into the namespace?  (Full script listing here.

Thanks for hand holding stupid noob python questions.

Quite right.  I am on OSX so I leave the voodoo of making Armory work up to Red Emerald and the brew formula isn't updated for 0.87 yet.   I had thought that I checked my actual installed Armory code; however I must have been looking at my HEAD checkout, sorry about that.

I have pushed my script changes to github.  For anyone who is interested the (very rough) script can:

• Dump all 'created' public address
• Generate new public addresses
• Dump imported pub/priv keys
• Dump generated pub/priv keys

Right now is outputs in pseudo-csv format. I say pseduo because Armory logs to stdout so you have to do some 'magic' to get a plain CSV file:

You can access the script here: https://github.com/ErebusBat/BitcoinArmory/blob/master/extras/export_keys.py with the same license as Armory.

Question:  I didn't use a test wallet for this and now my chain is extended by several hundred addresses.  Is there a (quick) way I can reset the highest address count back to something sane?  EDIT: nm, found wallet.rewindHighestIndex

Second question:  I appear to be getting differing results for the .chainIndex value, is that to be expected?  See below for an example of tailing output of a dump of the public keys, then a call to new which produces an index almost -100 behind.

EDIT 2: nm again... looks like i was using lastComputedChainIndex rather than highestUsedChainIndex.  Out of curiosity, what is the difference?

Today I tried to send btc. Had a hard time remembering the passphrase and that got me into a little bit of trouble

I was using an old version at that point, something like 0.7x, those that would give you the "loading blockchain info" splash screen still. So I start a transaction, put in the address, the amount, click send, confirm and here it asks for my passphrase. Here I wrote a wrong one and it froze armory. I killed it then restarted, tried again, same thing.

I then updated to 0.87 beta. I start it, let it read the block chain, procede to send coins, write in a wrong passphrase and it freezes on me again.

Round 3, start armory, let it load the chain, go to the wallet menu by double clicking on it and attempt the change the passphrase. Write in the wrong one, freeze.

Round 4, start armory, attempt the change passphrase before the block chain is loaded, write in the wrong one, long wait, then tells me the passphrase is wrong. Keep trying to change the passphrase until it finishes loading the chain. At that point I attempt the change the passphrase, expecting a crash, but it doesn't, and I manage to "brute force" through my passphrase and send my btc.