Just hit "Receive Bitcoins" a few times, and it will calculate the next few addresses in your wallet.  Armory only shows you the addresses that it thinks you've used, and will only calculate and show the next addresses when you request it.   I thought that detection of existing transactions would mark those next addresses as "used"...   but I guess there's a bug in that logic.

The funds show up in your balances, because regardless of whether they show up in the wallet address list, the next 100 addresses are always included and tracked in blockchain scanning.  Just in case you have multiple devices using the same wallets and another device calculates and uses and address you have marked as unused.

As far as I know all wallet app have this shortcoming.  It's not easy to overcome... unless you scan the blockchain on every load   Because even if you encrypt the watching-only wallet, any data you save between loads can be used to identify what money is in your wallet. 

This was one of the benefits to having the super-node version of Armory that maintains a full DB of all spent and unspent UTXOs, so that it can encrypt the watching-only wallet without leaving leaky information all over the disk.  You just decrypt the wallet and instantaneously request all the address balances from your local database (among other uses for the super-node version).  But the super-node stuff will be put on hold for now.  Got some other priorities.

What I hope to do is get the blockchain scanning in Armory faster (I missed a lot of database optimizations in 0.90), and then have an option to disable saving data between loads.  Then it will behave much like 0.88.1 and earlier where it scanned every load.  Then it makes sense to implement the encryption. 

Just hit "Receive Bitcoins" a few times and it will calculate the next few addresses.  I thought Armory would do that automatically when it found money in "future" addresses in your wallet, but I guess not.  It does include them in the blockchain scan, but doesn't display them because it thinks they are "unused."  Definitely a bug.

Semi-official.  I'm going to let this release ferment silently for a few days, and make sure I got everything right, before pushing out notifications.  I was planning to push them out right away, but I've had too many instances of stupid things that need to be fixed and I don't want to spam users any more than necessary.

Probably push notifications and official announcement on Friday or Monday.

Send a log file to support@bitcoinarmory.com.  Then you can try doing a "Help"->"Rebuild and Rescan Databases".  If it's still stuck there... did you recently move your Bitcoin home directory?  And leave the old one intact?  I've seen it happen where Armory thinks the old home directory is the current one, but connects to Bitcoind which is working in a different directory.  Then Armory never sees any of the updated blockchain files.

Armory can't do this unless you modify your Bitcoin-Qt/bitcoind as well.  Since your local instance of Bitcoin-Qt is Armory's only peer, and it follows the fee rules exactly, any transactions that don't follow the correct fee rules will be DOA.  They don't get stuck or propagate slowly... they are dead the instant you send them.  There's no way around it without doing something else, like broadcasting the tx externally. 

It looks like HPLIP is the way to go for your printer.  I didn't see a lot of success stories when googling it.  Apparently the reason HPLIP works is because it ships all the PPD files.  Perhaps you only need to install it on another system and then find the PPD in the installed directory, then copy it over.

Also 12.04 might be better.

Within the "Add Printer" dialog, there should be the option to select the driver yourself.  Go to "System"->"Administration"->"Printing".  Then "+Add Printer".  It will "search for drivers", but even when you're online it will usually ask you to specify the make and model.  In your case, click on "HP" then continue.  Then under "Choose Driver", there are quite a few "Deskjet" options, though not 1050 specifically, but the 1000 may work.

Alternatively, you can try to find a .ppd file.  The .ppd is all you need, and instead of "selecting a driver", you just load the .ppd. 

I hope that helps.

It's your lucky day!   I figured out how to export it from my clean 10.04 system.  It should be OS-agnostic, so I don't think it matters what system ultimately uses it.

I just put uploaded it to our new S3 storage space, and linked it for you right here!

HP DesignJet 110 PPD file (CDNJ500)

Luckily, picobit's build script is pretty easy, so it's not too hard to make new releases when I update the code.  Though they will likely need extra testing, since OSX has a few quirks.  I'm hoping he'll see this and try scanning his own package for hardcoded directories and figure out what's wrong (though, he is a busy guy...)

I got a few more polishing activities (actually, mainly updating the website and replacing the dead links in the app), and then I'll at least release the Windows and Linux versions.  Perhaps early next week.  But I won't post the OSX packages to the website as-is, since they are basically unusable...

Interesting!  Each next version seems to work less and less reliably on OSX.  And for sure, that absolute path reference is ... not right. 

Luckily, picobit just messaged me to let me know that he may have a solution (a variant of the current build recipe).  I'm going to try it out tonight and see what happens.

The fee is required if it's less than 1 Bitcoin*Day old.   If it's 1 Bitcoin, it will require 1 day.  If it's 0.01 Bitcoins, it will require 100 days.  If it 1000 Bitcoins, it only needs a single confirmation to meet the requirements.

You might be waiting a while

It's perfectly possible to submit free transactions with the current version of Armory... Armory lets it through if the network would take it by default.  Armory won't let you send transactions that don't meet the minimum rules since they are likely to get stuck and cause serious heartache.  The only thing the current version does wrong is:  when a fee is required, it computes the required fee to be too high.  That's all.

The new version is already posted on the website, but as a pre-release "testing" version.  Should have a final release in a few days.

One more thing... that doesn't address your concern about paying 0.0005 BTC fees when you expected 0.0001.   It's because the older versions of Armory were created and hardcoded with the the "fee rules" at the time they were released.  For a very long time, those rules used 0.0005 BTC as the default fee, and Armory enforces that.  It has been changed to 0.0001, but the older versions of Armory don't know that!

The new version of Armory we're just about to release does have that updated.  You should see 0.0001 by default.  And transactions that don't output dust, using sufficiently old coins, and size under 10kB, can make it through for free.

So apparently you completely changed the topic on me before I posted... I'm leaving my previous post intact, in case you want to start a new thread.  Then I'll move it.

The answer to your fees question is on our FAQ page:

https://bitcoinarmory.com/about/faqs/

About half-way down is the question "Why do I sometimes have to pay a transaction fee? Why is it so inconsistent?"

Are you familiar with "bitcoind" (vs Bitcoin-Qt)?  We have a "daemon" version of Armory as well:  armoryd.py which behave almost identically to bitcoind, but gives you access to watching-only wallets, better transaction ledgers, etc.

The link above points to the armoryd.py on the master branch, which is currently pretty bare.  However, you can easily run it in offline mode and having it load and distribute addresses from a watching-only wallet.  If you put it in online mode, you will also be able to access transaction history and verify payments.    But it will crash every few days (because that's what 0.88.1 did).

In a couple weeks, that script (on the master branch) will be updated with a much-improved version.  We've actually already finished most of it, but will need to merge in some other changes that aren't ready for this release.  This version will implement most of the same functionality as bitcoind.

Either way, you should familiarize yourself with how bitcoind works, and then you will be able to access armoryd.py exactly the same way.  Even better, you could make a modification of armoryd.py which has your application built into it.  This is much more preferable than starting from scratch, because armoryd.py already has all the networking hooks, event loops, wallet load ops, etc integrated and working.  You would simply need to add code to the methods that process new transactions, etc. 

Can discuss at greater length after this release it out.  But if you are unfamiliar with bitcoind, you should do some research on that and how to use it and integrate it into web services.  Doing so will give you a non-deterministic, full wallet.  If you have that working, switching to armoryd.py for deterministic, watching-only will be trivial (when it's ready).   Or if you really just need a process that can read a watching-only wallet and get addresses on demand (but without transaction history), I can post a small python fragment that does that.

The latest testing version is stable and already posted on the website.  Just a little bit more polishing and we'll have an official release next week for Windows and Linux (having serious issues with OSX, so that might be a bit longer).  If you want to know or discuss it any more, continue over at the RAM-Reduction Thread.

So the btcarmory.org has been suspended and is empty.  However I was able to pull off the "installers" using a VM before it was taken down, and currently have them in a tar archive waiting for... something!  Anyone have recommendations for how to go about analyzing the executables and figuring out what they do?  I'm super interested to know how they decided to "attack" you.  Whether it was simple wallet stealing, some kind of trojan, or maybe even unrelated malware that does other things.

I know there's only so much you can do with a compiled binary, but I suspect there are people that know how to properly isolate and monitor the executable while it's running.  I'm envisioning low-level tracing of system calls, network accesses, disk accesses, etc, while running it in a VM. 

I'm not going to post the malware downloads publicly, but if someone has background to analyze them, or connections that do, I'll be happy to send them.  I have both a Windows .exe, and more interestingly (to me) a Linux/ELF "armoryamd64.out". 

Ack, somehow that file didn't make it to S3.  I'll have to check the script to see if it was being excluded from the upload or if there was an error.

Thanks for catching that... the data behind the link is now there, so the previous link should work again.

I just tested on a fresh install of 13.10 online, and it works great.  I am not sure if the offline bundle will work with 13.10 offline though.