Don't worry guys... I know what to do   There's been a lot of life distractions, and I'm trying to finish some other Armory upgrades that both improve usability, and security.  After that (hopefully in the next couple days!) I'm going to crawl into a hole for 96 hours and not come out until the the RAM usage is reduced and the blockchain doesn't require rescanning on each load. 

Right now, Armory is still an advanced tool.  I haven't made it a priority, because I wanted to focus on unique features that no other program has, instead of having less features, but making it more usable. I'd rather have a program that 50% can't live without + 50% can't use... than a program that 95% of people can use, but don't see the advantage.  Unfortunately, that "50% can't use" is growing quickly, so that's why my priorities have shifted.

It's coming!

Can you email or PM me the whole log file.  I suspect there's some logged messages higher up that indicate what happened.   The specific error you pasted for me is actually way after the root of the error.

I never said that disk encryption is pointless.  But Armory already encrypts your wallet, and guarantees that if your wallet is created encrypted, the unencrypted keys never touch the disk.  By all means, you need encryption, but full disk-encryption is mostly redundant here.  In fact, in some environments, it's inferior -- if you were to use full-disk encryption and unencrypted wallet files, then you are protected the same when your computer is off but the encryption is completely useless while the computer is on (so it can run the OS and access your files).  Someone who gets on your compute for 1 minute can put in a USB key, and copy off the [unencrypted] wallet file to their key.  Ditto for serial.    At least with Armory encryption, the file on disk is always encrypted and inaccessible even when the computer is unlocked. 

The counterpoints to these thoughts are:  just hedge and use both -- disk encryption and Armory encryption.  And in the end it may not matter--anything advanced enough to get to your offline system is probably advanced enough to pull your private keys out of RAM when you unlock your wallet to sign a transaction.  No disk encryption can protect against that.

The security environment is this:  you have an offline computer setup securely, and it has not been compromised in any way.  You have a verified version of Armory installed and know it works perfectly (of course).  However, you assume an attacker has full control of your online computer, and knows you will be using <insert transfer method here> to move data back and forth between your [compromised] online computer, and you're not-yet-compromised offline computer.

If it's a serial connection that's not done correctly, they grab your Firefox password file and try every entry to TTY login to the offline machine.  Once there, they grab the encrypted wallet, and start trying to brute force it (probably also related to one of your firefox passwords...).  Or if that's not enough, they keylog your passphrase and send it back over the serial line to the online computer (which is compromised).

Similarly, if your transfer method is USB keys, there's undoubtedly lots of ways to exploit autorun.  Put a carefully crafted file on the USB key with a payload that gets executed when you plug in the USB key, and it carries your wallet out with it when the user brings the USB key back to their online computer. 

Any mention of Armory flaws, or initial install security is mostly out-of-scope.  We assume the user installed the correct software offline and that the software itself performs exactly as expected. 

Are you talking about scanning QR codes, or a program that produces QR codes?  Armory could easily produce a QR code of the private key, though I'm very much against sharing private keys with anyone.  It adds an order-of-magnitude extra complexity to the application if some private keys are epic-fail if not protected, and others are already/intended to be shared.

Either way, Armory has a window for looking at the private key of the address.  It wouldn't be too hard to add a QR code to that window.  (to use at your own risk).

You don't see it, but Armory actually opens a localhost port in order to catch duplicate instances of itself, and handle Bitcoin URIs.  If Armory is opened a second time, it fails to be able to open that same port for listening (because the first instance is already using it), and quits instead.  If there was an argument on the command line, Armory2 sends it to Armory1 over that port, before exiting.  This is how Armory pops up when you click on a link, and also prevents your wallets from being corrupted when multiple instances collide.

When's the last time you did a git pull?  I have actually been updating the branch pretty constantly, trying to add the new features.  I see that error all the time, but it usually goes away with a quick update.  Check for the latest version, and then also try changing your settings instead of using the command line (I mean, both should work), but I just want to get more info about what does and does not work).


After this update, both of those concerns will be fixed.  Right now, it's added a tremendous amount of simplicity and robustness to Armory, doing a rescan and holding a bunch of [now-very-large] lookup tables in RAM.  Not having to store any persistent, corrupt-prone data between loads is a huge benefit.  But now Armory has been ironed out so well, and resource usage is so high, that this will be the first thing I address after this update is done (both RAM usage and not rescanning every load).

I personally don't believe it would.  I'm not all that experienced with malware, but I know the actual executable code tends to be tiny.  According to wikipedia, "Stuxnet was unusually large [for a virus] at 500 kB".

Also, while your individual transaction may be small, Armory has to transfer all the supporting transactions so it can verify the transaction fee (it makes me wish Satoshi had done one tiny thing differently to avoid this necessity).  Because of that, you don't necessarily have control over it:  someone may send you coins in a 200 kB transaction, which will then have to be couriered to your offline machine along with the one you want to sign.  If your wallet consists of lots of little inputs (like a donation wallet), then you will end up with enormous transactions.  I've seen 3+ MB, before.

Unfortunately, I have to accommodate that in this solution, as it will actually be more common than I initially realized.  A company that does business with even 10 customers a day, will have a 70-input transaction once a week in order to move the coins.  Theoretically, you could have a 100 kB transaction with something like 600 inputs each of which is about 100 kB -- that would lead to 60 MB to be transferred (based on the fact that the network may be making >100kB non-standard for tx).


The disk crypto doesn't help in this case, because either (1) you use full-disk-encryption, which will be unlocked while the system is on, so a "copy" will copy the unencrypted data, or (2) The wallet file is encrypted only, in which they only need to keylog your passphrase to get it.  Though, I have received some good ideas for helping with keylogging, but any malware advanced enough to compromise your offline computer could easily pull your crypto key out of RAM next time you unlock the wallet. 

The goal is to avoid getting to that point at all:  a serial connection that doesn't possibly induce any subsystems to kick in and try to help out.

As usual, can you email me a log file?  Or copy any errors you see in the log file here.  I suspect there's an error being thrown that is usually some code punctuation out of place or something.  It's usually a quick fix, and usually results in buttons/commands looking like they do something, but then not doing it at all.

I just got a request to cross-link some discussion in the newbie's thread:

https://bitcointalk.org/index.php?topic=156003.msg1674928#msg1674928

Looks like good information!

It's possible that Bitcoin-Qt was not fully synchronized with the network.  If it was still a couple days behind in the transaction history, Armory would have no evidence the transaction ever existed.


The new version of Armory coming out soon will hopefully fix this problem!

FYI:  some kind soul has donated a RPi to me!  It should be arriving soon, and I will be figuring out how to compile on it.  I hope to make offline-bundle releases for it, eventually. 

But this thread isn't useless ... I'll be needing to figure out how to compile it myself!  So... carry on...

If Armory finished scanning and is online, please check the bottom-right corner of the main window for the "Connected (X blocks)".  If everything is up-to-date, then you will see (as of this writing, Mar 25, 2013) something like "Connected (227,977 blocks)".  If that's correct, then please go into your wallet and find the address you sent coins to, right-click on it and show it on blockchain.info.  Although Armory usually picks up fresh, zero-confirmation "unconfirmed transactions", it frequently doesn't.  Then you'll have to wait 1 confirmation before it shows up in the main ledger.

It's funny you say that, because I spent the last week pulling my hair out trying to accommodate all the situations to make "auto-management of Bitcoind" the default without confusing people too much, but also try to leave "self-management" available (which may be forced on OSX, for now).  So far it seems to work, quite reliably, too! 

Strictly speaking, the two won't be "merged", code-wise.  But it will be transparent to the user.  I'm just finishing up the process of helping the user download and install Bitcoin-Qt in Windows.  Once Bitcoin-Qt is installed on the user's system, they'll never see it again (unless they want to).  I'll hopefully be releasing a testing version for Windows, soon, then people can dig in and see for themselves. 

@ Tirapon:

The problem is there is an enormous range of size of data that needs to be moved.  Most transactions will be a couple kB.  Some tx, and all the all the supporting tx, will be MB.  I wouldn't consider any device with less than 5MB of space, sufficient for 100% of transactions.    Even if that was sufficient for avoiding malware (which I don't think it is), it would be pretty tough to find 5 MB USB keys.

@Blowfeld

I just want to clarify this is not "security through obscurity" -- moving the /dev objects around for the serial port is not for confusing malicious threats on the offline computer, it is about confusing innocent, latent threats.  We are operating under the assumption that the offline computer is not compromised, not under malicious control.  Moving the /dev devices around is about confusing pre-existing software/modules that are part of the OS/kernel, that might otherwise kick in automatically when it detects a serial port and expose attack surface.  Learning about tty logins scared the crap out of me me, because it took something that was theoretically very safe, and turned it into a security disaster (I would wager that 30%+ of users will use a login on the offline computer that is stored in their saved passwords in their online webbrowser -- this means that an infected online computer needs only a couple seconds to tty login over serial and take the wallet).  

The tty logins on the offline computer are not "malicious", they are simply trying to make a shortcut for what kernel developers 20 years ago expected we wanted:  which is that we connected the serial port so that we could login from a different device.  That is clearly counterproductive to our goal with offline wallets, and it's the reason I didn't want to blindly recommend serial ports, because of the risk that impatient/low-attention-span users would actually decrease their own security instead of increase it.

If your offline computer is already compromised, well there's not much we can do about that.  Anything we could do, would only be a temporary relief until the threat adapts and the next person's compromised system already defeats the new security procedure.  This is more about disarming the rich subsystem of modules that are pre-built into the kernel, to "try to help out" when you plug in a device.  Perhaps a custom OS is the right procedure... but I'm no an OS developer/packager/distirbutor.  It is also at odds with my goal for "easy" and "transparent."  The solution not only has to be secure, but it should be trusted -- a custom OS leaves room for all sorts of shenanigans, which some users may not trust, and instead go for lower-security-but-with-higher-certainty solutions.  The nice thing about the serial port idea is that it's strictly a software solution that applies to anyone's favorite/trusted *nix OS, and is easy to review the code that moves devices around. (and if they're using some obscure OS that the default script doesn't handle, well they have enough obscure *nix knowledge to translate the process for their OS).

The address changing problem is actually one for the payment protocol.  That was thoroughly discussed on the mailing list, and I suspect it's something that will come to fruition soon.  It's not a sure-shot, but it definitely avoids most of these problems:  you would now send money to receipts@bitcoinarmory.com, and even the offline computer would be able to verify that there is a trusted CA signature confirming the underlying (invsible-to-the-user) address.  It's not a certainty, but it shouldn't be used for $1mil+ transactions, the same that you don't [shouldn't] use SSL for $1mil+ operations.  Bitcoin can still be used there, but it would be done with a higher, manually-verified level of checking.   I think it's a perfectly acceptable solution for small-to-medium transactions.

Please don't go off on a tangent here discussing CAs and SSL security and how it shouldn't be merged with Bitcoin, etc.  I can point you to other discussions if you want to insert your two cents about it.  I'm of mixed opinion about it, but I do believe it is the lesser of all evils for small-to-medium sized transactions (status-quo being the evilest), and I'm happy to support it if everyone else does.

My fault, actually.  I believe that text was copied for the 0.86.3 release, and then I updated just the version number when I released 0.87, not noticing that the date was part of it.  Of course, I wanted to have the latest version number, so people simply copying the commands would get the right thing, but I screwed that up.  I'll update it on the webpage.

Sorry for the confusion!

I'm just finishing the crazy updates for 0.88, and then I will be doing an official release (after a testing period, probably over the next week).  As part of that process, I have to setup a different offline computer just to sign Windows and Mac binaries (this is turning into a real PITA just for signing Windows binaries in Linux, and so far I can't find anything at all that does OSX).  In order to avoid problems with the gatekeeper, I wanted to make sure the first actual OSX release is signed with a real certificate.

So to answer your question, probably next week.  Even if I wanted to, I don't have my system setup yet to do the signing... that's getting done Friday.
(yes, i'm a stickler for making sure identity information/signatures are kept offline)

@alexanderanon

It might work being 50 days behind, but probably not.  You'd be lucky if it does work, and doesn't start choking on all the data that Bitcoin-Qt is sending it.  The new version will actually just run it in the background for you, and won't even let you connect until it's synchronized -- because users have so many problems when they do it early

I know backups are confusing, which is why I made this backups page.  There's a better one, coming soon, but that at least has most of the information you could want.

The answer to your question (directly), is that if your wallet is encrypted, your digital backup will be, too.  The encryption is very strong, and the attacker needs to know something about the passphrase in order to break it.  So in that case, you'd be safe.  But you'd probably also forget the password in 2 years when you need it, making that digital backup not very useful (especially if you are trying to restore from backup because you forgot your passphrase!).

I always recommend a paper backup, which is unencrypted.  Similarly, if your wallet is unencrypted, your digital backup will be too.  In both cases, if someone steals it, they will send all your coins to their own address, and your online Armory will show an outgoing transaction to an unknown address.  You won't see anything on the offline computer, because it doesn't have network access (the offline computer doesn't even show balances, it's only for "signing the checks").  If you have online armory open, though, you'll see it right away.  And you won't know that anything is wrong until it's too late.

Let me just reiterate one point:  the vast majority of use Bitcoin cases are threatened by online/virtual threats, not physical threats.  Unless you have a specific reason to worry about physical security of your paper backups, you should use the unencrypted one.  Because, if you use the encrypted one and forget your passphrase, it's just as good as not having any backup at all!

---

Hey thanks!  Unfortunately, the other currencies are not in my priorities list, but "simple" variants like LTC can probably be made work with only changing a few constants and updating a couple of functions.  I can offer advice to someone making that leap, but I don't have time to do it myself and debug it, etc (also, I don't use the others coins, so I don't even know where to begin)..

Yup!  I actually just tried to use it myself on an offline computer and ran into this.  I already adjusted the build script to distribute them with the dependencies needed to run them, I just have to do a new offline-bundle.

Big new release coming soon.  I'll make a new offline bundle just for that reason.

I've been touting the 2,000/month number based on the code.google.com/bitcoinarmory/downloads page.  The latest statistics are a little muddled though, because I released 87.2 very shortly after 0.87 but didn't announce it for a while to avoid spamming users with more updates.  So, I'm sure some there's a lot of duplicates there.  Also because many people use different OS for online and offline computers.

Though, it's offset by the number of users who also access via git repo directly, and OSX users using Red Emerald's brew formula to install Armory (because there's no official release for OSX, yet).  It's probably still less unique users than shown on the download page, but not dramatically.

So there have verifiably been 6,300 downloads of Armory between Jan 11 and March 22.  That means about 2,800 a month if they were all unique.  Therefore, I stay conservative and say 2,000/mo.

Along the same lines, I was just talking a lawyer friend of mine, and he mentioned FERC (Federal Energy Regulatory Commission) as an example of why you shouldn't read too much into something like the FinCEN guidelines.   He said that FERC is notorious for having a set of rules, publishing guidelines for following the rules, then slamming companies with millions of dollars in fines for violating the rules, even if they followed the guidelines exactly.  The reason?  "Well the guidelines are not the law, the law is the law, and it should be perfectly clear how to interpret them.  We're not sorry if you got it wrong." 

I asked what was the point of publishing guidelines at all if it offers you no legal cover for "misinterpretations" of the underlying laws?  He didn't have a good answer for me, other than they publish guidelines because of all the requests they get for clarifications.  Perhaps such clarifications can do more harm than good, giving actors a false sense of security about what they're doing.

I'd like to think there's more sanity in the world than that.  I'd like to think that the FinCEN guidelines gives you something legally-meaningful to use in self-defense in these cases.  It might be worth someone (probably a lawyer), doing a bit of research on the past cases involving FinCEN to look for precendents of this type.   You know it's true of FERC because of all the cases where this has happened... perhaps we can find similar evidence for FinCEN.  Perhaps, cases where a judge ruled in favor of someone following the guidelines instead of trying to interpret the law.  Or vice versa.