I should add:  I also expected this to take weeks, not 48 hours.   I expected endless issues with dependencies, py2app, whatever.  And that it would require collaboration between parties to resolve.  In this case, though, higuys had basically already resolved all of that himself, and the rest seemed to be polishing.  For that reason, it didn't play out exactly as I expected.

Although I agree your contributions to the thread were useful, I wouldn't place at the 10% threshold.   Though, I do agree, it probably would've been a good idea to post my intention to payout the bounty, before actually declaring it, and get feedback.  I acted too hastily.  For that, I apologize.

There may be more that is done, but I can handle that.  My goal was to get something that *works*, and I can tweak the rest of it, probably with his help.  The reason the discussion moved was because higuys was essentially done already.  He was simply polishing.

And I guess I forgot to mention the 10 paragraphs he sent me via email, explaining the whole process to me.  Which was probably unnecessary, because his solution includes a fully-automated script that I can pick apart to understand what he did to any level of detail.

I didn't mean to imply that the "double-clickable .app" was the only checkout criteria -- it was necessary condition but not sufficient.  The polished script and extended email that makes the whole process repeatable for me, was the checkout.

I can't officially recommend you switch to higuys' .app for your "real savings accounts."  I only ask that you try it out if you don't have Armory yet, to confirm for me that it works.  I will get around to checking the build script, code modifications, building, signing, etc, next week.  Then I will post an official version.

Congratulations to higuys -- Bounty claimed!

He passed the "exit criteria":  He gave me a .zip that I downloaded in a fresh install of an OSX virtual machine, double-clicked, and Armory was running.  Nothing else had been installed.  In fact, there was no installation, either... it just runs!   And of course, he also wrote me a few paragraphs about it to make sure I understood it, and pointed me to a git repo with all the modifications.  It doesn't look hard to do.   The only problem is that I don't have a signing certificate yet, so users will have to disable the strict gatekeeper in order to use it...

And even better, higuys agreed to give RE about 10%.  There wasn't a negotiation, I just threw out a number that sounded like 10% and he agreed (sorry, it's actually 9.1%).  So I will break out my offline system and send higuys 22.5 BTC, and RedEmerald 2.255.  This was, by far, the most effective bounty campaign I could've imagined.  I guess it helps to have a nice compact problem to be solved, and someone who's basically already solved it! 

As for timelines... I have some big news coming up (besides OSX support), and the next few days are pretty packed.  I may have to wait until next week before I can actually create the OSX build to officially distribute.  For now, I request that higuys post his latest package and let people try it out.  Remember, he hasn't actually gotten the bounty yet, so he still has incentive to tweak it and help you out

gmaxwell answered it:  a large majority of mining power switched to running 0.7 -- which meant restarting the miners and clearing their memory pools.  With the right dynamics, a rebroadcast would not repropagate because most nodes had not been restarted and would not rebroadcast it.  Thus, those miners that restarted, started mining without it, and accepted the double-spend as a first-spend.

That particular theory, if correct, suggests that it's safer to have saved memory pools between loads, to make the keep/drop decision deterministic.  It would also appease those that want to do far-future locked transactions, whose transactions cannot, by definition, survive a software update cycle.  At least it would give clients/miners a choice about their locked-tx policy, rather than having it decided for them (drop all tx on restart).

Any guesses as to the reason it didn't show up in the pre-0.8 branch?   I don't see any reason that the original transaction could be systematically rejected by one branch and not the other.  Even transactions that hadn't made it into blocks in the pre-0.7 branch should still be in the nodes' memory pools and double-spends rejected.

gmaxwell pointed out that this could happen if an attacker started by flooding the system with duplicate transactions hoping to create disagreement, but it sounds like macbook-air did not do that.

Reserved!  (Because all the cool kids are doing it...)

I have recently had a large volume of email from users contact me with lost wallets and/or forgotten encryption passphrases.  It makes me realize Armory needs to be more aggressive about getting users to make a paper backup.  Or any backup!  

If you have no backup at all, and your hard drive crashes, you will lose your coins forever.
If you have no backup or only a digital backup, and you forgot your encryption passphrase, you will lose your coins forever.
If you have no backup or only a digital backup, and you get hit by a bus, your family will not be able to recover your coins -- they will be lost forever.

On the other hand, unlike the main client (Bitcoin-Qt), you only need one backup ever.  It doesn't matter how many addresses you use -- they're all derived from the information on that paper backup!

This isn't like a bank website where you can click a button to recover your password if you forget it.  Your password is the encryption key for your wallet, thus your wallet is permanently encrypted (i.e. useless) if you forget your passphrase.  This is what makes it secure against malware/viruses that copy your wallet files, but also keeps you out if you forget it!

Luckily, Armory has the ultimate solution for this: Paper Backups!   Use it!

Why paper?  Because a sheet of paper in a safe will last decades!  If the text is readable, the backup is good.  Compare to a USB key or CD, which is not guaranteed to work after a couple years... it might work ... it will probably work... but why risk it when you know paper will absolutely work?

• (1) Having a paper backup guarantees you will be able to recover your entire wallet, any time in the future, for any reason (except for imported keys; if you don't know what that means, you don't have them).
• (2) All paper backups are unencrypted.  The biggest threats for most users are digital/virtual, not physical threats.  It's also because an encrypted backup is useless if you forget your passphrase!  You may not need your backup for a couple years -- most users forget passwords within a couple months.
• (3) If you do not have a working printer, please copy it by hand with pen and paper!
• (3a) The QR code on the backup is only a copy of the four lines of text.  It is not needed for the backup to be useful, it's simply there for convenience.
• (4) Please protect your paper backup.  Because it's unencrypted, anyone accessing it can restore your wallet and send themself your coins.  If you are concerned about physical security, put it in a sealed envelope in a safe-deposit box at the bank.
• (5) A digital backup is encrypted if your wallet is encrypted.  This will protect you if your harddrive dies, or your laptop is stolen (import the wallet, type your passphrase, send all your coins to a new wallet).  But this doesn't help you if you need the paper backup because you forgot your passphrase!
• (6) If you have imported private keys, please use the "Backup Individual Keys" dialog, and copy the data to a text editor to print it.
• (7) Use the "Import Wallet" feature to restore any kind of backup.  Either in the "Wallets" menu, or in the upper-right corner of the main window
• (8) By keeping an [unencrypted] paper backup in a safe-deposit box, your family will be able to recover all your coins if something terrible happens to you.

A paper backup will not protect imported keys.  Please use the "Backup Individual Keys" dialog.  If you don't know what this means, you haven't done it.  This is also why it is recommended you sweep keys instead of importing -- keys are rarely reused unless you explicitly decide to do so, and sweeping will not require you to print/secure more backup material.

To reiterate:  if you only have an encrypted wallet on your computer, and only have encrypted backups, you essentially have a brain-wallet.  If something terrible happens to you, your Bitcoins go to the grave with you.  If you are simply forgetful, you have no more coins.   If you want to use a digital backup exclusively, it's highly recommended you write down the password and keep it with the backup!

UPDATE (12 Mar, 2013):  When the new wallets are released in a couple months, I will be revamping the backup system in Armory -- it will become more of a "Backup Center", or a "Backup Wizard" to help users figure out exactly how they should secure their funds.  This will include new options for backing up, including fragmented backups (with a GUI).  This information is provided here to fill the gap until the new wallets and backup center are complete.

Impatient user creates an offline computer, installs Armory, transfers 1,000 BTC, hooks up a serial cable to do one tx, then leaves it running with the serial cable attached.  

This is ripe for old OS subsystems that watch serial ports to be exploited.  Sure getty's are mostly disabled... but maybe not.  There may also be other processes which do something automatcally on the serial port to "make your life easier", which could be exploited.  Yes, I am being exceptionally paranoid... but it's a one-time cost for me to develop a solution that puts the serial port somewhere that no program or app can find it or use, then it nullifies the threat of latent processes exposing an attack surface.  An attack surface that is potentially much worse than the threat of USB viruses.

Keep in mind this is not to say that an attacker who has already compromised the offline system couldn't find it and use the new serial port... but the assumption here is that the offline system hasn't been compromised, and I want to prevent it from being compromised by making sure Armory is the only process on the system with access to the serial cable.

I think the exchange rate isn't going to go too nuts, becuase there's plenty of people who realize how much of a non-issue this is and are buying cheap coins as fast as the people freaking out are selling them.  The price will drop, but not to $5.  

The original post lacked info for "regular users".  Here it is:

(1) If you are a "regular user" (not a miner), the best thing is to do nothing and wait a couple hours.
(2) If you are a "regular user", upgrading, downgrading, whining, FUD, etc, will make no difference.  Only miners have an incentive to do anything.  Otherwise, it doesn't matter which version you are running.
(3) Regardless of who you are, your transactions are not dead, your coins are not lost.  They will just temporarily be held up.  If you sent a transaction within the last few hours, it may take a few more hours before it's sorted out.
(4) If you insist on processing transactions right now it's probably best to wait 30+ confirmations.  It's just due diligence though ... an attacker would still need a tremendous amount of mining power, quick thinking, and a victim willing to part with a lot of BTC.
(5) By tomorrow this will be in the past and everything will appear to be normal again.  If you slept through this, you'd never know that anything happend (except for the price drop).

Let me reiterate, your coins are not at risk, your transactions are not lost.  It'll just take some time for the network to "iron itself out."  Everything will be okay.

No it doesn't.

It only stores a transaction index to where the transactions are on disk.  But there's 10+ million transactions, with hashes 32 bytes each, 20 byte file pointers, and some extra overhead.  It's not difficult to see you're approaching the order of magnitude of its current RAM usage.

On my system, it consumes about 1.5-2 GB RAM.  It used to be 400 MB.  But the index itself is growing too fast...

It definitely should not take that long to scan.  On my computer, it takes about 3-5 minutes.  On my Windows VM, it's about 10 minutes.  Some people have reported 10-20 minutes.  Not ideal, but at least it's "usable."

The blockchain is not getting any smaller, and reports like this are increasing in number.  I hadn't planned to do this upgrade for a while, but Bitcoin's growth + SatoshiDice have started to hold me hostage.  That's why maintaining persistent blockchain data is top of my priority list (after I'm done with my current major upgrade).

However, you should be seeing the blockchain update.   There was a bug in 0.87 that especially affected users with long load times.  That was fixed in 0.87.2.  If it still doesn't update properly in 0.87.2... then I guess you should wait for the RAM update...

New ideas!  Food for thought:  I just talked to some people who are a bit better with hardware than me, and someone mentioned the idea of using "broken" cables.  For instance, using a serial cable with a null-modem connector that has some wires flipped.  My understanding was that there's no reason the other pins can't be used identically, it's just more "convention" that pins 2 and 3 are used for tx/rx...?    So if you connected that wacky cable, it is theoretically usable with the same bandwidths, but nothing on your system would recognize it as a usable serial cable.  You could probably do something similar with ethernet (which is easy to make yourself). 

Another variant of that was that you could use ethernet but configure one machine with "broken" settings.  You could set the machine so it would never even get itself an IP address, you could transmit data via byte-padding ping/arping packets.  That's a pretty crazy idea.  Basically take things one level lower than most apps operate at.

---

A more software-oriented solution came out of that conversation too.  One that might actually make me feel comfortable about serial if I can make it work.   Actually remove the /dev/ttySX devices from the system, create new files in their place with chattr +i them so they can't be removed, then make them root-only-everything.  Then create a new device file in, say, /home/username/armory-tty using mknod, using char blocks (4,64) (which is the block to identify that the device is to be assigned to the next serial device that is attached).  Then setup Armory to use /home/username/armory-tty for serial communications. 

That would pretty much kill everything.  Even things that are smart enough to search the /dev directory for serial-capable devices.  Any getty's would become invalid.  Could it be further modified, using chmod 700 for my username/group, so any other non-root processes couldn't access it even if they found it?  Would that interfere with the system assigning serial devices to it?

By the way, here's the code my friend sent:

Sorry, Freenode

I had created #bitcoin-armory but no one ever went there, so I stopped reopening it when I would restart.  There's nothing stopping you from using it though.  I just jumped in, myself.

Yes, very much in the works.  This is one of my two major usability upgrades for Armory in the next month.

Sounds like you're using an older version of Armory with Bitcoin-Qt 0.8+.  Do you have the latest one from: http://bitcoinarmory.com/get-armory/ ?

And how would just one key be compromised?  If an attacker gets your passphrase, scrapes your decryption key from RAM, has a keylogger, etc,  they get them all.  I'm very curious what situation leads to the compromise of a single key but not the others...

Sorry coqui33,

This is not currently possible, because Armory depends on having access to the blk*.dat files in the Bitcoin-Qt/bitcoind home directory.  In the future (hopefully near future), this will be possible, as I start maintaining my own database of blockchain data.  However, bear in mind that Armory is very dumb when it comes to networking... it can compute the longest chain, but that's its only defense.  So you will have to select a trusted node.  I recognize you are planning to do that, it's just a warning.

However, before then, the RAM usage will probably come down considerably, so it may not be needed in your case.

---

Good news!  24 hours and 24 BTC, and it looks like we may have an OSX installer for Armory soon!  It turns out, all it took was some advertising on reddit -- someone had basically already packaged it up for his own use.   I wish I'd known it was that easy, I wouldn't have been dreading it for months!