Funny you ask -- I just added a feature for doing this in the latest version (0.84.5)!

If you install the latest version, run Armory, then switch to "Expert" usermode, your wallet properties will have a new button allowing you to generate more addresses.  You can have it generate 10,000 addresses (though it might take a few minutes).  Once they are created, you can go into "Backup Individual Keys" and export just the private keys.  Now, I don't know how you intend to read them, but they may not be in the best format for importing into another application.   If you really need them formatted another way, I can create a very short python script for you to export them however you want (or if you are capable of it yourself, I can tell you exactly how to read the wallet files and pull private keys out of it (using armoryengine.py).

EDIT - Sorry, running the script yourself will be difficult unless you are on a Linux-based system.  It is rather difficult to get it all setup in Windows.  Let me know if the GUI interface is not sufficient and we'll figure something out

I just added the "Ubuntu 10.04 Offline Bundle" to the "Get Armory" page.  Or here's the direct link:

Armory 0.84.5-alpha offline bundle for Ubuntu 10.04 32bit and
Detached GPG signature for offline bundle.

It should be exactly everything you to install and run offline Armory on the first boot of a fresh Ubuntu 10.04 32-bit installation.  I have tested this with a fresh VM, but I do need others to try it to make sure that I didn't "cheat" by accident while testing it

---

P.S. - I just realized that the webpage (and the links above) suggest that they only way to have an offline computer is through Ubuntu 10.04 32-bit.  I should clarify that any offline system running Armory without an internet connection is an "offline system," and as long as Armory runs, it will serve its purpose.  This means that you can use a Windows machine and just copy the installer over there, detach it from the internet, and you're good to go.  The only reason why there's a special bundle for Linux is because Armory requires some dependencies to be installed -- which are downloaded and installed automatically when Armory is installed -- but those dependencies are not accessible if you do a fresh offline-installation of Linux without it ever touching the internet.

So, don't think that you need any special version of Armory to run offline.  The bundle only helps you get it setup on an Ubuntu machine that started offline and can't get the dependencies.  Without it, if you install Ubuntu, you might want to put it online long enough to install Armory and its dependencies, then detach the network cable... but it's clearly much better if you can do a fresh Ubuntu installation without ever touching the internet, even at the start.  

I'm actually out of town right now and can't update the webpage yet.  So I wanted to clarify this for users before then.

What OS?   What version?  There's a ArmorySettings.txt file and mempool.bin file in the home directory.  Delete both.   Or if you can open it in Offline mode,  Help-> Revert all Settings (does the same thing without digging into directories)

If it continues to keep crashing then please email me a copy of the log file.

Oh, I guess I missed some polishing... "Private Key" options are supposed to be disabled for watching-only wallets.  Private keys are always displayed with a 4-byte checksum after them, so it's easy for the system reading it to recognize if it was copied correctly.  In this case, since the wallet doesn't have private keys, it's showing you a zero-byte private key (i.e. nothing) with a four-byte checksum after it (checksum of an empty string).  That's why it's the same few characters for all private keys on that screen -- they're all the same empty string.   Don't worry, there's no private key data in the wallet to be leaked

If you're really interested, I documented the wallet format:  http://bitcoinarmory.com/index.php/armory-wallet-files.  You can use it to manually check your watching-only wallet file... you can dig through the binary and verify that the private-key fields are really empty.

I'll add that to my list of things to polish for the official beta release.

Unfortunately, my Mac-fu is really weak.  Before a 2 months ago, I had never even seen what OSX looks like.  After doing some research, I determined that creating an official package is a lot of work, and probably a bit of money (for the code-signing key). 

However, I have received some tips from others, about creating .dmg/.app bundles.  The problem is the dependencies -- I might have to do something creative to make it work as a standalone application without the users installing a bunch of stuff.  On the other hand, RedEmerald's instructions involving brew have been good enough that it worked on my first try when I finally got a 10.7.4 OSX VM running (it does download and install all the dependencies, which is why it's not terribly difficult).  There's more here in case you want to try it.

On the other hand, maybe Red Emerald would like to respond here with his latest walk-thru, to make sure that those users who want to try it, can see it.  While I've had reasonably good response to people compiling in OSX, I have personally tested it very little there.  Again, maybe RE would comment on its limitations (if any) compared to the Windows/Linux.

I'm sure most of you have at least heard of Armory by now.  Many folks donated to the Armory call for crowdfunding back in March.  And many other folks claimed they would try it when it was no longer alpha.   And even while it has been alpha,  Armory has been getting about 1,500 downloads per month!  

Well, after 8 months and probably another 1,000 hours of development, I believe that Armory is about ready for its official Beta release!  

However, I want to release the latest release candidate to a smaller crowd of people, before doing it officially -- Armory now has so many features, that no level of personal testing is sufficient for such a major release.  I just need people to get out there and use it!  If you've always wanted to try it, then please use it and give me feedback!


Get Armory version 0.84.5-almost-beta
(there's a very good chance that this will be the final beta release)



For those who like to compile their own, you can check it out from the github repo:  "git clone git://github.com/etotheipi/BitcoinArmory.git" and the switch to the threading branch "git checkout threading".  It will be merged into master when the release is official.  (more detailed instructions at the Building Armory from Source page)

---

What's new since crowdfunding phase?   (Answer: everything)

• Armory now works on 32-bit and 64-bit Windows and Linux (Mac/OSX users have been successful at compiling it themselves, but I have failed at packaging it properly; there are links on the "Get Armory" page linked above)
• Installers with uninstallers for both Windows and Linux
• Bulk address importing/sweeping
• Multi-threaded blockchain scanning so you can still user Armory while it is scanning.
• System tray icon, with notifications!
• Full "bitcoin:" URL handling in both Windows and Linux (and a place to enter the URL manually if clicking the links don't work for some reason)
• Create clickable payment requests to be copied into emails or wepages.
• GPG-signed installers for using the Armory Signing Key (the first link on that page)
• Export your transaction histories
• Minimize to system tray
• Manually pecify change address for each transaction (expert usermode only)
• Version checking and notification
• Endless polishing (table sorting, formatting, preferences, filtering, warning windows, action verification checks, tooltips/mouseover text on everything, etc)

And of course, that is only what is new to Armory!  Don't forget that Armory gives you:

• Painless offline wallets (cold storage)
• Multiple-wallet interface
• GPU-resistant wallet encryption
• Deterministic wallets
• Only-one-time-needed-ever backups!  Print one off when you create the wallet, protect it forever!
• Watching-only wallets
• Key importing and sweeping
• Message signing
• And lots more I can't even remember!

If you haven't tried Armory in a while, it probably looks completely different.

Remaining issues (what you can expect):

• Still requires Bitcoin-Qt to be running.  But I made a page explaining why
• Still long load times, but at least Armory is running while it is loading
• RAM usage is dramatically reduced from the original, full-blockchain-in-RAM implementation.  But SatoshiDice has bloated the blockchain so much, that even my indexing scheme consumes a lot of RAM (>=1.0GB).  After Beta, I will be switching to having Armory manage its own blockchain data using LevelDB, which will trade RAM consumption for HDD consumption.  However, I wanted beta to be a stable release with the current HDD-lite architecture.  (a lot of power users have a lot of RAM and like the small HDD footprint)
• Windows 32-bit still sometimes has issues.  Until the upgrade mentioned above, Win32 users may not have a pleasant ride.
• Some crashes may still exist under combinations of events.  If you experience this, please send me a log file
• Compressed public keys not supported.

P.S. - In case anyone is wondering:  There have only been two reports, ever, of users losing money with Armory.  Both cases were due to users side-stepping Armory's built-in protections -- they manually deleted files in the application directory -- and both would've been prevented if they had made paper backups! (a digital backup would've been fine, too)  

Make a paper backup of your wallet and keep it safe!  Only one backup is necessary to protect all private keys, forever! (except private keys, back those up separately).   Even if you later decide you don't like Armory, you can use the "Backup Individual Keys" dialog to export all private keys to be imported into another application or service.

My point was not that you should use it, for fun, but because using it might make the "what if offline tx uses change address 1e7?" problem a bit easier.  The online computer could hand out millions of addresses on the external chain, but the number of addresses used on the internal chain will be strictly limited.

However, if the private keys are distributed across multiple devices, it's not quite so simple...

Is the save dialog problem on the offline computer?  I just did it online with the update and it works (created unsigned, saved, next window, loaded, signed, broadcast).  What OS are you in?

I shouldn't have said "malicious."  This was all timed with a hard system crash.  Yes, large chunks of code went missing in a conveniently-transparent way, but if it was malicious, they wouldn't be doing it just to waste my time bug hunting.  I will instead attribute this to vim + hard crash...  I've lost code before with vim (like, two other times in 10 years), but git makes it easy to recover.

I will go back into testing mode, and start testing send-transactions, offline tx, etc.  Though, I might not get to it until tomorrow...

Sorry for the trouble!  Getting there...

Okay, something is definitely not right.  At all.  There are parts of my source files missing.  This happened before ... a chunk of wallet code disappeared was causing my wallets to break.   I assumed I had done something stupid in vim, but now looking at qtdialogs.py, there seem to be other things missing.

This all happened after a hard crash happened two days ago.  I wonder if it somehow corrupted some files...

I'll be investigating...


EDIT:  Thank god for git.  Showed me exactly what disappeared (two things, one of which was that "createTxAndBroadcast" function), and I was able to copy it right back in.  The bizarre thing is, it almost looks malicious -- not only did it destroy functionality, but everything that has disappeared still ran and "compiled".  The code was continuous and valid... just not correct.

I will investigate further, but for now I recommitted to 0.84.4 all those updates.

Major bug fix!:  Windows 32-bit installers were not compiled with multi-threading support!!!   It was 1-2 months between when I figured out how to enable multi-threading, and the next time I fired up my Win32 dev environment.  I thought my VM was just behaving wacky when it didn't work, but it was a real problem!

This also means that if you were a good samaritan and actually installed the 32-bit version on your 64-bit Windows system, then you probably didn't get to experience the months of multi-threading upgrades. 

Below is the Windows 32-bit installer for 0.84.4 which also has all the other bug fixes I mentioned before. 

Armory 0.84.4-almost-beta .msi installer for Windows (32-bit and 64-bit)

This has all the major bug fixes of the last 24 hours.  Windows users, please test it!

That's quite a relief!  I caught two big bugs today.   It looked like there might still be the occasional crash, but I have to give in some time and just release it.  It can't be perfect...

I have mostly only polishing left for beta, no major features.  Though, all this seg faulting and issues with file-reading has encouraged me to bump up the priority on making Armory maintain its own blockchain files.  This would not only solve a great many instabilities related to sharing the blkXXXX.dat files with Bitcoin-Qt, but it would load faster, use less RAM (it will be HDD-heavy instead of RAM-heavy), and allow users to connect to any trusted full node not necessarily localhost.  But it means blockchain data would be duplicated on the HDD.

I think I'll stick to my plan to do the new wallets first.  There's too many benefits of the new wallet format, like finally supporting compressed public keys (and migrating Bitcoin-Qt wallets), encrypted-backupable comment/label files, and multi-sig preparation (won't be implemented just yet, but I need the new wallet format to support P2SH).  Plus, some users have expressed pleasure that Armory is so lightweight in terms of HDD space, so I think it's a good idea to lock in the current stable design, and change around the CONOPs (concept of operations) later.

I'll do a semi-official release in the next day or two, and get some more users clicking on it.  Perhaps within a week of feedback I can officially tag it Beta.  Once again, please let me know about any issues/polishing, or any minor feature requests.

Anyone running from the git repo, please pull the threading branch and try again.

I feel like I've been going in circles, but I'm think I'm better off than a week ago.  I re-enabled most operations during scanning, and so far they work most of the time without crashing.  Wallet recovery, sweeping, importing, keypool extension, should all be queued up for execution when Armory is currently scanning. 

I haven't built any installers yet, but I was pleasantly surprised with how many people are running from the git repo... so maybe that's enough.

@Red Emerald:  there was a wallet recovery bug I introduced somehow... I don't know how long it's been there but it's definitely fixed, now.  Can you please re-restore the wallet you were having issues with? 

Well here's an idea:  can the device at least store how many times it's ever created signatures?  Or something else that is at >=1 for each transaction it ever deals with?

Here's what I'm getting at:  BIP 32 allows for random access to any address, but it also specifies using a separate subchain for change addresses (the "internal" subchain).  This may have been overlooked by you early on for simplicity reasons, but it is part of the spec.   The idea is that change addresses will only ever come from this the internal chain, and that chain will never receive coins from any other source except the "external" chain (the main chain that is used for distributing payment addresses). 

The relevance is that the "internal" chain is very dense.  There will not be any gaps in the internal chain.  In fact, the highest index ever used in this chain should be about equal to the number of transactions ever signed by the device.   Therefore, if you implement both roots on the device, the device can safely declare that "a change address with an index higher than the number of transactions I've ever signed is invalid." 

Oh, I missed that part.  I forgot that BIP 32 doesn't require computing addresses in order (Armory current wallets do require computing in the chain, but that has turned out to be more of a curse than a blessing, but would be useful here).  But I see your point, now.   And the suggestion about storing an index on the device and or displaying it for the user, makes more sense, now.

I'll think about that one...

I don't understand the risk.  The desktop computer is perfectly capable of creating a new address in the same deterministic wallet, and telling the device what the address index is so that it can recognize it.  The user doesn't even have to know it's there, as long as the device is doing its job to verify ownership of the address. 

(1) If the device doesn't recognize the second address, the user must confirm the extra output, which will look suspicious.
(2) If the device does recognize it, then the user only confirms the original output they were expecting to see

There's the non-zero benefit of:  ECDSA is secure right now... but if it wasn't, using new addresses still keeps your coins secure because your private key can't be broken if your public key isn't even known.  i.e. -- if you send back to an address that has its public key already in the blockchain, then in the far future if ECDSA is broken and/or quantum computers start becoming a reality, then you are vulnerable.

And of course -- the privacy aspect is improved. As you said, privacy is not guaranteed when using new addresses, but it's also not as bad as just reusing old ones.

I really don't think you're getting any value out of this.  The device can internally confirm that the change address belongs to your own wallet, and asking for user confirmation doesn't add any security -- but it does create confusion.  Even if users know what they're doing, they may accidentally confirm through a malicious change address because they are always asked to confirm two addresses when they send a tx with one target. 

I'd prefer, instead, that the second address only comes up when it is not part of their wallet.  If the user created the tx to go to 2 people, they'll expect to confirm twice, etc.  If they are asked for 3 confirmations, they'll immediately recognize something isn't right.  

It really depends on the target audience.  You and I are intimately aware of how Bitcoin works, under-the-hood, but non-techies think of their own wallet as a single number -- their balance.  They don't understand what "unspent outpoints" are, and why there is change, etc.  To them, they send 20 BTC to one address, they expect to see 20 BTC go to one address and their balance reduced by that much.  Forcing them to understand more than that is... a judgment call.

I've gotten lots of questions about "change addresses", and why it looks like users are sending coins to multiple people.  I tried to make it clear in the Armory tx display, but they don't always catch on.  For that reason, the "Standard" usermode in Armory tries to avoid making any mention of "change," for fear of confusing the user.

On the other hand, your device is not for absolute newbies (although many would argue that Armory isn't, either ).  I'm sure most of your users would understand what change is.  But I'm not sure displaying the change would make a difference -- even if they see it and understand it, they aren't going to know for sure that the displayed address is part of their own wallet.  The device verifying its own address is the roadblock to a malicious attack, not the user confirming it.

In fact, what will happen if the first 100 tx, the user sees the change output and confirms it.  On tx 101, the second addr pops up but isn't actually change (because it was maliciously replaced).  Is the user going to notice this is different?  Or just hit the "confirm" button twice like he always does because he's always confirming two outputs? 

Even without multi-sig, some people include a large number of outputs.   Many times, because it's inconvenient to actually execute an offline transaction, they may pool together many different outgoing transactions into a single transaction.  I know Armory users do this (I do it myself, sometimes), but usually because my offline computer needs to be booted in order to execute the tx and I'm just lazy   But for this reason, you probably need the device to be able to scroll so that it can display an arbitrary number of outputs.   I even have it on my own TODO list, to put Armory's confirmation list onto a scroll area to accommodate the rare times users specify two dozen outputs... (but I haven't had anyone complain yet, so I guess it's not common to do that many).

Something else that you need to accommodate:  since the device can't recognize its own addresses, it can't recognize its own change address.  Therefore, your protocol needs some way to tell the device which output is change -- perhaps specify the address index so that it can check that the marked change address truly is in your wallet.  Without it, the device doesn't know which is which, and even if the user understands how transactions and change work, a compromised desktop computer could swap the change address and the user wouldn't realize it's malicious.