Log file please! 

I'm not sure what would be causing that, besides the dreaded corrupt blockchain database in Bitcoin-Qt.  I haven't heard of that happening a while... i think the core devs must've cleaned that up pretty well.   If you don't mind spending the time and bandwidth, maybe you could try it for me... just let bitcoind redownload the blockchain.   THough you did say it was a fresh install, so I doubt it...

Either way, please send a logfile to support@bitcoinarmory.com!

@els & anyone else having problems with the windows build:

I just noticed I file missing from the package.  Both in the installer and the standalone.  I have added that file (msvcp90.dll) to the standalone directory and re-zipped it up for you:

https://dl.dropboxusercontent.com/u/1139081/ArmoryTestingReleases/ArmoryStandalone_0.89.99.10_w_msvcp90.zip

Please try again.  I actually have a strong feeling that will resolve it.

It's complicated. And ironic wording... sorry about that.

It's easiest if you just run it yourself, if you don't mind running it yourself.  If you do, then go to "File"->"Settings" and uncheck the first checkbox about letting Armory run it for you.  Then close Armory, start Bitcoin-Qt/bitcoind, let it synchronize, then start Armory.  It should behave a bit better.   Apparently detection of Bitcoin-Qt installation is still not as good as it could be...

Is it installed?  Did you simply download a zip file and unzip it somewhere?  Did you install to a non-standard directory?

That should be correct.  Hope you got a big thumb drive though.  A lot of block data...

Not sure about the paths with spaces.  They are always a problem, everywhere.  I try to handle it, but it really is a painful process.

runeks, I probably forgot to respond to your other post.  Sorry about that. 

The problem is either

(1) Change the "filter" in the bottom-left of the main window to show "All wallets" instead of "My wallets"
(2) Go into wallet properties, and changed the "Belongs to" field and check that the wallet is "mine"

This is to avoid users importing malicious wallets and thinking the balance belongs to them.  They have to do a little bit of work for Armory to show them the balance.  Hope that's the issue.

If anyone has experienced the disappearing tx behavior, where a zero-conf tx shows up in the history but then disappears when it it's included in a block... please send me your log file!  And especially if you remember when it happened, so I can try to locate an error message in the log file.  The problem is that I'm not sure there even is an error message at all.  So, if I don't know where to look I don't know for sure if it's there or not.

I have some strong leads on this bug.  But I'll have to reproduce it eventually, to know for sure if I fixed it!  If anyone can reproduce it reliably, any info about that would be fantastic.  (I've definitely seen it once before, but hoped it might be fixed with some of the other DB updates).

Send all log files to:  support@bitcoinarmory.com

Very strange behavior, can you send me a log file?  Personally I've never seen it show connected & balances, but not also say "Armory is Online" on the dashboard.  It's almost like you somehow have a mixture of multiple versions...

Also, you should consider running Bitcoin-Qt yourself, and uncheck the first checkbox in the settings (about letting Armory run it for you).  Then try again -- sometimes it just doesn't do the auto-bitcoind well..

Those three options were added in 0.89.99.10. 

Since I messed a bit with the DB ops, go ahead and do a rebuild if you don't mind waiting for it.  From the help menu "Rebuild and Rescan Databases".  Let me know if you have the same problem after that.

I wonder if maybe things were updated on OSX 10.9 between the last version and now.  Because I didn't really do anything differently.  The only thing was that I installed the latest updates on 10.9...

As for reliability of this version:  I have to give the usual caveats about it being a testing version of beta software.  But it has proven to be quite reliable.  And I've been using it exclusively for the past month.  However, the backup system is still only 99% complete.  I've got some more testing to do on it before an official release, but I'm fairly confident it won't change (but we have some more tests to run, and I want to implement a way to test all fragments at once).

I am comfortable using it for offline transactions, for sure... because the offline computer (running a stable version) would  catch any issues with the tx created by the new version -- but so far there hasn't even been a hint of a problem with hot wallets, etc.

I have one more major bug to catch, which results in zero-conf transactions disappearing from the interface when they are included in a block.  It doesn't happen to all tx, and they should reappear when you restart.  But it can lead to incorrect balances which can be somewhat dangerous.  It seems that all the other bugs are simply usability issues, which I'll have to live with for now.  I think the combined usability problems of this version still sum to something far less than the problems with the old version with the RAM consumption...

Also, if you run across the following error in your logfile:


please stop Armory and make a backup of your database directory.  Then rebuild.  I will find a way to get a copy of the DB from you so that I can debug it.  But doing a rebuild should fix it in the short-run.  (sadly, I even caught this bug in my windows debugger, but accidentally did a rebuild over it.  D'oh!),

Rogue Star & els,

I just dumped a "standalone" version into dropbox.  It should be exactly the same as the installed version, but it hasn't gone through the NSIS installer-builder process.  I want to see if that makes a difference.

https://dl.dropboxusercontent.com/u/1139081/ArmoryTestingReleases/ArmoryStandalone_0.89.99.10-testing.zip

Just unzip and double-click on ArmoryQt.exe.  Let me know if that works. 

P.S. - I wonder if maybe the presence of 2008 redistributable is actually hurting you.  Total longshot, but possible.  Since I changed compilers, I doubt having that installed would benefit you (though there may be other reasons you have it installed)

Oh, I haven't been building the Debian packages, but it's actually pretty easy, so I don't know why not.  I just built the package and put it in Dropbox:

https://dl.dropboxusercontent.com/u/1139081/ArmoryTestingReleases/armory_0.89.99.10-testing_amd64.deb

It is signed by my online GPG key (not the offline key, but better than nothing).  Use "dpkg-sig --verify armory_0.89.99.10-testing_amd64.deb" and check that the signature is valid for key FB596985.  You may have to install the "dpkg-sig" package first ("sudo apt-get install dpkg-sig").

If you are on 64-bit Ubuntu-Debian, please try it and let me know if it works for you the same as building it yourself.

Perhaps there's some kind of MSVC redistributable to be installed.  In the past, there was a couple users that needed the MSVC 2008 Redistributable installed, when I was still compiling with MSVS 2005.  Perhaps goatpig has some ideas...?

Update:  0.89.99.10-testing

Windows 0.89.99.10-testing:  Download the NSIS installer
Ubuntu 0.89.99.10-testing:  checkout and build "testing" branch (see instruction in first post)
Mac/OSX 0.89.99.10-testing:  Download the ArmoryQt.app for OSX

What's new:

• (1) For my life, I cannot figure out the orphan chain bug.  It is very complicated to debug even with the tools I've got right now.  Instead, I work around it by detecting it and rebuilding the databases when it happens.  This won't solve it for everyone, but it does happen most often if a build/update is interrupted, so perhaps it won't be an issue if you're nice to Armory  For now, I don't see another way that gets me to a release in the near future.
• (2) Thanks to CircusPeanut, this version of Armory detects non-standard signature padding and corrects it before broadcasting!  If you had trouble broadcasting transactions from an offline computer runnning an old version of Armory, updating the online computer to this version will allow your offline tx to work again!
• (3) Goatpig helped update the "bitcoin:" URI-handling in both Linux and Windows.  I have no idea if it works:  try it!  (both with Armory open, and without)
• (4) Added three new items to the "Help" menu:
      "Clear Unconfirmed Transactions" (mempoool.bin)
      "Rescan Databases"
      "Rebuild and Rescan Databases"
  All three operations require restarting Armory, and signal to it by touching a file in the ARMORY_HOME_DIR -- meaning you can do it yourself externally.  You can simply touch "clearmempool.txt", 'rebuild.txt' or "rescan.txt".  The file will trigger the appropriate behave and then be deleted so it doesn't trigger on the next load.
• (5) Added a popup to warn users about sending money to their Armory wallet without ever getting online first.  This should prevent users dumping money in before they realize that it doesn't work on their system.
• (6) Fixed the "memory pool file is corrupt" messages on Windows.  It should now successfully save zero-conf transactions between loads.
• (7) If a rebuild operation is interrupted, Armory usually picks up where it left off when it restarted... but the meter would reset to 0% giving the user the impression it is starting from scratch.  That has been fixed.

News on OSX:

The OSX recipe prepared by picobit that i used to compile the OSX testing version, appears to be pretty unreliable on some systems, with lots of crashing.  It appears that, with enough effort, you can eventually get out of Armory what you need, but will likely involve lots of restarting and rescanning.  

The good news is that it appears this is a known problem affecting the combo of PyQt4 & OSX 10.9.  Not sure when there will be a fix, but even without fixed PyQt4 binaries, I might be able to work around it (it has to do with nested modal dialogs).  Therefore, I suspect the issue is not picobit's recipe -- even if I rebuilt higuys' package for 10.9, it would likely still be unreliable.

Message Signing!
Almost... should be in the next testing version.  I hadn't planned on including it in this release, but getting this release out has taken so long that it gave me time to delegate that integration to CircusPeanut.  Will include a Bitcoin-Qt compatible version, as well as an Armory-specific version that is based on RFC2440, so I'm hoping that others will feel inspired to support it (it's makes much more sense than the bare signatures).

Don't delete it!

Both are needed.  Right now.  The easiest implementation for RAM reduction was to move all the operations from RAM to disk, and I required a full index of everything.  This also gives me the opportunity to have a remote instance of Bitcoin-Qt/bitcoind running, and Armory maintains its own block data.

Once this version is stable, I can implement a much lighter version, which doesn't store/duplicate the entire blockchain.  It's just that Armory currently assumes it has full access to everything, and I didn't want to have to battle those things with this overhaul.  Plus, as I said, there's a use case for the full DB version.

A future version will not duplicate all data.  The default will be to store a much lighter version of the DB and request data from Bitcoin-Qt/bitcoind if needed...

When you restart online Armory, does it still show your 200 BTC transaction with zero-confirmations?   There is nothing to do on the offline computer, this is solely an issue with the process of sending your already-signed transaction to the network -- it didn't quite get there. 

If the transaction still shows in Armory with zero-confirmations, follow the directions in my previous post about closing Armory, deleting mempool.bin, and then restarting it.  If it's not there, then just go ahead and broadcast it again. 

(1) O(sqrt(N)) is not "broken".  It's like saying that O(N²) is crackable but O(N³) is not.  They're both polynomial.    You just double your key/block sizes once, and you've forever stunted QCs back to where classical computers were.  It's quantum-resistant because it's still easy to choose key/block sizes that are secure.

(2) QC number factorization is a different process, and the gains are much more powerful.  It's actually turning a super-polynomial problem into a polynomial problem.  I.e. factoring numbers on classical computers isn't quite exponential, it's about O(e^cuberoot(N)), but is about O(N³) on a quantum computer.  The O(e^cuberoot(N)) is prohibitive, as it's easy to pick reasonable key sizes that would take billions of years for a classical computer to crack.  But O(N³) can't really be outrun.  A crypto system that relies on O(N³) being hard is broken.

Someone just reported a problem with "Too many open files" when running on Ubuntu 12.04, 32-bit.  This is only printed to the terminal, though, so it doesn't show up in any log files.  Its symptoms are all sorts of weird behavior on your system, outside of Armory.

He ran "cat /proc/sys/fs/file-max" and it returned a number around 700k.  On my 64-bit system it returns 3.2M.  I wouldn't expect that to be exhausted from our "little" blockchain database, but I guess it is (bitcoin-qt/bitcoind is also running a leveldb database, as well...).  I also found mention of systems with large databases running out of files.

The solution (still being tested)

(1) Reboot.  You're kind of hosed once you get to here
(2) Remove the database which probably go corrupted "rm -rf ~/.armory/databases"
(3) Increase the number of files:  "sudo sysctl -w fs.file-max=5000000"
(4) Restart Armory

If this works, you can make it permanent on reboot by appending the following line to /etc/sysctl.conf


Hopefully that helps.  Though it does concern me that this is even a problem...

Start Armory with the " --datadir=/path/to/armory/dir/with/wallets"

Similarly, you can move the Bitcoin-Qt/bitcoind home directory by starting bitcoin with " -datadir=X" and starting Armory with " --satoshi-datadir=X" (replace X with the path)