I've witnessed this issue once before on a Windows machine, and I actually don't know why it only happens on some machines.  It appears that Armory is trying to write out a log file that it has no access to.  Can you please go to C:\\Program Files\\Armory and delete the Armory.exe.log file and try again?  Is your Win7 account an admin account?  Or an unprivileged user account? 

I just stumbled on an article about disabling Armory.exe.log... which I don't need anyway, but it hadn't been an issue so I didn't bother figuring it out.  I'll see what I can do.

Also, I just started the testing process for the next version of Armory (0.84).  This version has a new flag that allows you to override the internet detection.  Frequently, the false non-detection of internet can be due to VPNs, non-standard network settings (i.e. proxy/Tor).  I am not familiar enough with these things to know how to accommodate all of them, but 0.84 will have a way to tell Armory to use online mode even if you don't detect internet.

Thanks for your patience.  My goal is to get it stable on all systems, but there are inevitably lots of system configurations that break my best efforts 

FYI, Armory connects to bitcoin-qt/d via sockets (via python-twisted) on localhost over port 8333.  Is that potentially an issue?

I just looked through the log file you sent me, and I see the most interesting thing:


I have no idea what could be causing that (it's the first time I've ever seen that).  But it looks like a good explanation for why nothing is being updated.

The logic in the code goes like this:
(1) Check the blk000X.dat file for updates
(2) If there are updates, read in the new data, add the header to the header map
(3) Re-calculate the longest header chain (which may involve a re-org)
(4) Write "New Block! : <TopBlockHeight>" to log file

So, for some reason, Armory is detecting new blockfile updates, but after the blockchain update, it thinks that the main chain was not extended.  Unfortunately, when there are re-orgs or errors in the underlying C++ code, that doesn't get written to the log file (it's too difficult to capture it from python).

I'm going to have to spend some time thinking about how this could possibly be happening (difficulty-bits conversion-to-float error?).  Thanks for the log-file... maybe I'll figure out what's so special about your system!  By the way, if you don't mind re-downloading the blockchain in Bitcoin-Qt, I would appreciate you trying that.  Go to your ~/.bitcoin directory and delete all the blk000*.dat files, then restart Bitcoin-Qt.  In the past, I've seen bizarre Armory behavior when something unusual showed up in the stored blockchain data (I don't know what, but I know that many people who reported bizarre behavior saw it go away when they re-built their block files this way).

Thanks for your patience!

Please email the log file to etotheipi@gmail.com.  Thanks for your patience.

I already have it on my list to add a checkbox to hide change addresses... perhaps I should make it possible to hide empty addresses, too.  However, they can't exactly be "removed"... they are an intrinsic part of your deterministic wallet.

Something is awry if the data is in the blockchain and a restart doesn't show the coins.  It means that Armory is having difficulty accessing the blk000X.dat files maintained by Bitcoin-Qt.  Transactions disappearing is concerning, too. 

Could you do me a favor before going back to Bitcoin-Qt and export the log file for me?  It should have record of any errors triggered in the last couple times you opened the client.  There is no private key data in there (you can empty the wallets first, if it makes you feel better).  I just want to see what kinds of errors were showing up when you were having this difficulty...  (File->Export Log File)

Odd... can you create a new shortcut for it and run it with the " --debug" flag?  That might reveal a little more information.  Unfortunately, it sounds like a seg-fault...

Just as a point of reference ... last I checked (a couple months ago) the total number of hashes performed by the Bitcoin network since 2009 is only about 2^68.  Think about thousands of GPU mining rigs doing billions of hashes per sec for a few years... that's enough "guesses" to break 68-bit key 50% of the time...

Therefore, 64-bits is crackable in a year only with extraordinary resources (barring weaknesses being discovered in AES).  Anything beyond that -- 96 bits, 128 bits, etc -- is arguably going to be safe for decades, even with extraordinary advances in computing speed.  

Unfortunately, most user-created passwords contain far less than 64 bits.  Though, you can offset it quite a bit with key-stretching -- if you slow down guessing speed by a factor of 65,000, that's kind of like adding 16 bits of entropy to the passphrase.  

This is why Armory uses RAM-heavy key stretching for its wallet encryption.  When you create a new Armory wallet, it will test the speed of the system it is running on, and will usually require at least 2MB of RAM, and however many hashes it can do in 0.25s.   This is essentially scrypt -- each thread an attacker uses to guess a decryption passphrase will require 2 MB of dedicated RAM, and will have have a non-trivial amount of hashing to do.  The RAM requirement makes it infeasible to execute on a GPU -- you might get a modest speed up, but not orders of magnitude (because all threads would have to use super-slow global memory instead of super-fast local/shared mem).  If your system is fast enough, it could require 32 MB -- then the attacker would be better off with an 8-core CPU than a GPU.

To answer your question about brute-forcing:  if someone creates a truly random 256-bit encryption key -- it's not possible.  Bruce Schneier showed (via thermodynamics) that if you had perfect computational efficiency, you'd need the power of something like 40 trillion suns in order to crack one perfect 256-bit key (actually that sounds like of low, to me... maybe he was talking about hash collisions...?  I don't know, look it up).  That doesn't take into account how many gazillion years it would take to consume and apply that energy.

The weakness is the password, so as others keep harping -- a strong password, on an encryption scheme that has solid key stretching is the way to go.  For instance, someone contacted me recently to ask if there was a way to recover their Armory password.  It turns out, a completely random 5-char password would take over 100 years for him to crack on his own system (for default settings of the Armory wallet)... considerably more if the password was longer.  But when he told me how simple his password was, I was able to write a script to help him find it in 12 hours...

Back from Armory vacation!

The last month has been devoted to lots of random things, the biggest of which is wedding planning.  I also got distracted by some random side projects and even a couple games.  However, it was a much needed break after an epic battle to make Armory multi-threaded -- I hit a frustrating combination of threads losing synchronization causing difficult-to-debug seg faults, etc.  I spent days debugging, and I was desperate to be distracted by something else... so I found other things...

However, I jumped back in recently feeling refreshed, and without any other distractions (plus, a few days off of work due to Hurricane Sandy gives me some time to dig in).  After a rough re-entry battle, I found a single bug that seemed to clear up almost everything.  There's still some features remaining to be implemented for the GUI to play nice with asynchronous BlockDataManager.  But most of it is working.  I even had it running for two days without any issue -- I didn't actually send any coins in that time, but at least there are no memory leaks or issues with reorgs, etc.

Additionally (and importantly), I optimized some of the blockchain scanning code, so now mega wallets (with 1000+ addresses) should operate much more fluidly.  The fix seemed too easy, and I seem to remember there was a reason I didn't do this 4 months ago... but so far I can't see anything wrong with it.  Testing will be key.

So, I don't have an official testing release yet, but maybe ambitious folks like Red Emerald would be inspired to check out the "threading" branch and try it  It'll throw a few errors for some operations (like shutting down), but it won't lose you any money -- the worst that can happen is the GUI loses communication with the BlockDataManager and then you can't view balances, etc (but I haven't seen that happen recently).  If you do test it:  please open the latest stable version first (0.82.4) and write down your wallet balances, to compare to the balances reported by the new version.  I want to make sure wallet scanning is still reliable.  

When multi-threaded Armory is stable, that will be beta!  0.82.4 has been working very reliably, and this new version (0.84) will be tremendously more usable, now that it opens immediately and tells you what's going on (scanning, offline, disconnected, why it can't go online, what you can do in each mode, etc).  Hopefully, it will be no more than a couple weeks!


EDIT:  As I should've expected... I broke a lot more things than I thought I did.  It seems that all import/sweep operations only update the wallet balances after a restart  (probably related to the scanning code I updated).   So I still have plenty of work to do here...

Red Emerald:  I called you out specifically, because I think you had tried this version before, and found it unusable -- I discovered the exact same thing when someone sent me a wallet with 1000 addresses with 1000+ transactions.  The scan operation was running in O(N²logN) instead of O(N logN), causing the GUI to timeout while waiting for updates from the BDM.  This was only noticeable when you have tons of addresses (which is why I didn't see it at first, but then ran into it after someone sent me a huge wallet)

This problem has come up quite a few times in the past, but it was so long ago I honestly don't remember if it was ever resolved.  However, there have been some networking-related bug fixes since then.  Please download 0.82.4 and try again:  https://github.com/etotheipi/BitcoinArmory/downloads

I'm not saying attack surface is exactly 0.00, simply that I'm not aware of any transfer method that has less linkage between the content of the data stream and what code will be executed. (and subsystems of the OS that automatically operate when the link is detected)

If you want to discuss this further, please respond to the thread I linked above.  This would be a good discussion to have there.  

It's about as good as you're going to get.  There is no default software on any distribution (that I've ever heard of) that executes code based on the content of incoming audio streams.  Serial, on the other hand, some linux distributions have telnet logins enabled by default over serial ports!

Aren't there encoding methods with a higher limit that can be printed out?

If I was working with a savings wallet with > 10^4 USD equivalent I'd buy a printer/scanner for the offline computer and use paper to move the required data if that reduced the potential attack surface.
[/quote]

There are non-standardized ways to do it, but it will be a lot of work.  I have discussed a lot of ideas -- and associated strengths and weaknesses -- in my Improving Offline Wallets thread.  A lot of ideas have been discussed there, and you are welcome to contribute if you have more ideas.  I think I converged on a solution, though:  audio coupling.  Take two double-male audio cables and connect MicIn-to-SpeakerOut and transmit the data the same way a modem would. 

This has some tremendous benefits:

• (1) Zero surface for remote code execution between machines
• (2) Platform-independent (someone using an archaic/ancient version of Linux for offline computer may not be able to get webcam drivers working, but audio almost always works)
• (3) Simple, convenient and inexpensive for the user.
• (4) Bandwidth is sufficient to transfer a couple megabytes in less than a minute

I have not committed myself to this solution, but in the absence of new ideas, I believe this is how I'll go (when priorities become appropriate).  Before anyone mentions webcams, serial cables, IR, etc, please read that thread.  Those ideas were discussed, and may be appropriate for knowledgeable users, but I do not believe they are satisfactory solutions for the general user.

No matter how much you try to avoid it, the system must still be able to handle it.  Even if it was acceptable from the user perspective to use only a single address, users would still combine wallets, import keys, etc, and it would still happen.  Plus, many users may collect month for months without ever moving the coins once, which means there will be no opportunity to consolidate coins until it's already too late. 

Even if it was, it's not worth the effort just to use QR codes for this purpose.  The answer is to find a transfer method that has higher bandwidth than QR codes.  (though, I do agree that programs could do a better job in this regard for high-activity wallets)

It's an attack that is possible, and can ruin someone.  Even if the attacker has no financial gain from it, money may not be their primary motive.  Not to mention, that someone with serious mining power could see financial gain -- and further, if someone has compromised the online computer to do this, they can intercept the transaction so that no one else sees it until they can mine it themselves.  Sure, it may take a couple days, but the person may just assume something is wrong with their client or the tx fee (the fee they thought they were paying). 

No matter how silly the hole may seem to you, it can cause epic financial damage to someone and it's easy to avoid (modifying BIP 10 for this took only a few hours).  Thus, it had to be done.

Nonetheless, even if those transactions were not included, the tx to be signed could still be huge.  The transaction I referenced in my previous post was 140 kB.  Still too big for a QR code.

Well, the pickaxe is always shown, but the little checkboxes on the left are handled differently.  Usually it shows a partially-full bucket with the number of confirmations up to 5 (like on the screenshot on the main page) and then just shows a checkmark.  For coinbase, I decided to just map the 6 bucket levels to 0/120, 20/120, etc, but not actually show the number except in the mouseover text.  Then it changes to the same as others once it hits 120 (as you can see for the coinbase on the bottom of the ledger).

It's one of those millions of polishing things that is useful for so few users, but worth doing it eventually.

I wanted to add my number one reason for preferring BTC:  identity theft.

When you use a CC, you are giving the merchant your credit card number.  Technically, they can charge it as many times as they want.  They store it on their system and hackers get millions of credit card numbers when they breach the merchants' systems.  How many times have I been notified that my CC number might have been compromised and I have to get a new card?  I even had fraudulent purchases on my CC before and spent hours on the phone with the CC company explaining that I'm single with no kids -- why would I be buying $1,500 worth of baby supplies?  Even PayPal has automatic payments that I have found myself struggling to "cancel" in the past.

With BTC, you authorize each payment.  There is no way to do automatic payments.  In the absence of someone compromising your personal computer, there is no risk of someone hacking a merchants' system and getting your BTC private key -- you never gave it to them.

This isn't exactly a real-life scenario, but it's a real-life consideration in a world with accelerating levels of identity theft.  If the economy grew such that Bitcoins were frequently accepted online next to fiat, this is a clear advantage for Bitcoin that many consumers can tangibly understand.

I put coinbase transactions in Armory recently.  I didn't think it would ever matter, because there'd be so few people ever mining blocks directly... then P2Pool came along...

Feel free to plagiarize my pickaxe icon

It's even a tad more complex than that.  Without the blockchain on the offline computer, it can't verify all the information on the transaction, and it may be tricked into signing something that you didn't intend.  i.e. -- someone hacks the computer holding the wallet you use to create the transactions, and the next time you create a transaction, it will put false information in the transaction, and it will look like you are paying a 0.0005 tx fee, but it turned out to be 500 BTC fee.

There is discussion of this in the BIP 10 document.  The punchline is that you need to transfer not just the transaction to be signed, but every transaction that provides inputs to it (so that it can manually verify amounts and hashes).  Because of this, the data to be transferred back and forth between online and offline computer can be way more than a QR code can handle.  It is usually less than a few kB, but someone recently submitted a bug report because Armory choked when trying to sign a transaction with 483 inputs -- and so there was 483 transactions to be transferred, totaling about 3 MB.  QR codes are just not feasible, here.

I want to get away from USB keys, but they are just so damned convenient and people already know how to use them, so I haven't been able to make it a priority, yet.   For now, USB keys are a 98% solution, and I'd rather people use this solution, than be greeted with something dramatically more complicated, and then they give up on offline wallets altogether. 

First private key + chaincode = compromise of all private keys (security fail)
First public key + chaincode = reveal all public keys/address (privacy fail)

The chaincode by itself is not useful.  Even if someone gets the chaincode, they still need your first public key in order to derive the rest of your public keys (your first Bitcoin address is not enough).

And even if someone got your first one million public keys, they wouldn't be able to deduce the chaincode.  The same goes for private keys:  if someone has the first N public or private keys, they won't be able to compute public or private key N+1 without the chaincode.

People should not be sharing private keys from their Armory wallets.  Or really, any wallet, except under bizarre/experimental circumstances.  They're called "private" for a reason.

Armory uses the Crypto++ library, which handles all the entropy operations.  I remember once seeing a list of entropy sources used by Crypto++ but I can't find it now.  All that matters is that it "is suitable for cryptographic purposes"  (it is a standard crypto library, though it's kind of slow).


Addresses cannot be linked unless you know the chaincode, which is stored in both full wallets and watching-only wallets.  Without access to at least the watching-only wallet,  there is no way for anyone to associate two addresses or public keys.  The strength of this non-linkage is as strong as the inability for someone to derive your private key from your public key. 



I don't know exactly what you mean... but Armory will generate a new address for you every time you click "Receive Bitcoins", and also when it needs to send change to itself.  I recently started flagging addresses in the wallet properties that were created solely for change.  Some people had asked about how to tell the difference, and there really wasn't a way.  Now all change addresses are marked with "[[Change Received]]", and you can sort by comment field to look through change addresses or non-change addresses (it's not the most useful thing to do, but you can do it).



Armory implements a very minimal part of the networking protocol.  As long as the Bitcoin-Qt client version has the Feb15 protocol upgrade, it will work (which I believe was added in version 0.3.XX.