I'm not saying that no one has problems with Armory.  But we got 25,000 downloads each of the last two months, and we get only a handful of support requests each day.  Unfortunately, it's still too much, as we need to focus on developing and we're not a customer support house, but we're doing our best to balance everything.

In that particular thread that is linked, we have a problem with certain types of transactions that is affecting at least 2 of the 3 users there reporting issues (which are in this thread).  I suspect this pattern is present across a lot of support requests.   I whole-heartedly agree that we need to get the app working for those users, but they still represent a small portion of our userbase -- those that are participating in pooled mining.  In fact, my neighbor who knows nothing about Bitcoin was able to get Armory running and using it, though she said it took 58 hours to sync.

0.91 is an improvement over 0.90 for sure.  But we don't believe that it's a critical upgrade.

I was not aware that 0.90 was "unusably crash-prone".  If that was the case, I would not have delayed the 0.91-beta release.  What platforms/contexts are unusably crash-prone (besides Mac)?  As far as I can tell, Windows and Ubuntu seem to be working well for most.

https://github.com/etotheipi/BitcoinArmory/blob/0.91-dev/ArmoryQt.py#L796



That's in 0.91-dev and just merged into the testing branch.

Did you try using the "Multiple Keys" sweep option at the top?  It was designed for this

If you don't mind doing one test for us, I just pushed the disablecomments branch to the BitcoinArmory repo.  I removed all the logic I think is slowing you down.  If our hypothesis is right, this will work.  This is the best I can do without getting your watching-only wallet.  


P.S. --

I really appreciate you being so patient!  Seriously, thanks.  Hopefully, as we go back through some other support requests, we'll see that most of them are due to this.  Admittedly, I don't do any mining, or have any enormous tx like this in my ledger (and apparently no one on our team, either).  Also, this did come up 18 months ago, and I made a huge efficiency fix that was supposed to fix it.  But apparently not efficient enough...

Ugh, looks like it worked, but your blockchain wasn't fully up to date.  The 0.4 left is the last three outputs received by that address.

Also, I can see that you did fall into this category I asked about (users don't always know if they are in this category).  Each transaction received by that address has tons of outputs.  The first one has 1,400 TxOuts of which you are only one.

Armory has a known inefficiency when it comes to transactions that huge, and you have a wallet full of them, so that's as bad as it gets.  The good news is most of the processing that's slowing it down turns out to be non-critical (it's for associating address and tx labels with the rows in the ledger), but still important.  We might see if we can find a way to disable it on wallets in this category, of if maybe we can just find a more efficient way of doing it.

For now, sweeping should work as long as Armory is fully synchronized.  Scanning the blockchain to sweep the addresses should work at "normal" speed, it's just populating the main window ledger that takes forever and Armory trips over itself while it waits.

Nope.  Just pull the latest 0.91 and try sweeping again

We literally just fixed a bug in the sweep code, like 2 hours ago.  Pull 0.91-dev and try again.

I'm not convinced this won't work.  If anything it will help debug the problem.  This will probably work for some of the keys, and maybe one in particular it will fail. 

Just in case it has to do with the wallet itself, can you try making a backup of it, then use the menu item "Wallets"->"Recover Damaged Wallet".  Do a full recovery.  Then try it agian (you can do it from offline mode, then restart Armory).

Does your wallet have lots of transactions with tons of inputs and outputs?  For instance, we noted huge lagging when we loaded a wallet that had 100 transactions, each of which had 1,000+ outputs (even though only one output was related to the user's wallet).

I believe the getSpendableBalance errors are a symptom of the problem, not the problem itself.    Rather, the problem already happened before it got to that line. 

Actually... looking at the errors makes me think that you're still using the old C++ utilities.  Like you didn't recompile the C++ code after checking out the latest version.  I see


Those prototypes did change in the latest version and now have a second argument.  Try doing a make clean and make and try agian.

My guess is that it's looking for a header pointer on a zero-confirmation tx.  It doesn't find it, and then the error somehow leads to crashing the readBlkFileUpdate() loop.  We may need to examine how the loop is handling zero-confirmation transaction and make sure there's not any crashing there.

Oh duh.  Offline.  Whoops.

Very interesting about the 12.04.3 vs 12.04.4.  Gonna have to figure out how to adjust our offline bundle releases appropriately.

Goatpig figured out where you can inject additional entropy into the RNG in Crypto++.  I went to go inject entropy path from the GUI to the C++ PRNG and I stumbled on this:

https://github.com/etotheipi/BitcoinArmory/blob/master/armoryengine.py#L7636


That comment was probably written two years ago.  I guess I had thought about it before, but never took the time until now to look into it.  There is actually a AutoSeededX917RNG::IncorporateEntropy function that does exactly this.  There's a few other things that held up the 0.91-beta release, so there's room to get it into that release.

I just ran into an issue with 12.04 myself.  I think on a fresh 12.04 OS, the dependency sources are outdated.  You have to do a "sudo apt-get update" to get the new sources for the missing dependencies.   Try that, and then try reinstalling Armory again.

The bootstrapping takes way longer than I was expecting when I put this in.  But also the bootstrap file is three months old at this point, as is the last checkpoint in Bitcoin-Qt.  I think with 0.9.0 and the updated checkpoint, the bootstrap will be much faster.

However, even with no time improvement, this should cut down considerably on corrupted blk*.dat files. 

This issue is most commonly associated with updating Armory but not rebuilding all the sub libraries.  But we also modified the Makefile since the last version was released, so it's possible we broke something there.  And you said you did a fresh clone, so my first sentence doesn't make the most sense.

Try going into the cppForSwig directory and doing a "make hardclean", then try again.  I will try this on a fresh Ubuntu installation, too.

Turns out there's a bug in the isX64 logic.  It reports the python build, not the CPU architecture.  Since Armory was built with all 32-bit libraries on Windows, I believe it always reports 32-bits there regardless of CPU architecture.  You can safely ignore that.

New stuff for 0.91-beta!

Finally ready to lock down the feature set for 0.91-beta.  I posted a testing version a couple weeks ago, and then some internal discussions revealed it was actually possible (and easy) to integrate BitTorrent into Armory to dramatically improve the initial synchronization!   But that's not it: we are now running 30+ seedboxes to make sure there is sufficient seeding power for... a lot ... of users simultaneously.  The joys of being a company with capital to make such investments! (and really, it's not terribly expensive)  

And yet there's more!  I had been meaning to update the announcement system for a long time, and never quite had the motivation to do it.  With the necessity to periodically update the bootstrap.dat.torrent file, I decided now was the time.  

Armory now has a hard-coded offline signing Bitcoin key, that is used to sign all announcement data, including torrents, upgrade info and alerts.  This channel is protected to the same level of security as the releases themselves.  It will be used sparingly:

• URLs, hashes, changelogs for all new versions of Armory and CoreBitcoin.  This made it possible to also integrate a "Secure Downloader" that downloads installers and verifies signatures for you!
• Notifications list for critical announcements and alerts (including low-priority testing announcements if selected in the settings)

It's all stored in an announce file which is periodically retrieved by Armory.  If the announce file has no valid signature, it's as if it doesn't exist.  Similarly, when data is downloaded, it must match the hash in the announce file, or it will be discarded.  All text files will, themselves, be in Armory signature blocks, and can be manually verified in Armory via Tools -> Message Signing/Verification from the main window.


tl;dr

• Automatic usage of torrent and Armory seedboxes to bootstrap a cold start.  I downloaded the blockchain at 4 MB/s on my connection! (unfortunately, bitcoin-qt still takes 2-3 hours to process the bootstrap.dat, but the total time is still faster for most, and much more reliable)
• Armory works even if the torrent library is actually removed.  I don't think most people would care, but just in case... remove the BitTornado directory and it will sync with the network normally via Bitcoin P2P.
• Secure downloader provides a secure way to update Armory without using GPG.  This even includes the ability to "Save with offline-verifiable signatures".  This means you can create a .signed file to take to the offline computer and it won't even write the package to disk unless the signature is valid.
• General notifications:  We finally have a way to issue critical security alerts if the need arises.  Can select the threshold in the settings, including a "testing" mode, which we might use to communicate with people actively helping test.

We are still tweaking a few things, but otherwise the testing version is about ready to go.  It's on 0.91-dev if anyone is willing to help sanity check that all the files are committed, etc.  Will merge into the "testing" branch and make Windows and OSX installers in the next two days.  I will also start another testing thread (with bug bounty!) when we do.

P.S. - If you run with 0.91-dev right now, you'll need to use --test-announce to see the announcements, downloads and use torrent.  And they're all fake at the moment (except for the torrent), so it the actual information displayed isn't all that meaningful.  The Armory downloads for Mac and Ubuntu should technically work, but may not download anything actually useful (though you can test the offline-verify-signature feature)

We never encourage doing this, but Armory encryption is about as good as it gets for these things.  The key-stretching on your password is not only designed to make it expensive to crack passwords, it's actually designed to use tons of RAM so that GPUs have a much smaller advantage brute forcing them.  GPUs will probably still be faster at password cracking than CPUs, but probably only 20x faster instead of 1000x.  

On our website, we have posted a presentation I gave on security best practices.  You might consider looking at slides 41 and 42:

http://media01.bitcoinarmory.com/InsideBitcoins_Present.pdf

It illustrates what key-stretching means, and shows some numbers for what kind of resources would be needed to break a password of a given length.  And that's with default settings.  If you are going to do this, I recommend that you use the advanced options when you create the wallet, to increase the RAM and compute time.

In conclusion, if you are going to do this, raise the advanced encryption settings, and use a strong password that is more than 12 characters.  If you are not so concerned about physical security, write the password down and keep it somewhere that is accessible but not obvious.  You really should only use this as a secondary backup method, to other unencrypted methods.

---

Though, I would still encourage you to skip this exercise and simply manage your backups with M-of-N.  You can think of M as the security of the backup, and (N-M) as the redundancy (though I would argue that M=2 is nearly as good as M=3 or M=4--all of which are enormously better than M=1).  The point is, you can use a high N-value to protect yourself from losing too many fragments.  

Earthquake zones can do a lot of damage, but it's also not going to utterly destroy everything in a 50 mile-radius.  You can be comfortable that some of your fragments will survive if they are appropriately distributed.  So something like 2-of-5 would probably suit you well.

Here's my thoughts:  if Crypto++ has a way to inject supplemental entropy, I'm all for doing that.  As picobit pointed out, it can't do any harm, it can only do good.  If that's the case, there's no reason I can't add various user-generated values to the entropy pool (such as the number of microseconds between mouse clicks, uninitialized RAM states, hashes of various system files like /var/log/Xorg.0.log,  etc).  A few of these together are probably even sufficient entropy alone.

My main concern was messing with crypto libraries, that have already been thoroughly reviewed and tested.  In my mind, digging into any of these things is very risky, and I'm not exactly qualified to do it. I risk unbalancing a solid RNG implementation.   But if there are channels built-in to insert extra entropy, I will act on your suggestion.