Oh, strange.  It should've popped up a window where it asks you how to open it.  You should select "Run in terminal."  Maybe I should rename that script to "Install_dbl_click_run_in_terminal.sh".

People lose coins because they get creative or they don't understand the system.  There's a very good reason we set it up the way we do.  And using the default behaviors of these clients will not result in coin loss, by design (though, I suppose bugs could still happen).

If you printed out a paper backup of your Armory wallet, it's good forever.  The piece of paper will let you generate any number of addresses (13 trillion if you wnat, but really almost-infinite).  Whenever you receive coins, Armory generates the next address in the chain for you.  When it needs to send change to itself, it generates the next address.  So you receive coins to address 1,000, then you click "Recieve Bitcoins" again, and you end up with address 1,001... then you send money which generates change, which is sent to 1,002, then you hit "Receive Bitcoins" again and you get 1,003.  It's all protected by your paper backup... forever.

The only thing that isn't protected by it is imported addresses.  And people lose coins because they think the default behavior should be for change to get sent back to the same address.  But that's a privacy SNAFU.  Every person you ever transact with can see your entire history, including your entire account balance.  For instance, if you have $1,019,032 in Bitcoins... every person you ever transact with knows that you have $1,019,032.  Not only that, but now they can watch you... if they see it jump to $10mil, they hire a hitman to take you out and take your coins.  I wouldn't want everyone I talk to to know the balances of all my bank accounts...

There's an Offline wallet tutorial which will soon be replaced with a illustrated tutorial (with screenshots).  You can think of it as:  your "watching-only wallet" is identical to a regular, the only difference is there's an "extra step" that has to be completed when you hit the "Send" button (it doesn't send right away, it will save a file to your USB key which you get signed by the offline computer and then bring it back and hit "Broadcast").

I'd love to support Android devices, but I don't have a secure file transfer mechanism for them.  The only way to really transfer data to it is through plugging it in via USB, but then it's filesystem becomes accessible to the online computer, which kind of defeats the purpose.  However, I will implement multi-sig, allowing you to link computer and phone -- then the computer simply emails/texts/QR-codes a half-signed transaction to the phone, the phone signs and broadcasts (after verification).  

Seriously, I would love to support Android offline signing devices, I just don't have a good way to it.  This is what this thread was about and one reason I really liked the audio-transfer solution ... it's just that it's too slow, and likely to destroy some hardware

Have fun explaining change addresses to granny.  And reminding her to take note of how much change was created, so she can manually update her documentation to make sure she knows how much each key has.

Also, at least until something like Ultimate Blockchain Compression is implemented, "importing" a private key is a disaster.  You either trust someone to tell you how much each address has, or wait 30 minutes for a blockchain scan to complete.  (right now, there is no way other than to do a blockchain scan).

I'm not sure this embodies simplicity.  It embodies simplicity once you understand private keys, but I'd like to hide user-handling-private-key-data entirely (because they're likely to not realize it's different the addresses which are okay to send to your friends).  They should make a backup of their wallet and told to keep it secure, but that's it.  Beyond that, the way forward is "Wallets" and "Balances".  I'd almost be in favor of referring to addresses as "one-time payment codes", to even hide the "addresses" concept to users that only care about how many BTC they have.  A user has a wallet, and balances on each of those wallets.  Combined with "wait 2+ conf for small payments, 6+ confirmations for huge payments", this is enough for users new to Bitcoin to actually be functional.  This is what I want to see in the Satoshi client.  And eventually in the "Standard" usermode in Armory.  

For now, it sounds like Bitcoin-Qt and Multibit and Electrum are going to work on that user-frieindliness aspect.  Armory, bitcoind, and electrum-CLI are going to work on that advanced user aspect.

Let's not bash on Mike too much.  I sympathize with his position -- also coming from the development side, I know how hard/frustrating it is to meet the demands of users for features that may be transient requests, for functionality that seems like it can provided in other ways (spend a week implementing it, then a month later it's obsolete by the other features you put in that serve the same purpose, or the original users don't find it that exciting after all).  It's part of the reason I didn't do coin control for so long -- I didn't even know how to design it because I didn't understand what users wanted or why they wanted it.  How is it supposed to be on my priority list when it has such little value to myself?

In this case, the OP made a specific argument, and I agree with Mike that the specific request by OP is "addressed" by other solutions.  But I think OP, like so many other users, just want the level of control they understand is possible, and he tried to justify it with that particular example that Mike disagrees with.  Everyone is "right" here:  the fee logic should be updated to favor reducing UTXO set size, clients will adapt to the new rules by favoring reducing UTXOs, and users should have control over the source addresses/coins anyway, because some of them prefer to use their knowledge to optimize coin selection for their specific needs on a per-transaction basis, better than the default logic included in the app, and such advanced features should be hidden in the default installation of the app.

Armory lets you control the source addresses, not the individual coins (but still called "Coin Control").  People requested "Coin control", I gave them that, and I haven't really heard any complaints.  So I left it alone.

And my point, based on experience, taking feature requests from hundreds of users and trying to negotiate things in designing Armory... some users just want control.  I agree with you that the fee logic could be updated to favor cleaning up dust.  But that's not the only reason people use it (though, it might be the base for the OP, here).  The advanced folks who understand how it works under the hood *want control".  It's the same reason I will always drive a manual-transmission even though automatic technically does the same thing for me.

As far as I'm concerned, the answer is splitting the interface into usermodes.  That's why Armory has a "Standard", "Advanced" and "Expert" usermode.  Custom change addresses and coin-control only appear if the user explicitly changes the mode to "Expert."  It's a very elegant solution to making these "manual-transmission" features available while still giving most users the automatic transmission.

Although it's easiest if the windows are laid out in code.   Then in the code you say: 

This.

ECDSA was picked for Bitcoin because it has much shorter keylengths than other digital signing scheme/crypto schemes.   For instance, all the following keylengths are approximately equal in terms of mathematical entropy:

--3,072-bit RSA key
--256-bit ECDSA key
--128-bit AES key

There is no doubt that an AES 128 key is sufficient protection, probably for decades, if not longer (protection against well-funded attacker with a billion dollars of computing resources)

It's the link in the "Get Armory"-->"Linux – Offline Bundle for Ubuntu 10.04-32bit" section, under "Ubuntu release page" (http://releases.ubuntu.com/lucid/).  Grab the "PC (Intel x86)" version.

If you get that one, you're guaranteed the offline bundle will work.

Man, this is not going smoothly!  Are you using an non-standard configuration of any sort?  Can you send me a log file? 

Crap, I guess I need to catch that condition!  At least I have access to that output so I can interpret the error message.

Also, having the bitcoind.exe in that directory is not normal.  It should be in the daemon directory.  I wonder if that's an ancient version of bitcoind.exe...?

The log file shows this:


Does that file exist for you?

Gah!  I see the error, and not sure why it happened.  It looks like it's trying to run a non-existent bitcoind.exe.  Can you point it to the correct location in the settings file? 
C:\Program Files (x86)\Bitcoin\daemon\
Run it in offline mode to be able to open and change the settings.  Then continue testing. 

This is actually a wacky bug, because it's not supposed to try running BITCOIND_PATH unless it checks that it exists.  But somehow it found a non-existent one on your system!  I'll double-check the logic to see how that happened.

Windows 64-bit users:  there's now a Windows version available for "testing".

http://dl.dropbox.com/u/1139081/ArmoryTestingReleases/armory_0.87.8-testing_win64.msi

I say "testing" because this is really just a sanity check -- it's still fairly rough around in edges, in terms of accommodating all the different configurations.  If you are not upgraded to 0.8.1 yet, uninstall Bitcoin-Qt and install the new Armory and let it download and install the new one for you (yes, there's cryptographic verification to make sure you're getting the right files! see the top of versions.txt).  Let me know how the process goes! 

There will be issues.  Please help find them!  One issue I'm concerned about (but haven't seen happen recently), is Armory closing and leaving bitcoind.exe running in the background.  That shouldn't happen anymore, but I can't know for sure until people try it.  If it does happen, please tell me what you did.  I don't want to have to add a "kill" button to the dashboard, but I'm ready to if necessary

This has taken way too much time, but I'm fairly certain it's almost done!  Help me test it!

There will be mac binaries soon.  We just recently figured out how to package it.  If you want to do it right now, though, you would have to follow Red Emerald's brew formula (which involves opening a terminal and typing a few commands).  Obviously, the package would be better, but it's not ready yet.

You can use any OS online and any OS offline that runs Armory.  The data moving between them is platform-independent.

For the system without an OS, I recommend installing Ubuntu 10.04-32bit and using the offline bundle (which can be found here).  The reason for that is that if you want the offline computer to never touch the internet then you need to have a few dependencies installed in Linux for Armory to work right (that's what the offline bundle has).

If there's no DVD drive, you can make a bootable USB key installer.  You could use your 16 GB key once, wipe it just to get the OS installed, then go back to using it for other things.  Download Ubuntu 10.04-32bit CD image (the "PC (Intel x86)" link at the top).  If making the USB installer in Linux, you can find the "Startup Disk Creator" application (google for it for your particular linux version), if you have access to a windows machine I recommend unetbootin for making the USB.  If mac... I don't recommend doing that in Mac, as I just googled it and it looks like it can be complicated (but here's a link so you can try).

The nice thing about the offline bundle is:  once you have Linux installed and you copy the offline bundle onto that system, you just run the install script and Armory works.  That's it!  

Why not?     If it doesn't work right, even a few percent of the time, I should still investigate.

Try loading Armory in offline mode (there's a link in your Start menu), and then export a log file for me.  Email or PM.

Of course, you can try stopping it and starting it again.  Sometimes, it just gets stuck scanning (though quite infrequently... it's usually just being slow).   There's a few known stability issues, that result in Armory crashing every week or so.  When the new blockchain utilities go in, that will go away.

Don't forget the Quick Start Guide!