Armory has a multi-wallet interface precisely because it does support different security models.   Many users keep different wallets also for general organizational reasons, and I've heard that the bitcoind "accounts" are very ... awkward.

We spent a lot of time making the interface natively support multiple wallets, because having a single wallet doesn't meet the needs of most users -- you need to be able to manage "spending cash" (hot) and "savings" (cold) simultaneously, you can't just keep all your money in one or the other (you can, but it's not ideal).  Also, we use watching-only wallets to track employees payments.  For instance, here's why we hold multiple wallets:

• A hot wallet for day-to-day spending
• A watch-only wallet for an offline/cold laptop in the office
• A watch-only wallet for an offline/cold laptop in a safe-deposit box at a bank
• N watch-only wallets for each N employees, so we can pay them without requesting or reusing addresses.  Armory also has an export function to save the transaction history for each wallet to a CSV file for book-keeping.

The last one isn't limited to companies.  You and your friends can exchange watching-only wallets, and use them to pay each other.  It's automatic book-keeping, easy backup, and never re-uses addresses.

Trying to deal with multiple wallets in any other app is kind of a pain, and not all that useful unless you're using significantly different security profiles for each one.  I agree that if the private keys for multiple wallets are on the same hard-drive, they have essentially the same security profile (assuming they're both encrypted).

On second thought, you're using Linux with 0.91-beta -- you can use the secure-downloader to download a verified copy of bitcoin core, and it will even unpack it for you and automatically adjust your settings to use it.  I specifically enabled this because it can be kind of a pain to get Bitcoin Core setup on Linux and get Armory pointed to it.  I'm so used to recommending users just run it themselves, that I forgot we have a better answer for it.

The secure downloader currently only has Bitcoin Core 0.9.0, but that is fine for what it needs.  The open SSL bug is irrelevant with the way Armory uses it.  And it will only download and unpack a local copy ... any installed versions you already have will be untouched.

We'll be doing another point-release shortly, and will also update those downloads to get 0.9.1 into the secure downloader.

It'll be easiest to just run Bitcoin-Qt yourself, but in Armory options unselect the first checkbox "Let Armory run Bitcoin software in the background".  Then restart Armory -- it will use the manually-run bitcoin-qt instead of trying to start it itself.

Just make sure that Bitcoin-Qt is fully sync'd and shows the green checkmark in the bottom-right, before starting Armory. 

Sorry for the delay... I totally got swamped and forgot about the bounties.  I will compile a list of first-reported bugs and then have people PM their addresses to me.

However, we're about to do a 0.91.1 release with some tweaks and notifications regarding corrupt wallet reports.  Unless I hear complaints... I would like to just merge it all into one bounty campaign and pay out all at once.  Since the changed in this point release are so minimal and isolated, it should be a very quick testing phase

This is why deterministic wallets are being so widely embraced.  It is all upside, and no practical downsides except in community-unsupported use-cases where people want to reveal some of their private keys but not others.

Given any subset of private keys or public keys in a deterministic wallet, no matter how many, there is no way to know they are related, an extra piece of metadata stored in the wallet file called the "chaincode".  Without the chaincode, it's all perfectly private.

This applies to Armory deterministic wallets, as well as BIP 32 wallet (which Armory will be migrating to, soon).  In fact, BIP 32 has an additional, related feature that we plan to leverage for identity verification / webs-of-trust:  you can give out your root public key (such as on your business card), and then provide a piece of metadata with each address you distribute, which proves that address is linked to the root public key on your business card.  However, this proof does nothing more:  it doesn't now allow them to prove any other addresses are related, it doesn't not let the sender generate any more of my own addresses.  And I, as the receiver, don't have to provide the proof if I don't want them to know it's related to my root public key.  So I can remain anonymous if I want to, or I can prove identity if I want to.   They would need to have the chaincode in the wallet to learn any more-- and if they have access to my wallet, they have all that info anyway. 

I did just verify this is true.   thought there was an OP_0 in there for every empty sig, but just verified there isn't on a confirmed 3-of-4 spend.

Luckily, it's not exactly O(N), because as long as the sigs are the in the right order, the mapping between the two lists converges quickly.  You will end up with extra/unnecessary signature checks, but you shouldn't need more than N.

I agree it could be improved by utilizing that first push-data, but keep in mind that value is a source of malleability.  I think we'd prefer to force it to always be OP_0, or force it to encode a canonical encoding like you recommend.  I doubt we'd do a softfork just for that change, though, so it will probably stay at OP_0.

I forgot to mention, that you can use coincontrol to spend regularly from the wallet without risk of spending those coins.  But you have to be diligent and remember to always use coin-control with every transaction.  The first time you forget, those coins will like be spent (the older they get and the more tx you execute, the more likely they'll be used in the next tx).  That's why I recommend the new wallet -- you do it once and don't have to worry about it again.

Technically you could request payments to that address in Armory, but you'd have to explicitly ask it to.  Otherwise it will always use the next address in the chain and ignore old ones for receiving.  Spending, however, will happen.  If you keep receiving colored coins to that address, Armory will keep adding them to the pool for spending.  The only way to leave them untouched but use your other coins is to simply switch to a new wallet and move all those coins there.  Then you can treat the original wallet as a kind of mastercoin watch-only wallet (technically you can spend them, but it sounds like you won't be)

Ugh.  Armory doesn't really have a way to do this.  In essence, you have a colored coin, and Armory is not aware of the meaning of the colors.  It treats all coins the same.  It sounds like you're looking to delete or remove the address, not "export" it.   Armory doesn't have a way to do this with deterministic addresses.  Nor does it have a way to lock addresses or coins.

My recommendation is that you create a new wallet and move all the non-colored coins to it.  Make sure you are in expert mode, and use coincontrol to select all coins except the colored ones.  Press "MAX" button to indicate you are moving all coins currently selected in coin-control.  Use the address book to send them to the new wallet.

There's no other way (currently) to tell Armory to treat some coins different than others.

This is precisely what Armory Bitcoin Wallet does.  Armory pioneered the entire cold-storage concept, and wallets that only have to be backed up once.  The two concepts together are extremely powerful: security from others and security from your own mistakes.

It's as good as you can get for a single-signature cold-storage system that is going to be used by non linux-geeks.  You can track your balances, request payments, and verify incoming transactions without compromising the security model.  And you can keep the offline portion of your wallet in a bank vault if you want to (stop by your safe-deposit box to boot the system and get your signature).  You can see more about it here:

https://bitcoinarmory.com/about/using-our-wallet/#offlinewallet

Armory will also be releasing its generic multi-signature interface to expand the security model in any direction you want.  It's quite powerful, but it's not in an official release (though it will be soon).

https://bitcointalk.org/index.php?topic=559776.0

Yes, when that is released, you could store all your coins in a 4-of-5 fund, with each key kept on a separate offline computer in a different bank vault.  We do this already for single-sig, Armory will enable for arbitrary multi-sig, as well!

I actually don't agree with Ente on those statements.  Print a paper backup of your wallet, and you are protected forever.  Armory is being used on $10M+ worth of BTC.  If Bitcoin has any value, there will always be a copy of Armory floating around that can be used to recover your coins.  Or someone will create something that can produce the private keys from the paper backup.  It's not a terribly complex algorithm.

If you have to worry about change addresses, etc, you are taking unnecessary risks.  Part of the reason I made Armory was to help people avoid dealing with those low level details

Of course there is.  I'm just mentioning that this sounds like a solid solution to use (if done properly), if you have more than a casual interest in the privacy of Tor.  And it doesn't require us (Armory devs) to do anything to support it.

Please carry on, figuring out a non-VM solution, and helping us figure out how to make sure Armory behaves itself properly in that environment.

I actually really like justus's suggestion in the short-term, because it completely compensates for anything Armory does that is not ideal for Tor.  Setup a VM that basically only allows traffic through Tor.  Armory can't really misbehave in that environment.

Though, at the same time, I don't think it would be to make sure Armory is doing the right thing, I'm just not the person to do it.

Btw, regardless of what we say here, I would not interpret that as official advice or in any way guaranteeing ... anything.  I bring this up because many people use Bitcoin in ways where privacy is equivalent to their personal security (either in less-free states, or for doing questionably legal things). 

I suspect that the strong privacy protections of Tor probably require both the user and the developer to be careful.  Unfortunately, I have spent no time learning about Tor, or spent any time figuring out how to make sure it doesn't leak information.  As such, I would not rely on it in this way unless you have only a casual necessity for privacy. 

I would be happy to entertain someone who really understands Tor, to be able to review what Armory does, and make sure it doesn't do things that leak information.  For instance, we have periodic announcement checks, and check for internet connection on startup by pinging google and microsoft.com.  Both of these can be disabled -- but I suspect there may be other things that I don't realize leak information, even when the user has been careful.

We'd have to see your logfile.  You should be able to submit it from within Armory (in offline mode) using "Help"->"Submit Bug Report".  It will send us the log.  Or you can use File->Export Log File, and then attach the result when you submit a ticket:

https://bitcoinarmory.com/support/

Make sure that you have properly modified --satoshi-datadir to the right folder, and that it exists.  We typically see this happen when the user originally was running Bitcoin Core in the default dir (C:\Users\<user>\AppData\Roaming\Bitcoin), then later moved to a new directory but left the original one there.

Armory looks for a P2P connection to Bitcoin Core and looks for the blk*.dat files in the bitcoin home directory.  If it finds both, it goes into online mode, not realizing that the blk*.dat files it's watching aren't being updated.

@shoesman

Rather than changing the shortcut, try running it directly from a command prompt to make sure. 

Start->Accessories->Command Prompt

You don't need the --satoshi-datadir arg because the path you have there is already the default (as long as your username is actually "bob").

I will just reiterate what goatpig said:  this line indicates that Armory is starting without out any of the command-line arguments you claim you're starting it with.  Whatever you're changing to change the args, is not actually making it to the final call to start Armory. 

If you are using Tor, I believe you should avoid -addnode=127.0.0.1.  I believe that Tor connections all appear to be from localhost, so if you are attempting to only allow actual-localhost connections, you won't get what you think you're getting.

(again, I don't know much about Tor -- just relaying a warning I was given a while ago)

Then you probably need --satoshi-port=9150