Ack!  I haven't seen a segmentation fault in a while...

I bet there was a partial-write to the blk0001.dat file, which Armory then tries to read through and ends up with a segmentation fault.   I do have a check for that condition, but it doesn't get much testing...

Honestly, I don't know what to do besides attempting to re-download the blockchain, but that seems excessive and not guaranteed to work if Bitcoin-Qt works fine.  I'll have to get back to you on that one...


Ahh, excellent question!  It does actually use the registry to register itself as the URI-handler for "bitcoin:" links, and I just checked that it does assume default installation location.  I just made a note on my ToDo list for supporting non-standard install locations.

So if you move it around, it will incorrectly set the URI-handler for clicking "bitcoin:" links, but that shouldn't affect general usage (at least not yet).  It won't cause any errors or crashing, it will just disable that convenience functionality.

Three things need to be "available" for Armory to run:

• (1) Armory installed into ProgramFiles directory
• (2) Blockchain in the APPDATA directory
• (3) Armory "home" in the "--datadir" directory

For (1): There is no problem moving this directory to another location. Just be aware that the shortcuts that are automatically created will become invalid.  But you can send the default shortcut to your desktop and change the target to the new location of Armory.exe

For (2): My last post described how it could be done, right now:  but it probably requires creating a two-line batch file and then changing the shortcut to point to that

For (3): Just run with the " --datadir=Z:\appdir\whatever" option (which can be added to the shortcut or batch file)

It should be straightforward to add an option to the installer to "fix" (1) but I will not be doing that on the next release (enough to deal with, at the moment...).  I will add support for (2) in the next release.  And (3) is already supported.

I had multiple requests to make the Armory-home-dir portable (3), so I did that not realizing that such users probably also have non-standard bitcoin installs...

Yeah, odd.  Who has an "A:" drive anymore?

But seriously, 0.56-alpha is "ancient".  It appears that you are, perhaps, running the old version of Armory.  In fact, that version just flat out loads everything in to RAM, doesn't even do any kind of file mapping...

It sounds like there's some shortcuts/links/environment variables that are set incorrectly.  If I were you, I would remove the stuff on the A:, remove Armory, and then reinstall the correct version.  Then make sure that the shortcut you use is pointing to the right place, which will be "C:\Program Files (x86)\Armory Bitcoin Client\Armory\Armory.exe".

Ack!  That's not good, actually.  I wonder if the wallet file somehow got corrupted (hasn't happened yet! but there's always a first...).  Can you now run in online-mode without the wallet?  Create new wallets?  Restart Armory with the new wallets?

If you've got only a few BTC in the wallet, I might just buy it from you and then I can go hex diving to figure out what happened.  (obviously, you'd switch to a new wallet, after that)

What the hell is that?  I am definitely not familiar, at all, with that error.  Can't even begin to imagine what would cause it.  Especially if it used to run on your system and now doesn't...? 

I suspect it's still MMAP-related, and thus will go away with the new version.   I'm working feverishly on it, and will even be taking a day off of work to work on it...

By the way, you should backup your wallet (for sure!) and then move it to a different location then retry offline mode -- I just want to confirm that it is not an issue with the wallet.

While I do think that galambo's statement is silly -- there appears to be plenty of evidence they exist, but not much evidence as to their quality -- I do think your reaction is clearly incendiary and the kind of response that will cause a thread to spiral out of control...

So I just figured that searching a forum does not search the sub-forums.  WTF?  So now that I can search for "BitForce" on the "Hardware" and "FPGA" forums, I have what I was looking for.  So I am locking this thread to prevent this from becoming another slugfest like the other threads!

You can run Armory with the " --datadir=Z:\New\Dir\Armory" to tell it where to put all of the Armory-related data and wallet files.  

However, there is no option for setting where Armory should look for the Bitcoin-Qt/bitcoind home directory.  Armory autodetects based on environment variables -- specifically "os.getenv('APPDATA')" in Windows, "os.getenv('HOME')" in Linux.  Looking at the code now, I don't see why I can't add an option for this, it just isn't in version 0.77-alpha.    I have added to my list of things for the next release -- add a customizable bitcoin-home option.  

Until then, if you are really anxious to try, you can permanently change your "APPDATA" environment variable to point to "Z:\appdata" from the control panel (search for "environment" in the upper-right corner).  

If you are constantly changing your "APPDATA" directory depending on your context, you can dynamically change it from the command-line using the "set" command.  I'm not familiar with the mechanics of doing this through launchers/shortcuts.  You might have to make a .bat file that says

Or just wait a week.  I'll have a major release out with this option added.

By the way, I don't know if I'd call it "infecting"... it's completely normal behavior for programs to make a directory for themselves in the "APPDATA" directory.  Just like programs install themselves to the C:\Program Files" directory.  I agree it should be customizable, but there's nothing wrong with that as the default choice.  I'll look into adding an installer option for these things...



You can be assured that your wallets/coins are fine.  The issue is likely similar to other users who have reported issues -- mmap() in Windows is just bad -- which is why the next major release is a complete overhaul of the blockchain utilities without using it at all!  This will improve load time, work on any system with any amount of RAM, and should handle arbitrary blockchain sizes.  I got caught off-guard by the rapid acceleration of the blockchain size and was not ready to fix it.  My guess is, that there will be more and more users having this issue...

Until then, I don't have a good solution, other than to check the size of C:\Users\yourname\AppData\Roaming\Bitcoin\blk0001.dat and observe if there's a blk0002.dat.  Armory will definitely stop working if that's the case, and the problem will fix itself for 2-3 weeks if you delete all your blk000X.dat files and let bitcoind/-qt redownload the blockchain.  In the next week, I will have the fixed version out.

If you can't wait, you can always run Armory in "Offline" mode and extract all of your private keys (using the "Backup Individual Keys") and import or sweep them using another application.

P.S. -- An extreme alternative is to load your wallet on a linux system/VM, which still runs fine. 

Wherever you heard "GPUs are bad at scientific research" is wholly incorrect.  They're absolutely fantastic for tons of different kinds of scientific and computational activities, but there's a lot of applications where it doesn't fit.  I should know, because I work as a physicist, and we have dozens of projects within the organization that are adopting GP-GPU (general-purpose GPU) programming, and outfitting all of their systems with GPUs.  Myself, I do a bit of GPGPU development for "scientific research."

On the other hand, I will say from personal experience that CUDA -- an NVIDIA-specific GPGPU language -- is much more pleasant to develop with than OpenCL, even though CUDA won't work on ATI cards.  That's why all the computers in all the computer labs where I work have GTX 480/580/680s.  ATI cards will generally perform better with equivalently-optimized algorithms for the target architecture, but the development ease is the issue, not the speed.  If code currently takes 10 minutes to run on CPU, then perhaps we can get it down to 15 seconds on NVIDIA cards or 9 seconds using openCL.  In that case, we're picking whichever arch is the easiest to develop for because the difference between 15s and 9s is like comparing paying $0.15 for a sandwich instead of $0.09... we'll pay the extra $0.06 for the more pleasant experience.

(P.S. -- Do not compare raw power of the ATI vs NVIDIA based on mining speeds:  ATI has some big advantages over NVIDIA that are very specific only to Bitcoin mining; the gap is not nearly as huge for most types of computations, especially double-precision operations which are common to scientific programming and NVIDIA has spent a lot of time optimizing them).

That's not to say that OpenCL isn't used.  Because of the speed of ATI cards, there are a lot of organizations that develop in OpenCL, and prefer ATI cards because they tend to perform better overall.  I think there is plenty of market for GPU-cluster resources, the big question is how are you going to arrange/setup for remote users to access the cluster and charge them for their use of it?.

Good news:  I got the 11.04 VM installed, confirmed the error, and then confirmed the python2.6 package works.   Remove the old package using sudo dpkg -r armory and then install the python2.6 package as normal.

I have no idea why this is.  I will have to do some more exhaustive testing to figure out why this is happening.  Perhaps the 2.7 package should be fore 11.10+ only...

So the first 3/4 of that is normal if you try to "dpkg -i" from the command-line -- you have manually install unmet dependencies when installing using dpkg.  If you instead double-clicked the .deb file from a file browser, it will open GDebi/Synaptic which will handle all that for you.

As for why nothing happens when you click on it... that is not normal at all!  This is the second complaint I've heard about 11.04, which is the one version I don't currently have installed for testing (I thought I did, but it's actually 11.10).  I'm going to create an Ubuntu 11.04-64bit VM right now and see what's going on!

If you could just do me a quick favor:  now that it's installed you can run it from the command line by typing "python /usr/share/armory/ArmoryQt.py" adding " --offline" if you only want wallet management without any knowledge of the blockchain.

Can you try running it both regularly and in offline mode from the command line?  If it fails to open, there will be a useful error message, and then copy it here.  I suspect it's the same cryptic message as molecular mentioned.  If so, I would ask molecular if installing the python2.6 fixed it...?

If you get "GLIBCXX_3.4.15' not found", I recommend removing Armory, downloading the python2.6 version, and then try installing it.  If it complains about dependencies, you can try "dpkg -i --force-depends armory_0.77*.deb".  I'd say maybe I created the Debian package with the wrong version of python, but my package-building scripts auto-detects the architecture and python version and names the output appropriately.  

(Ubuntu 11.04 is downloading right now. I'll get back to you when I get a chance to try it...)

Dig where?  I searching the mining forum for "BitForce" and found like 6 threads, all mostly useless.   The technical discussion and regular discussion forums were also quite useless.

That wait-time is definitely unappealing.

I have searched the forum and found a couple threads with about 2000 posts and a lot of yelling, but I didn't have the patience to dig into it to find anyone who said they've actually purchased and tested a BitForce Single. 

I was thinking that I could sell a few of my power-hungry GPUs and replace them with a BitForce single, but the specs seem too good to be true.  Does it really achieve the stated performance?  830 MHash/s with 80W power consumption, for $600...? 

Also, how difficult is it to get setup and grinding in Linux?

Okay, so here's a problem -- you have a double-stacked blockchain file.  The current blockchain size should be around 1.6 GB, and you just showed me 3.2 MB (blk0001.dat + blk0002.dat).  I would guess that you recently did something and your client ended up not recognizing the original blk0001.dat file and then started redownloading it on top.  So you ended up with a second copy on top.  This has happened to me before...

Armory does not handle this situation well.  Not only that, it only handles blk0001.dat, and doesn't even look for blk0002.dat (due to a poor design decision I made in the first month I developed the underlying library).  I am in the process of fixing this, and will have a fix out soon.  It looks like I got about 2 weeks before a fresh blockchain download overflows blk0001.dat.  It's like Y2K all over again!

Until then, the best thing you can do to get Armory running again is to close bitcoind/-qt, delete both blk000X.dat files, and then restart bitcoind/-qt.  It will re-download the blockchain, but the final product will be 1.6 GB and be contained entirely in blk0001.dat and then Armory should work again...

Is there a blk0002.dat file?

Can you check to see if there is a logfile in your "C:\Program Files (x86)\Armory\Armory Bitcoin Client" directory (my .msi-builder program would not let me put it in the non-x86 directory, even though it really is a 64-bit build).  If there is, there will be an error message at the bottom that you could copy here.

Second, can you check your "C:\Users\<yourusername>\AppData\Roaming\Bitcoin" directory and tell me the size of blk0001.dat. 

Yup, very easy

Just open the wallet you want to add the keys to, then on the lower right there is a button for "Import Private Keys."  It auto-detects the format, handling Casascius physical bitcoins, vanity-gen addresses, and the usual array of standard formats.

You can install Armory whenever (double-click the .deb file and click the button to install it when it asks).  However, I recommend not starting Armory until Bitcoin-qt is running and sync'd with the network (i.e. completely up-to-date with the network and you see the checkmark).  Worst case, Armory will start and and be really laggy as it tries to "drink from the firehose" (i.e. reading and processing 2MB/s of blockchain data being downloaded).  Just restart Armory after bitcoind/-qt is sync'd.

EDIT:  You can use bitcoind or bitcoin-qt.  Both of them do what Armory needs:  which is to act as a single localhost peer that Armory uses as a gateway to the rest of the  bitcoin network.

I think most Armory users just start bitcoind/bitcoin-qt once, and leave it running in the background (minimized to tray).  It stays out of your way, and is always sync'd.  Then you can just start Armory whenever you want and never think about it.

You just reminded me I need to make some supplemental materials/instructions/tutorials for the beta release!

Strange, that's what happens when you use the wrong python version.  Try the python2.6 version.  My 64-bit 11.04 VM actually seems to run the python2.6 binary fine.  There's a good chance the 32-bit version will be the same way...

I must be misunderstanding something here...

Armory wallets are deterministic.  You can produce an infinite number of addresses from a single wallet, and both the online and offline wallets will produce the same sequence.  

Once you have the full wallet setup on the offline computer, and the watching-only wallet setup on the online computer:  you can generate as many addresses as you want with the online wallet using the "Receive Bitcoins" button.  The offline wallet has the private key for every address ever generated by the online wallet, and the online wallet has no private keys.  It's the magic of "Type 2 deterministic wallets"

Unless you are generating addresses with another program, there is no need to import keys at all.  Just use the watching-only wallet the way it was intended!

P.S. -- then your watching only wallet acts as a "monitor" for all those addresses.  You can set comments for each address as they are assigned, or as you create them with the "Receive Bitcoins" button.  If you want to export a list of addresses generated by the wallet so far (so you can import into another application) you can use the "Backup Individual Keys" button.  Uncheck everything except for "Address String".  Then you can save it to file or copy and paste into Excel.

... of course, as I review this thread I see that even if the serial-port solution is done technically correct, there is likely to be mental discomfort with having a physical cable connecting the two systems.  It definitely makes me uncomfortable, even if know that no electrons are flowing...

P.S. - I mislinked in my previous post, I was trying to link to my thread about improving offline wallets. Please go to that thread and revive it if you have more ideas for how to achieve a 100% solution that isn't too complicated.