Yeah, unfortunately, we're still not quite sure how to do the CLI thing... may have to add an armory.conf, which should probably be added anyway.  Doesn't help with changing --datadir, but helps with everything else. 

This build is really more for testing... we will clean up those rough edges when we determine that it's usable.  So far, it seems the jury is still out on that one...

On an unrelated note, please try the new OSX build!

https://s3.amazonaws.com/bitcoinarmory-releases/Armory_0.90-beta_OSX_test1.tar.gz

---

Now that the conference is over, I took a stab at OSX.  I finally got it compiling and running!  But, I don't have the full blockchain on my Mac, so I can't really test it...  Try it out!

https://s3.amazonaws.com/bitcoinarmory-releases/Armory_0.90-beta_OSX_test1.tar.gz

I got stuck when nothing I tried worked.  I tried like 3 examples from various websites and documentation, and I never got sound out it.

If you want to take a shot, please do.  Linux is easiest though, since the dev environment takes 4 commands to get setup.   Windows... is pretty terrible to get setup, even just for messing with the python libraries (not compiling any C++ code)

Just so you know, the main ledger does use address comments.  It first looks for a comment associated with the tx ID.  If there isn't one, it looks for the comments associated with any of the output addresses and displays that. 

I can look at adding it to the tx viewer, as well.  Though, that table is already cramped enough.  I guess you'd ideally be able to customize which columns you want.

No way to do this currently.  The coin-control feature is really "address control", with the intention of providing a way to decide which addresses get linked, not individual transactions.  However, if you select an address and both Tx are different size, you can create a tx using the exact amount of the one you want to spend, and Armory will likely pick the correct one.  If you choose "Create Unsigned Transaction" instead of just hitting "Send", you can review the tx to confirm it did the right thing.  

If you want to spend a 1 BTC output but you are sending someone 0.4 BTC, then create a Tx with two outputs, 0.4 to the recipient, then use the address book to manually get a new address from the current wallet and send it 0.6 (or 0.5999 if you have a 0.0001 fee).  You are basically doing Armory's job manually (for creating change), and Armory will realize it doesn't need a change output.  It will also likely select the 1 BTC input.

Start Armory in offline mode.  Then import as many wallets as you want.  Then close Armory and start it again regularly.

Nope, the DB is just duplicating the blk*.dat files (but in a different format).  In the future it won't be pure duplication, but either way it will allow for remote Bitcoin-Qt/bitcoind connections instead of using localhost. 

After the DB is built, there shouldn't be a lot of bandwith moving back and forth.

Theoretically yes.  However, i've had reports of problems with the 12.04-64bit offline bundle.  It appears to work even after it displays a bunch of errors.  But it's not obvious that it worked.  There's no issue using the 32-bit version, though.

As Holliday said, you there's some tradeoffs to be made.  Luckily, the latest version should run pretty smoothly once set up.  We have had reports of problems, but it seems most people are successful.

By the way, you can use --dbdir=X to move the 14 GB of database files elsewhere. 

The first-time startup uses about 1 GB of RAM while building the databases, and might take a 1-3 hours after bitcoin-qt finishes synchronizing.  After that process is done, it will all be much smoother.  Starting up should only require Bitcoin-Qt sync'ing, but it will load all the histories from the DB to avoid rescanning (unless you unclean-shutdown).  I also plan to make that 1 GB configurable in the future.

Feel free to send us a log file, to support@bitcoinarmory.com.

Log file?  

Also, did you recently add a lot of addresses, wallets, etc?  There's a known problem if you have tons of addresses, it can be slow when new blocks are coming in.  That's going to be fixed in 0.91.

Also, try "Help"-> "Rebuild and Rescan Databases"

The restore dialog has automatic error correction.  If it can't correct the error, it will notify you that you typed it wrong.  Usually it notifies you that it fixed an error, but it may not do it if it's in the last couple letters.  If you change a letter in the middle of a line, it may tell you.

More specifically, you can go into the settings for Armory, and disable "Let Armory manage Bitcoin-Qt/bitcoind in the background".  Then Armory will expect you to run Bitcoin-Qt or bitcoind manually, and that it will be open and synchronized when you start Armory.

This will give you greater flexibility for managing both apps.

By the way, we will have a mostly-complete armoryd.py soon.  You might consider looking at that (in a week or two), as it should have most of the same functionality as bitcoind, but with Armory wallets (including watching-only wallets, etc).  Also we recently added a page about Python Scripting with Armory

The first issue is on our list of bug fixes for the immediate future.

The second one is more complicated.  We switched from using MSI files to use NSIS .exe files for the installers.  This has proven to be more difficult in terms of signing.  I can sign the .exe, and the user can right-click the properties of the .exe and see it, but I believe it then unpacks the proper installer and runs that, which isn't signed.  As such, I haven't been able to figure out how to make this work with our new NSIS installer system.

Perhaps I'll add it as a task in our SW tracking system.

Electrum and Armory are different applications.  Besides the server issues, it's a major privacy issue to be sending your wallet addresses to a bunch of a different servers.  If you have $100k+ in Bitcoins, I wouldn't want to be advertising that in plaintext (along with my IP address) to some random nodes on the internet.

That's not to say it shouldn't be option:  we believe it should be.  It just hasn't been prioritized yet, because there are many people (especially with the 10x increase in price) who are willing to put in the extra effort to maximize security & privacy.   We will be starting work on a mode of Armory that has similar properties as Electrum.

On that note, 0.90 does fix the resource issues.  It uses only about 200 MB of RAM, and starts up very quickly.  But it does require 14 GB of disk space (to be reduced in a future version), and some users have reported problems with their particular blockchain files (we're investigating now).  It's not for everyone, but most people have been reporting success with it.

I have actually tried to do this like 4 times now, and it doesn't seem to work.  Rather, I never figured out how to access the underlying sound system using Python-Qt4.  It should definitely be added, but I have struggled far more than I should have with it and it got dropped lower on the priority list.

You can use 0.60-alpha on the offline computer if you want... it will still work, even if you're running 0.90-beta online.  The only downside is that you won't get any of the new backup features.  And when we finally finish the new wallet format and implement multi-sig, we're going to have to change the message format for doing offline transactions.  At that point you'll have to upgrade the offline computer if you upgrade the online computer, but the old wallets will still work (rather, there will be a migrate function).

As for upgrading the offline computer: we have "offline bundles" for the offline computers so installing is super simple.  If you want to compile from source, you can install the dependencies once on the offline computer and you should be in good shape.  Very occasionally a new dependency is added, but I think that's only happened 2 times in the last 2 years.

Not sure what you mean.  If Qt is out of sync, the bottom-right corner hover text will say "4 days ago".  Is this not the case?

It is basically already supported in Armory wallets now, I just don't have the interface to make it happen.  The problem is how terribly you can mess yourself up getting your online and offline wallets out of sync.  As I said, users who don't realize what they're doing will end up DoS'ing themselves and no obvious way to resolve it.  The only way I see it working is if you have a dedicated wallet for watch-only addresses with no expectation of having the private keys anywhere.