I'd like to have it done in a couple weeks.  But if there are snags and it can't be done before then, I guess there's not much I can do, eh?  But if you look at the RFC, it doesn't look like it will be terribly difficult.  Especially in python.

You have to have access to the blockchain in order to create transactions.  This is why prior attempts at offline wallets (before Armory) have usually involved synchronizing the 6 GB blockchain with the offline computer.  Every transaction you do, would require taking the latest X-hundred MB of blockchain to the offline computer and letting it index it before it could make the transactions. 

However, Armory has implemented this "the simpler" way, which is that the online system can transfer just the critical information needed for signing, to the offline computer.  The offline computer gets just enough information to know that what it's signing is legitimate, but it couldn't have made that transaction itself.

The end result is that the way it is designed is simpler all around, even though it has the slightly non-intuitive "feature" that you can't see your balance or create transactions offline.  You can think of the offline computer as a very important person sitting in a vault.  He doesn't know how much money is in the account, but he has signing authority for your money. When you execute the process, you are going into the vault with a pre-filled check and saying "Hey dude, can I get your signature on this?"  He says "You do realize this check is sending 100 BTC to address X, right?"  "Yeah, I approve".  Then he signs it and gives it back to you.  You leave the vault and go to the bank to deliver the check.

Something just hit slashdot today, that I don't totally understand.  But it's definitely reinforcing my paranoia about serial ports:

http://threatpost.com/open-serial-port-connections-to-scada-ics-and-it-gear-discovered/

I'll just let others put that into context for me...

(My understanding is that these serial ports were exposed to the internet, and that no precautions were taken to secure them ... and thus something like tty-logins were trivial to execute from anywhere)

Unfortunately, that's the "cost" of security.  Some would argue that the alternatives are really not that insecure.  And they're kind of right.  But Bitcoin-Qt/bitcoind is the gold standard of network security (kind of, by definition, but doesn't matter).  So that's what I gotta go with to make sure that Armory users don't end up on arbitrary hard forks due to subtle bugs in some reimplementation detail. 

I'm working on making it smoother... but I got a ways to go, yet...

I have a 2 BTC bounty out.  I figured I'd get wider appeal here than on the Armory subforum: 

https://bitcointalk.org/index.php?topic=179422.0

Please respond there if you are interested.  I really don't think this will be hard, I just have too many other things I'm focusing on.  And someone else requested that this be open-licensed, so that it could be shared with other clients.   I'd probably request that the end result go out into public domain.  After all, it's following public domain spec...

Raised the bounty to 2 BTC!

0.88.1 should be no worse than 0.88.  It is literally just a couple lines of code different to address some stupid bugs that slipped by me.  One of those bugs is importing private keys into encrypted wallets.  If you don't need to do that, then you can stay on 0.88.

No no no.  Thank you for your patience!  I'm surprised your still beating your head against it after the troubles you reported.  For reference, I think most users have less difficulty than that.  The program wouldn't be very popular if everyone had to go through it.  So you probably got unlucky.  Or had too little RAM (yeah... the major upgrade I'm working on is making it much more lightweight)

There is the Offline Wallet Tutorial.  It's kind of wordy.  We're working on an illustrated tutorial with screenshots right now.

Just bear in mind, up until this point, I've been the only person developing Armory.  So, keeping up with the website has been a little ... low priority.  Thanks again for your patience.  Please continue this conversation over in the Armory subforum.

Oh please try it anyway.  It turns out that it does work on some 10.7.  I thought it was 10.8, but some 10.7'ers reported success.  I still haven't figured out the conditions that cause it to not work.

Only recently was I able to add support for OSX, and it's not universal.  No guarantees that it works, there.  But there is a downloader on the site.

Yeah, I usually put it in the release notes, whether you should upgrade the offline computer.  And by "usually", I mean "I will" because I don't think I've had to do it yet.  Ever.

There's a few scattered posts talking up the new wallets.  Here's one of them.  But they are on hold while I deal with some of the usability issues.   I decided that usability was more important while Bitcoin was booming, than the new wallet format.  Unfortunately, usability may have actually declined with the last release... I hope I can iron that all out

Wait what?  It does work.  Just use 32-bit.  It works on all architectures.

Yeah.   There is only one version of the clients for each Bitcoin and Armory.  32-bit runs fine on 64 bit arch as long as it doesn't use more than 4GB RAM

It was kind of in my long-term plans.  Armory doesn't have the features needed to execute those types of transactions, and neither does any other software.  It's something I'd like to pioneer, but I have other pressing issues at the moment.  It is something I'll do eventually, though...

Ahh, I bet the harddrives spin down and/or the network connection is disabled.  That would most certainly mess with Armory.  I don't even know what would happen...

I have sleep/hibernate/spin-down disabled on all my systems, so I would never notice...

Sounds like you and Armory weren't meant to be together.  The initial download will still be required, but the rest of it will be improving dramatically in the near future.  Reduced resource usage and near-instant startup time.

The reason to use Armory is that when you create the offline wallet, you can put the watching-only wallet on your online computer and it behaves identically to a regular wallet.  You can generate millions of addresses, without the private keys on the online computer, and you can verify incoming payments just like a regular wallet.  The key feature is that spending the coins from the offline wallet only takes 1-2 minutes with a USB key to get the signature from the offline computer. 

Lots of people have figured out how to put their private keys offline and try to watch them from the online computer.  But no one else has figured out how to actually make that wallet usable.  If it requires any command-line, or re-distribution/synchronization of data between online and offline, it's inferior to Armory.  But obviously, Armory has some work to do on the other dimensions of usability.

Offline Armory rarely needs to be updated, unless there's some interface improvements that you prefer (which 0.88 did have).  But it's rarely worth the trouble.  Even though version 0.61 is freakin' ancient, it would still work as the offline version, because the protocol for exchanging transactions to sign hasn't changed. 

Only when I finish making the new wallets will you have to upgrade, and only if you use the new wallets.  Though, at some point I might deprecate BIP 10, thus eventually requiring you update the offline computer to be able to read the new *.unsigned.tx files.

But do you have to reinstall it when you restart it? 

Ugh.  I'm working diligently on the next major upgrade, which I'm hoping will resolve all these issues.  Sounds like I need to do this ASAP.

Because that was the goal of Bitcoin, to remove the requirement for pre-existing trust between transacting parties without a third-party.  That's how it's advertised.  I have no dispute with your statement that a lot of transactions happen right now that don't actually require zero-trust.  But if the system fails to meet that criteria in some contexts (like expecting your transaction to be replaced when it actually may not), users should be uniquely aware that it's not a good option for zero-trust situations.

Trust can go to zero as confirmations go to infinity.  But before inifinite confirmations, you have to have a trade-off between that security and the convenience/functionality.  The point of my post was to state the revelation that rapidly-adjusted micropayments are not trustless the way it was originally suggested.  It's critical to know that the next time I transact with someone in Nigeria, I do not use that technique.  

Your point is that it's not useless.  I agree -- I don't think it's useless.  I just think it's worth mentioning that it shouldn't be used in zero-trust situations.  And luckily, most people who would be using this, already have some degree of trust.  So it's not so bad, just use it carefully.

Really?  So you reinstall, and it works for some time, but then next time you open it gets that error? 

Obviously, that is not intended behavior.  I'm not aware that it needed to be done more than once (when you upgrade from the previous version).

If you want to go back to the previous version, you can go to the googlecode downloads page:  https://code.google.com/p/bitcoinarmory/downloads/list