Okay, I've been battling this for a while now.  I think the virtualenv is screwing me up.  Using Red Emerald's brew formula, I can use run Armory no problem.  Then I use higuys' Makefile and deploy script, and everything breaks.  It doesn't break the system, just the directory.

i.e. It looks like this:

(1) Red Emerald brew formula
(2) python ArmoryQt.py  # works!
(3) higuys' "make osx"
(4) cd osxbuild;  open Armory.app;  #fails!
(5) cd Armory.app/Contents/MacOS/Armory; #fails!
(6) cd ~/src/BitcoinArmory;  python ArmoryQt.py;  #fails!
(7) "PYTHONPATH=... /usr/bin/python Armory.Qt" #works!

So I guess that the virtualenv is linking to the wrong libraries, or bad libraries or something.  

Specifically:  Red Emerald's call (the one that works):


higuys' script executes the following to start Armory (doesn't work):

Gah!  I figured it out -- higuys made the deploy.sh script skip those function calls if the env and Armory.app directories already exist.   And "make clean" doesn't remove them.  So this whole time, all those things I was trying were not executing!

I added removal of those directories to "make clean", and re-ran with just the extra "bin/pip install psutil" call, and it appears to have worked!  I can't believe I spent so much time chasing that down!

P.S. - Actually it doesn't totally work yet, but I'm getting closer...  Just got a "PyThreadState_Get: no current thread" error.  Have we seen that before?

It's not a bad solution.  I just don't have any experience with it.  However, there are quite a few threads and people doing it, and users should be aware that it exists.  But to really promote it, I think I have to create a more "packaged" solution, like a custom distro, or a downloadable USB key image that someone can use.  I think it may be too technical for most users, unless there's a nice pre-configured option for booting from USB with persistent storage (to have Armory installed).

Maybe it's not as bad as I thought, though.  Perhaps if I see a good tutorial on it, I can accommodate it.  For now, I was banking on a lot of people have old laptops laying around, or being able to get one on Ebay for less than $100.  Or eventually I'll have Android support -- I'd love to use old Android phones as offline-signing devices.

Well there's a lot of packages that are needed at runtime.  Twisted is one of them, yet that seems to be covered through the pip-install line. 

I'll try the copy operation...

I did that actually, and didn't see any errors.  It tells me it's installed successfully.  But I wonder if it is installing it in the external system, not the virtual environment.  I can't tell.  Or maybe I need to copy the psutil folder into the Armory.app explicitly, like pyqt is....?

I went ahead and did what I said I was going to try, above.  It appears to have worked.  I'm still curious why my system is different... but I'll live if I don't find out.

My next problem has to do with a new python dependency that has been added for version 0.88:  python-psutil.  It looks like the Armory.app is failing because that is missing that dependency.

Here is the deploy.sh script that higuys sent me.  I tried modifying it by adding the line in blue:


I assumed that is the point at which you are installing the dependencies in the virtual environment.  I also added it the get_dependencies() function as well.  Either way, it still fails find it when run from osxbuild/Armory.app/Contents/MacOS/Armory.

Don't worry about it!  This helps me figure out how I can improve the process.  Glad you got it working, without having to become a linux nerd!  Though, I always approve of more linux nerds...

One more thing, did you actually extract the file?  The file is a .zip file, and needs to be extracted before anything can run.  I would expect it to have the behavior you described if you double-clicked on it while viewing it without extracting it first.

You should be looking at a .zip file.  You can right-click on it and click "Extract Here".  Then it will create a new directory.  Go in that directory and double-click Install_All_Debs.sh.

"Beta" is mostly related to the usability and stability of the interface.  Not the underlying security of the wallet.

At this point, it's getting almost 10k downloads per month!  (used to be 2k, but the recent surge in activity has really propped it up!).  It's extremely stable and in the past 15 months, I've never heard of anyone losing money with Armory except when they didn't make a paper backup!

-- Lots of people have forgotten their wallet passphrase and their wallet became permanently encrypted.  Can be recovered from a paper backup
-- A few people have had their hard-drives fail/corrupt.  You are safe if you have a paper backup.
-- Some people have explicitly deleted files or wallets thinking they know better than Armory what needs to be deleted.  Two people have contacted me about losing coins because they explicitly did this.  They would've been protected if they had made a paper backup.
-- If you want to switch away from Armory at some point, you can "Backup Individual Keys" to write out all the private keys in your wallet and import them into another application.
-- I think some apps have even implemented Armory's paper backup code, so that you can plug it directly into that app and it will restore the keys. 

There's not very much risk involved, besides time wasted if it doesn't work on your system.  It's used to protect millions of dollars worth of BTC at this point.  I haven't touched Bitcoin-Qt or any other app in 12+ months.  A lot of other people haven't either.  The most important thing is to print or copy-by-hand a paper backup, and very little can go wrong.

EDIT: This message does not override the existing license you agree to when you run Armory.  Although Armory is extremely stable, and has never lost anyone's money, that doesn't mean it's impossible.  It's free software, it's still run at your own risk.  Please base your decision on its reputation in the community (such as being featured on bitcoin.org), and don't sue me if something goes wrong!

Don't bother with the command-line until you try the "Run from Terminal" thing.  When you double-click the .sh file, doens't it pop up with a window like this? 




Click "run in terminal".  In fact, I think I will modify the next bundle so that the file is named "Install_Armory_DoubleClick_RunInTerminal.sh"

I'm finally doing this!  I've just spent some time getting an OSX environment setup, and make sure that I can compile and run the latest Armory.

I just hit a snag while trying to execute the Makefile.  I think I understand what's going on, I just want to make sure:

-- I did a "sudo pip install virtualenv" and it completed successfully
-- I type "virtualenv" and I get "unknown command" error
-- I have looked around and found "/usr/local/lib/python2.7/site-packages/virtualenv.py"
-- When I directly run that script in python (bare), it appears to do what I want
-- I found some other references to installing "virtualenv" and running it as it's described in higuys' email and in the Makefile/deploy.sh script

So what's different?  Why is it that I don't get a symlink/executable like everyone else does?  Is there any reason not to just modify the Make file to replace "virtualenv" with "python /usr/local/lib/python2.7/site-packages/virtualenv.py"?

You should double-click " Install_All_Debs.sh and say "Run in Terminal...".    Or maybe you right click and select that.  Either way, the problem is that Ubuntu doesn't know whether you want to examine the file code, or run it as a script.  You want to run it.

If instead, you go to the command line (Applications->Accessories->Terminal), you can "cd" to that directory, and then "sudo sh Install_All_Debs.sh".

Are you using the offline bundle from the website (0.87.2)?  Or the one that I posted recently on the main thread (0.87.95)?

Thanks w1R903!

I will eventually get to making the wallet view more... flexible.  Along with sorting.  I just haven't gotten there yet.  What I will do is have the filter at the bottom, pop up a checklist of your wallets, and you can choose which ones you want to see at any given time.  Of course, with the preset defaults I've got, already.

The problem with QR codes is that there are so many transactions that won't fit into 1 QR code.  Or even 10 QR codes!   Yes, it works for *some* transactions, but certain usage patterns it will not work at all.  Ever!  It's something I've had to battle with every time I look at this problem:  90% will be under 5kB.... but some people will consistently produce multi-megabyte transaction "packets" to be moved back and forth.  I really want to save my effort for a solution that will work 100% of the time!
 

The answer is the usual too-big-to-fathom-answer.  There's 64 bytes on your paper backup.  That means there's [a lot] more possible wallets than there are atoms in the universe.   Your question is essentially whether if you pick one atom in a planet a million times larger than earth, 3 billion light years away, what's the chance that I pick an atom that's even in the same galaxy?   Much less, even the same atom (or within the same cubic mile?)

The first line in the release notes will be about fully removing Armory before upgrading.  I've actually had quite a few people with that problem.  Glad it went smoothly for someone!  I usually only hear bad stuff!


Please do not do this.  Just make digital copies of the wallet, and import them in multiple places.  The wallets are absolutely not "thread-safe" which is what you're doing if you access it from multiple system.  Either make digital copies and import it on multiple systems (with the risk of some address re-use, because some systems don't know that certain addresses have already been distributed), or just make multiple wallets.  Since each one is only one sheet of paper to backup, if you are going to use multiple systems regularly, it might better to keep track of which computer is producing which addresses.

Help me test 0.87.95-beta!

https://bitcointalk.org/index.php?topic=156250.msg1655941#msg1655941

From that thread:


OSX package & signing is next on my list.  Then persistent blockchain stuff!  

Please check top post for updates!  This is starting to look like a real release!  Finally!

https://bitcointalk.org/index.php?topic=156250.msg1655941#msg1655941

I can only spend so much time polishing and trying to catch all the little things.  I think a lot of people are actually having problems with resources, not the auto-bitcoind (and a few with auto-bitcoind). 

Last thing before starting down the resource-reduction path:  OSX packages! 
Then persistent blockchain stuff.

I assume that Windows 98 is too old, but I have no evidence to back that up.  Please try the "windows_all.msi" file and let me know.  I just wouldn't count on it.  As long as it has 128 MB+ RAM, it can run Ubuntu 10.04-32bit, which can be setup in about 20 minutes, and all you need is the offline bundle.  It's possible even without any real linux experience.  But I'll let others comment on whether that's accurate.

Yes, RAM usage and startup time will both drop significantly, at the expense of using more hard-disk.  However, after I complete that transition, I will likely be able to reduce the disk usage, too -- I don't need to store/index all tx in Armory... it's just how it was originally built.   I want to scale that back and try not to duplicate everything on disk...eventually...

Timeframe for the first round (with duplicate blockchain data) is probably a couple weeks.

By the way, I retract my statement about "why use disk encryption when you use an encrypted Armory wallet"?    There's two reasons I came across, one of them I became aware of recently:

(1) If you make sure you do everything on the encrypted partition, you're protected from even carelessness, like copying stuff into another program to print and it auto-saves.  Or you use the Shamir's Secret Sharing script which writes the results to disk.  It basically picks up the slack if you're a little careless with handling private key data.
(2) This doesn't apply to TrueCrypt, but if you use something like Ubuntu alternate installer and select that you want encrypted home partition, it actually sets up encrypted swap, too.  This is super nice, since it effectively negates any defects in my own attempts to keep key data out of swap/disk.  My implementation is the same one used by the Bitcoin-Qt devs, but I'm told it's not bulletproof.  Especially if you ever accidentally hit "hibernate" on your laptop (which will write it to disk even if it's in memory-locked RAM).