This capability is being built into the new wallet format.  Not by default, but I have designed the format in such a way that any entry can be encrypted, only identified by the Hash160 of a "root" key (root keys are never used, and thus unlinkable to any other addresses).

I really like the idea, except that it requires root access to do it (because, if you R/W raw volumes, you can access any files on your harddrive, even ones that you don't have permission to access).  That complicates Armory a bit, which shouldn't run with root priveleges, but there are environments where that is acceptable.  I'll have to think about that one.

I wouldn't recommend doing this, even if you could (running the same wallet in both Bitcoin-Qt and another application at the same time), but there is so much demand, I will be making it possible with the new wallets coming up... soon?  Hopefully soon...

Therefore, even when you can import them, unless you switch over to Armory completely, I recommend you just create a new Armory wallet and send funds to it.  Especially because Armory wallets can be backed up with four-lines of data -- your Satoshi wallet will require one line of information for each address, and then you'll additionally have to backup the Armory wallet, anyway.

If you can figure out how to boot off the Ubuntu CD, then everything else should be a cinch.  You select all the default options for the Ubuntu installation except choosing a username, password, and computer name.  It will probably take 20 min to install Ubuntu and then ask you to reboot.  Once it's done, put the Armory offline bundle onto a USB key and copy it to your home directory or desktop on the offline computer.  You can unzip it by right clicking and selecting "Extract Here...", or something like that.  Once it's extracted, double click "Install_All.sh" and "Run in Terminal" when it asks.  You'll have to type your password.

That should be it!  You'll find Armory in the Applications menu under "Internet".  You can drag it from the menu to the top panel to make it easier to get to.  For extra credit, I'm sure someone here can explain how to auto-start it on boot...

But!  There is one major downside to an EeePC:  they usually don't have CD/DVD drives.  If yours doesn't I recommend you download the Ubuntu install disk (*.iso) from a Windows machine, and use unetbootin to install the ISO onto the USB key.  You can't just copy it, because it needs to be bootable.  I have not had good luck making bootable USB drives from Linux, which is why I recommend Windows+unetbootin.

If the system won't boot from the USB key, you'll need to go to the BIOS and make USB bootable.  You might as well force-disable the Wifi and Bluetooth while you're there.  The Wifi/Bluetooth options don't always exist, but the option for booting from USB key must exist if the system doesn't have a CD/DVD drive (otherwise there'd be no way to boot anything!).

Let me know if you have any problems.  Now that I mention it, I should probably add this info to the webpage.

What OS?  I'm wondering if Ubuntu 10.04-32bit even works on such low-spec systems...

Out of curiosity, how much RAM does that thing have?  And what OS are you running?  I have been advertising 256 MB as a "minimum" but it was really an arbitrary number intended to convey "just about anything will work."  However, a 500 MHz CPU sounds ancient, perhaps older than I was expecting to be usable!

I've seen that mentioned a few times... it seems that the python-parallel package is in the Ubuntu repos, and the cables are not necessarily expensive.  Is there an equivalent way to hook up two systems?  i.e. the equivalent of the two USB-port adapters and a null-modem adapter.  I am assuming this would not be overly expensive...

I wanted to iron out the base idea first, then later figure out how to make sure udev doesn't get in the way (or set it up to help out instead of destroying all my hard work)

I know, that's why I posted, a few responses back more ideas for executing serial connections.  I already have two USB-serial cables and a null-modem connector and have been playing with them.  What I was hoping was to brainstorm on any possible, remaining attack surface exposed by it.  The getty's are a "hidden" snafu in the whole process, but easily disabled.  I am searching for more experience with this... since serial ports used to be "the cool thing", I'm sure there's tons of auto-enable subsystems that try to make your life easier by detecting and doing something when the serial device is plugged in. 

Hence why I liked the pure-software solution of destroying the usual device/file that is used for serial communications, and remaking it somewhere that no other subsystem can find it or use it.  This would seem to resolve any remaining "unknowns".

Unfortunately, the USB-serial cables are not cheap, but they're not ludicrously expensive, either if you are protecting a lot of money.  Maybe 2 * $20 plus a $2 null-modem connector.  In the long-run, it's actually a very reasonable solution for serious bitcoiners...

Can you email me the log file?  I doubt I'll see anything in there, but you never know...  (etotheipi gmail com)

Unfortunately, I don't have anything else to suggest other than re-synchronizing your blockchain from scratch.  Usually mid-scan crashes have to do with a corrupted blockchain file... though that wouldn't explain why both of them crash.

How much RAM does your system have?  Is this Windows or Linux? 

I suspect this is more resource-usage issues.  I keep saying it -- I'm going to be upgrading the blockchain stuff soon to "fix this".  Unfortunately, I'm in the middle of another important (major) upgrade, so I wanted to finish that first... but the system usage is my number one priority after that! 

This is mostly directed at Red Emerald since he has compiled this many times before, but of course anyone can answer:

For the auto-bitcoind-management, I need OSX versions of bitcoind to be compiled and distributed with the download from www.bitcoin.org.  Gavin said that he doesn't do this because there's no clear path to do it, and there's no demand -- except from me.  He would probably be persuaded if I gave him a working build script for it that does exactly what he wants, but hell if I know how to do that.

He says it's not straightforward, because bitcoind is a terminal app, which means putting it in a .app package is not good, and would have to be distributed as a separate package which is extra work for him.  He would create a standalone bitcoind, but it would require all the dependencies to be static-compiled in, which he also says will be a lot of work.  If that was done, I don't know if it could be bundled along with the Bitcoin-Qt .app file.  If we could have a standalone-static-compile-everything bitcoind that would fit into his existing makefile and simply bundle it along with the Bitcoin-Qt .app, that would be absolutely ideal.  I bet he'd be willing to do it -- perhaps 30 minutes of reviewing the makefile, and that's it.  This assumes that it works, and every failed attempt is more "favors" spent ... I'm sure Gavin wouldn't mind spending a few minutes supporting this, but not more than a few minutes...

Any ideas for how to go about this?  How about a static-compiled version of it that doesn't have any dependencies?  I could float a separate .app package by him, but I doubt he wants to add that to his build/release process which is probably annoyingly long already (I know from experience).

The hashes in that file are SHA256 hashes of the files, not SHA1.  That's why there was a difference.  There was not a great reason for picking SHA256 over the default, other than it seemed appropriate for Bitcoin which is reliant on SHA256.

But now that you mention it, I realize that the googledownload page gives the SHA1 hash.  Maybe I should switch back...  sorry for the confusion!

No need to fear -- I've never seen Armory lose coins.  This is usually just a result of Armory not having the full Bitcoin history available to confirm your balance.  

What does the bottom-right corner of Armory say?  It should say something like "Connected (225937 blocks)".  Usually when coins don't appear, it's because that number is far lower.  This usually indicates that Bitcoin-Qt is not fully synchronized and Armory should not have been started, yet.  There's a few other reasons it can happen, but I'll wait to find out more information.

Luckily, I just started debugging the auto-bitcoind-management code, and at least it works in Linux.  But a ton of polishing to do on it, and then gotta get it working in Windows, too.  When this is done (hopefully in the next few weeks), there will be no more issues with synchronizing Bitcoin-Qt ... Armory will run it in the background, and only connect to it when it detects it is synchronized (enough).  

Unfortunately, that's not something that I can really support with my current set of critical priorities.  But, Litecoin is at least close enough to Bitcoin, that you might only have to change a few constants, and maybe re-write a few functions to make it work.  Bitcoin-Qt (Litecoin-Qt?) is still doing the majority of the work, so Armory probably doesn't need to change too much except to point to the right port.

If someone tries it out, they're welcome to ask questions when they hit snags, but I can't see myself supporting an official version in the near future (it's enough trouble to do regular Bitcoin releases).

There have been some complaints about fitting some Armory windows into the small screen of a netbook.  I had made a bit of progress fixing that, and now windows remember their sizes.  I still occasionally get some gripes about it, but no one complaining that they can't use it.  I wouldn't worry about it.

Also, offline Armory has virtually no resource requirements.  Your offline computer only needs to be able to install/run an operating system, and one that runs Armory (which is any Windows, most Linux, and not so much OSX, but that will be fixed soon). 

You can get some more, general information from the Armory Quick Start Guide.

By the way, I never answered this question.  I have a section about this in my FAQ:

http://bitcoinarmory.com/frequently-asked-questions/

It's about halfway down... I'll try to put anchors in the page, so it will be easier to link directly to a given question.

The FAQ page needs a lot of improvement (both in organization and content).  Please let me know if you have specific recommendations for it.  Or if you're familiar with WordPress, tell me how to create collapsable sections, so that each question can be a section and the user clicks on it to expand it.

Mike,

I can't tell if you misunderstood/didn't-read the UBC thread, or if you have understood it, picked it apart, and 12 steps ahead of me in considering the dynamics of it (and decided you don't like it).  I'll assume the former...

No one has to use it.  I don't think "integrate with lightweight clients" is a goal for the developer here, other than integrating it somewhere to demonstrate its benefits.  With the addition of subtree-sums in the data structure, it appears to solve even more problems than I originally posted.

I continue to be hounded by Armory users complaining of how long it takes to rescan the blockchain when they restore their wallet, or import a key.  I could ask another node for that information ... but there's no guarantee they tell me the truth, or that they even have the information.  So, I am at a trade-off between downloading some non-negligible part of the blockchain myself, just to make sure I know how to spend my coins, or accept the risk of other nodes playing game with me just so I can make a "simple" client.  And the users are making the same decision when deciding which client to use. 

But with this, there is no trade-off.  The simple client only needs the headers, and then about 2 kB/address to get a fully verifiable, spendable balance directly linked to the chain with the most work.  If the program saves the headers, it could save nothing else between loads, and redownload its own balance information every time for less than 1MB and without sacrificing security.  It would frequently be much less data than downloading hundreds of blocks since my device was last running, and more secure than trusting that nodes are filtering properly for me.  There is no more "rescanning" the blockchain.  No "searching" for your UTXOs.  You just get them, and it's easy for any to prove inclusion or exclusion of existing or non-existent UTXOs at any block.

In essence, forcing full nodes to maintain this "service" isn't just an upgrade, it changes the network in a positive way.  It means SPV doesn't even really exist anymore, you just have miners and you have secure-non-full-nodes that can run on just about any device.

Unfortunately, it's an unavoidable feature of the way the network works.  You can think of every transaction as creating a bill (like a $20 bill), but exactly the size of the transaction.  You can't just send part of a bill, you have to use the whole thing at once.  That means you are always sending too much, you send the remainder yourself as "change" (which becomes a new bill in your wallet).   There is just no way around it, and every Bitcoin client/program has to do that.  If you look at transaction lists on blockchain.info, you'll see there's almost always 2+ outputs for each transaction.  They are randomized order, but you can usually tell which one is which, because it'll be like 9.5 BTC to address A, 2.93827112 to address B... B is clearly the change address from a really awkward-sized input.

However, if you are interested in being ultra-controlling of the software, you can switch Armory into "Expert" usermode, and you can use "Coin Control" when you send a tx to select which coins should be used for your transaction.  You can select a subset of addresses you own, and then click "MAX" for the value to send to the recipient and it will construct a perfectly-sized transaction that will have no change output.  The problem is transactions with other people are not so variable that you just send them whatever amount is "convenient" for the bills in your wallet.  For sending between your own wallets, it makes sense.  For transacting with others, there will almost always be a change address.

Perhaps, I shouldn't have said "just works".   But I did say I would be the final arbitrator, and what he gave me was fully satisfactory.  The fact that it "worked" was the final test.  Any further polishing or adaptation to my workflow will be handled by me.