Interesting.  What's your system specs?  A few others have reported 30 minutes to build the database on OSX, which is actually faster than it's been working on my Linux system!  (about 40-50 min).  There's also a scanning operation after that, which is 10-20 min.  After that, it shouldn't need to rebuild or rescan again and should start up pretty quickly (unless you restore wallets or import private keys).

Just to clarify about the OSX version I just made available through dropbox: that version was built by me, not picobit.  I used his script to do the building, but I reviewed it and confirmed that it's building directly from the github repo and downloads the build dependencies from standard locations. 

If this version is like the previous version, it should work 100% when it works (besides the fact that it's the new testing version with a few usability bugs).  I'll let people report their experiences with it, but I would guess it can be trusted as much as the Linux or Windows testing versions.   Those versions are pretty solid, besides the usability issues. 

So usual caveats about "testing version: use at your own risk", but I don't see a reason to trust this version less than the other ones already being tested.

Well just because it works on OSX, doesn't mean that the database/build/scan bugs are fixed.  I still have a lot of work to do on that front, but at least I have the tools now to debug it easier...

Unfortunately, one of the caveats of picobit's solution is the difficulty of passing command-line arguments.  I might "hack" something that will work from the menu:  Armory will check for a "rebuild.txt" or "rescan.txt" file at startup, if it finds it, it will delete it and then do the rebuild or rescan.  The menu option will simply write the file and then close the app.  This makes it fairly simple to force the rebuild or rescan, and also make it easy to induce it from within the app (I had problems before, trying to force this to happen after the app was already running). 

I'll make sure that's in the next version.  Unfortunately, we'll still need a real solution to the CLI-argument issue, since you can't set the --datadir this way. Though, for everything else, I suppose I could use an armory.conf file just like the bitcoin.conf file...

For reference, cypherdoc emailed me, and the problem turned out to be that he used the PPA method to install the "bitcoin-qt" package, but did not install the "bitcoind" package which is required if you use the default setting "Let Armory run the Bitcoin software in the background".  Apparently that worked.

Also, if you aren't following the RAM-Reduction thread, I just posted the output of Picobit's new build process.  Please try it out!

https://bitcointalk.org/index.php?topic=299684.msg3472728#msg3472728
Direct download of Armory.app: https://dl.dropboxusercontent.com/u/1139081/ArmoryTestingReleases/Armory.app.0.89.99.9-testing.tar.gz

So far I'm hopeful that it is more robust than the one on the website.  If so, that means that version 0.90 will have:
(1) Dramatically reduced RAM and startup times
(2) Full backup center with fragmented backups and SecurePrint
(3) Full support on OSX, including 10.9/Mavericks.

I can only hope, though... please test!

Yay picobit!

https://dl.dropboxusercontent.com/u/1139081/ArmoryTestingReleases/Armory.app.0.89.99.9-testing.tar.gz

That 40 MB tar.gz unpacks into a 136 MB Armory.app directory, which should be double-clickable to run Armory.  I successfully compiled it on my MacMini, after review the build-app.py script that picobit gave me, and then successfully running it.  There was a few hiccups in the build process, but it ultimately worked.  And kudos to picobit for not only giving me a script, but being diligent about creating and sorting log files for each command so I could easily figure out what went wrong.  

Please test it on your OSX system.  Especially on 10.9, and especially on any systems where the download from the webpage didn't work.  I want to find out if this .app works better than the one we originally got from higuys.  I'm hopeful based on els' statements that it worked on both 10.8 and 10.9, but I definitely need more empirical evidence.  

By the way, this is actually 0.89.99.9.  This has a feature merged in from CircusPeanut that fixes the broadcast issue people experience when using older versions of Armory on the offline computer.  The issue was that the core devs implemented a soft-rule requiring normalized signature padding, and older versions of Armory didn't do that.  Thus when you sign with the older version, the tx will be rejected if you are running Bitcoin-Qt/bitcoin 0.8.2 or newer.  This version works around that by exploiting the same transaction malleability that the core devs were trying to reduce!  It adjusts the signature padding of the already-signed transaction -- it changes the hash of the transaction but makes the transaction not only valid, but isStandard() so it will broadcast correctly.  

If you are experiencing that broadcast issue, you can:  (Linux) Pull the latest testing branch and use that (OSX) Use this .app (Windows) Wait for the next testing release.  

Whoops, totally posted to the wrong thread!  Please ignore this post...

[Post relocated to the correct thread]

Just to be clear, the issue is not the maximum size of a single transaction.  The issue is that in order for the offline computer to verify the transaction fee, you must supply every, full, supporting transaction along with the one to be signed.  The offline computer must see the tx associated with every input, so it can verify the value of each input.  Therefore, if I send you a few dust outputs contained in 100 kB transactions, then you will potentially be moving 0.5 MB of tx.  Even without me doing anything, I"ve had people report issues because they use their offline wallet to collect lots of small payments over time and then end up with 271 inputs at once.  Those are multi-megabyte transactions.  The single QR codes are just not scalable for this, requiring me to develop something that can handle wider bandwidth for those cases, anyway...

Technically, there's a trivial hard-fork solution:  https://bitcointalk.org/index.php?topic=181734.0 ... but I don't have much hope of it being adopted.  

Personally, I think this is an ideal steady-state solution once the offline system is setup.  But you can't use plain QR codes, you'll have to do QR videos.  If you have to move 2 MB to the offline computer and back... you really want those 100 QR codes to be cycled at 13.82 Hz (or any frequency that isn't a multiple of the other device sampling frequency).  Though even then, your arm might get kind of tired holding it up while it acquires all the images.  Meh. 

But there is still the concern about getting the system setup in the first place.  I guess if you have a custom OS image with the camera software pre-installed, you could use the QR thing to move the Armory offline bundle intself onto the system. 

Yeah, we really need to come up with a set of best practices, so people have some kind of guidance...

Mac is definitely a high priority right now.  I also should put in an informational channel to communicate with users like "Armory does not yet work with OSX 10.9.  If you upgrade you may temporarily lose access to your Armory wallet". 

Things like Windows XP and obscure (err... less-popular) flavors of Linux will be lower priority for now.   Luckily, goatpig has helped out tremendously with Windows in general, so I'm down to just a couple bugs left (though one is going to be a pain to fix), and then OSX support.  I'm going to make it my mission to try to get picobit's OSX solution working before the end of the weekend.   We'll see where it goes from there.

It sounds like goatpig might have a decent XP solution, but I will leave it to those who really want it to try to get it working.  Too many other things for me to worry about right now.

To be clear, I have nothing against accommodating those OSes.  It's just a matter of priorities.  If we can support it, I'd be happy to, but I need to get some of the more critical usability issues out of the way, first.

It might be a wallet filter issue.  If you haven't marked some offline/watching-only wallets as your own (in the wallet properties), they will not be displayed by default.  This is part of a mechanism to prevent people from importing arbitrary watch-only wallets and then thinking they own the coins.

You can change the filter in the drop-down box on the bottom-left corner of the main window.  Let me know if that's not your problem.

In many ways, I have designed the system assuming the online system is compromised, but without the ability to spread USB viruses (easily).   As long as you check very carefully on the offline system that the amounts and addresses are what you expect, then it's an exceptionally safe setup (because we've assumed no USB viruses like this).  The data that is transferred over USB is public, non-sensitive, and contains everything the offline computer needs to fully verify all the details of the transaction.  I had even considered an operational mode where people could run just the wallet, and then send their watching-only wallets to a server, and the server would prepare the transactions for them to sign (for the people without the resources to run Armory online).  I could provide such a service confidently, because it would actually be a very safe system -- the downside would be how easy it is for the server to feed bogus UTXO information and effectively DoS the wallet (every signature produced would be invalid, thus making the system unusable -- but better than losing coins!).

So, under the offline-system-is-secure scenario, the worst that happens is having your transactions become invalid (though, you can lose coins because you didn't verify the addresses and amounts on the offline system before pressing "sign" -- the virus could exploit someone simply being non-attentive).  If the offline system is compromised, then it would be a pretty advanced virus (jumped through hidden data on USB), and thus should be sufficiently advanced to shuttle private key data back over USB.  Or hide data in transaction malleability.  Or if both systems are compromised, it just flat out jams the private key into the signature space, and tells you it's valid, and the online system recognizes and sweeps the funds to the attacker before you've even realized your broadcast transaction is invalid.

Because of this, it's worth visiting how to minimize damage of an offline computer compromise, but it's a very difficult problem and one I can't claim to solve.  Use anti-virus on your online computer, dedicate a small USB key to be used for only offline transaction shuttling, and really check all the addresses and amounts of the transactions before signing.  Also, if the transaction is sufficiently large, I recommend making a phone call to the recipient to manually verify the addresses.    This will keep you from being "low-hanging fruit" to the next piece of Bitcoin malware

The problem with QR codes is they aren't big enough.  They're big enough for 95% of transactions, but the first time you have to move 1 MB across that channel, you'll be SoL.  And you don't have control over it.  If I know one of the addresses in your offline system, I can send you a couple 100 kB transactions, and effectively DoS your offline solution.

There's a discussion thread about it here:  https://bitcointalk.org/index.php?topic=68482
And ironically: https://bitcointalk.org/index.php?topic=135423.0

But none of it is ready yet.  Though goatpig claims to be making progress on the audio solution.

I should clarify though: the article doesn't say that computers will be infected through audio or power-line communication.  But if your offline computer is already infected, it can use those methods to communicate with another infected machine.  It does sound the stuff of science-fiction, and I'm conflicted about whether to believe this is a real threat (since there's conflicting evidence).  But it does give us some hints about ways we can protect ourselves better. 

I would argue that assume-the-offline-system-is-already-compromised-by-the-most-advanced-malware assumption makes security a mostly intractible problem.  There's too many ways for a properly-secured-but-compromised offline system to leak information.  And depending on how good it is, it might only need one transaction to do it.    The best thing we can do is take appropriate precautions to minimize risk of infection, and be able to detect it when we fail.

Now that ATI has some money, we'll be spending some of it to get some real good crypto/security guys to help us shape our best practices to address threats like this, even if this particular one turns out not to exist [yet].

Still 0.88.1 from the website.  Feel free to help test this version, but I'm fairly certain that the crashing bugs are bit too much for most people.  I finally caught the biggest one in the debugger, but it doesn't look like it's going to be easy to fix.  So it may still be a few days...

At one point I added rescan and rebuild buttons, but they didn't behave properly.  I decided that they needed to occur before the app loaded.  With some luck, these upcoming bug fixes will require that a lot less frequently.  Or I'll find another mechanism to do it.

The makefile was updated by goatpig to do a more-intelligent search for the python dependencies.  It's very possible that you may need to just branch that whole section if compiling on OSX/Darwin.

When it crashes on unlocking, it's definitely a wallet corruption issue.  Technically, it's possible for us to do a raw binary-extract-and-recover operation in the code, but it isn't ready yet.  We'll get it eventually.  

For now, the best thing you can do is make another backup (for catastrophic recovery), then go into wallet properties and "Delete/Remove Wallet."  Then restore from whatever backup you have.   That should resolve the issue.

There is a known problem using older versions of Armory to sign transactions, causing errors when attempting to broadcast.  We have a fix for that which will be integrated into the next testing release.  But that doesn't sound like your problem.  You can verify it's wallet corruption by attempting to make a paper backup, which will also require typing your password.  If it crashes there, then it's corruption.  If you actually get to the print-backup screen, then it's a different issue.

If you do see the paper backup screen (and thus not wallet corruption), then please go to "File"->Export Log File and send us the output.  support@bitcoinarmory.com.  Thanks for your patience!

Yeah, so far everything has broken on 10.9.  Picobit gave me a script for building a more-standalone version of Armory on OSX, which should hopefully resolve this problem on most versions of OSX, and hopefully Mavericks, too.  And hopefully we'll get a new guy soon that will be better experienced with OSX in order to battle these OSX problems.

I just caught the "Marking Orphan Chain" bug in the debugger, which I've been hoping to do for days!  If I fix that bug, then I'll be under a lot less stress and can maybe take a shot at this.  Stay tuned and thanks for being patient!

Unfortunately, that sounds like a corrupt wallet.  It fails when trying to unlock.  Do you have a backup? 

We're actually working on a tool that helps recover from corruption, but until then we kind of have to do it manually... unless you have a paper backup.  If you do, make a digital backup of the old wallet first, "Delete/Remove Wallet", and then from the main window, "Import Wallet" and "Restore from Paper Backup."   It will have to rescan, but then you'll have your coins back.

No offense to Dabs (sorry Dabs!), but I'm not convinced there's a reasonable cost-to-benefit ratio for this past a couple hours of work.  For every day that we spend on it, the number of potential XP users in the world shrinks by 2%...


EDIT:  To be clear, please take a shot at doing it.  I just don't want to spend a lot of resources working on it, because there's other priorities.   Well, assuming your priorities are aligned with mine

It might be possible to merge the .dlls from the old 0.88.1 release which was compatible with WinXP, with the new version with all the Armory code compiled using the XP toolset.  But that could be a mess and might not end up working.  I'm afraid that our move to MSVS 2012 may have shut out Windows XP users.