Just posted 0.92.2-testing.  Internal testing shows it is good.   Use --tor or settings menu options to disable all network-related actions other than P2P messages to the local Bitcoin Core instance.

https://bitcointalk.org/index.php?topic=56424.msg8545742#msg8545742

Also updated the offline bundles for 12.04.5 and a significant performance/stability improvement for OSX (thanks doug_armory)

Sorry for the delay getting out the privacy fix, we've been fighting a pretty big fire here and we wanted to get our ducks in a row so we could push it into 0.92.2 release.  Unfortunately, it's not ready for 0.92.2, but the privacy fix is in there and we wanted to get that out there, along with a couple OSX performance/stability tweaks.  Also updated the Ubuntu offline bundles to work with 12.04.5 (finally, no more download links to download from old-releases.ubuntu.com).

Standard 0.03 BTC bounties apply.  However, we won't be fixing any bugs reported unless they are specifically related to the privacy issues , breaking OSX, 12.04 offline bundles, or otherwise critical.  This release is intended to be just a tweak to 0.92.1, including any non-critical bugs.

Regular Installers for 0.92.2-testing
  Armory 0.92.2-testing for Windows XP, Vista, 7, 8+ (32- and 64-bit)
  Armory 0.92.2-testing for MacOSX 10.7+ (64bit)
  Armory 0.92.2-testing for Ubuntu 12.04+ (32bit)
  Armory 0.92.2-testing for Ubuntu 12.04+ (64bit)
  Armory 0.92.2-testing for RaspberryPi  (armhf)

Offline Bundles (now works with Ubuntu 12.04.5)
  Armory 0.92.2-testing Offline Bundle for Ubuntu 12.04 exact (32bit)
  Armory 0.92.2-testing Offline Bundle for Ubuntu 12.04 exact (64bit)
  Armory 0.92.2-testing Offline Bundle for RaspberryPi  (armhf)

Signed hashes
  Armory 0.92.2-testing: Signed hashes of all installers

What version are you using?  For a brief period of time, we had released a version that suffered from a duplicate transaction issue exactly as you describe.

Either way, to fix it you don't need to redownload the blockchain.  Simply wait for it to get at least one confirmation, and if there's still a duplicate, use "Help->Rescan Databases".  Should take 30 minutes.

Note that people tend to have issues when they have a custom bitcoin.conf.  Usually happens when they limit connections, and Core maxes out its P2P connections with peers that aren't Armory.

The nice thing about fragmented backups as well as multi-sig wallets in general, is that you have the flexibility to manage those parameters yourself without many resources.  You don't need to store some at the bank.  Even if all you did was scatter them in your house, you'd still be protected against someone breaking in for other reasons and randomly finding a paper backup.  With regular paper backups that would be game over.  With fragmented backups, someone has to specifically target you (i.e. break into your house with the sole intent to find your Bitcoins).  Even then, they may not find them.

But of course, we recommend not keeping all of them in the same place -- people also like to distribute backup fragments in case their house burns down, etc.  Keep one with a family member, bury one in your backyard, etc.  If you make a 6-of-6 backup, having only 5 pieces is as good as having zero -- they need that 6th piece to get your wallet, and without it they might as well try brute-forcing your wallet from nothing.   

It's up to you to decide the parameters you are comfortable with, since it's your money.  At least Armory gives you that flexibility (are there any other wallets/services out there that do fragmented backups?).

Okay, so we've had zero reaction to the latest code, either running it or in code review.  I will try to post a signed build of it shortly, but I was hoping to have one of the original reporters of the issue to review the result (for which I posted a link to the diff on github in a previous message).  We will do some internal testing, but at the moment I can't officially release it in its current state.  I'll see what we can do this week to get it out there.

P.S. - There is a 0.05 bounty per bug!   You have every reason to try it out!

P.P.S. - We found a subtanstial improvement for OSX performance that was a small change so we decided that should go into 0.92.2.  Also should have minimal impact (simply disabling AppNap, I think). 

Are you using a watching-only wallet?  A WO wallet doesn't have private keys and will have that checkbox deactivated since it doesn't exist there.

Indeed -- lockboxes were intended for multi-party escrow and/or low-volume transactions such as long-term savings.   They were what we did to get some kind of multisig released and usable, even if it doesn't have all the features we want.  The new wallets will do exactly what you described, but it might be another two months before we can get something release-ready.

If you build your own tools on top of armoryd.py, you can have it load multiple watching-only wallets and build your own command to "getnextmultisig walletA walletB walletC" etc.  It's not terribly difficult, but retrofitting multisig into the existing wallet interface seemed like a waste of time when it might be just as fast to redo the wallets with multisig built-in.

The block size limit maxes out at about 300 GB per year.  So that's the worst that could happen, and we are at about 1/4 of that right now.

Also, please try the latest 0.92.1 which has a ton of OSX stability updates. OSX has never been friends with Armory, though we have a fulltime dev on OSX now so it is getting some constant attention.  0.92 is much better than 0.91 and he's found even more improvements for the next version.  I don't know if it solved your problems here, but it's generally a good upgrade for OSX users.

First of all, we recently saw a similar issue and it was due to copy and paste in the address field.  It catches and warns about invalid addresses, but there was some invisible Unicode whitespace character getting copied in at the end of the address.  Armory doesn't handle the strange chars and errors out before being able to pop up an invalid address warning. Can you confirm that's not happening to you? 

Second, if you have a situation where you click a button and nothing happens, it's usually a simple error, and an error message is getting logged.  Please use Help,  Submit Bug Report, which will bundle your log file into the bug report automatically.  It will usually be obvious pretty quickly (to us) what the problem is.

Good news!  I have implemented all the changes I mentioned earlier today.  It's all in the privacyfix082014 branch.   Here's the full diff between the current master and the new code:

https://github.com/etotheipi/BitcoinArmory/compare/master...privacyfix082014

There are no promises that this is totally complete and bug-free.  But I tested all the different settings, modifying the settings file to make it look like it's a new month, etc.  So far, it all looks good.  But admittedly I was a little rushed.

The bad news is that I am preoccupied until Friday (which is why I rushed), so I won't be able to do any formal testing or final releases before then.  But I wanted to get this out ASAP and get people reviewing the code, as well as let anyone test it that knows how to checkout the repo.

I will start the testing by offering 0.05 BTC for bugs found in that branch.  This only applies to bugs related to privacy settings, announcement checking, etc.  Although we would like to know about unrelated bugs in general, for now we are trying to stay focused on getting this bug fixed ASAP.    To 1a5f9842524:  I believe you said you ran some network tools to find the original issue.  Can you do this again to make sure I didn't miss something? 

A very, very long time.  This is why many people don't use Core (and thus Armory).  This is also why Armory implemented a torrent-based download feature when you use auto-bitcoind (which unfortunately isn't available on MacOSX).  People have reported 3-6 days to do the initial sync because of a very inefficient bootstrapping algorithm in Core.  Armory (the company) runs a bunch of seedboxes over torrent which allows you download at the maximum rate of your connection.  I can sync from nothing in about 6 hours -- about 2 hrs to download then 4 hours for Core to index it and Armory to build its own databases.

Actually, are you running Bitcoin Core manually?  If so, I would close Armory until you see the green checkmark in the bottom-right corner.  Armory can sync find after Core is complete, but sometimes has trouble thinking it is done synchronizing and "drinking from the firehose" (i.e. processing hundreds of blocks per second).

Admittedly, we should've made this easier.  It's because Armory uses it's own format for transaction data, in order to do offline transaction signing securely (the raw unsigned transaction alone is not enough to securely verify the transaction details).   So we have to explicitly convert it to be useful for other services.

There's two ways to get the fully-signed transaction.  One is to load it into the offline wallets interface where you normally sign or broadcast.  If you are in expert usermode, there will be a button that says "Copy Raw Tx (hex)".  That copies the hex transaction to the clipboard, which can then be paste into, say, https://blockchain.info/pushtx.   The other way is when viewing the transaction details (the dialog that shows the inputs and outputs), there will be a button on the bottom for copying the raw transaction (again, only in expert usermode). 

Okay, so here's my plan.

I'd like to have a new version out by next week (0.92.2).  Given that the change is small and doesn't go by any critical code paths, the release testing process can be relaxed slightly.   We'll try to have it out by Monday.

Second, the way I'd like to do it is to put a 4-byte random identifier in the settings file, and use that to for duplicate detection.  That identifier will be overwritten/changed every month, so that any thing that would care about trying to match IDs to systems will expire after a month.  This allows us to aggregate up to monthly statistics.  Anything longer than that we can do without.  

Third, we will decouple the announcement stuff entirely from OS/version reporting.  We will add an option in File->Settings to completely disable this.  Then announcement fetching will send a bare string with no extra metadata.   And as suggested, no extra data needs to be sent on subsequent announcement fetches.

Fourth, we will add a command-line option called "--tor" (with an equivalent option in the settings).  Then we will adapt the code to use that flag  to implement all the standard Tor-based settings:  most likely "--skip-announce-check --skip-online-check --satoshi-port=X".  You guys will be able to examine what code paths are affected by this setting and make recommendations for us to improve it.   (note there is also a "--skip-version-check" flag, but that is no longer used, since we updated the announcement system in 0.91).

I want to reiterate that we do care about privacy -- I've personally been a proponent of security and privacy on these forums for years.  And it would be tough to see why we would really care to match up IDs with announcement fetch pings.  We're not in the data collection business, no advertising, nothing.  We wouldn't know what what to do with it even if we saved it.   We (I) simply made a judgment error when implementing this (compounded by the fact that it was developed as part of a feature we wanted to aggressively promote -- security announcements).  Armory is a massive program, and it is respected for being thorough and careful, but we can't get 100% right.  One of the nice things about open-source is that people can find issues, call them out, and get it fixed.  And that's exactly what happened here.  Thanks for your guys' patience and we'll get this fix out there.

  

Actually, please PM with address since most people don't want it to be public.  Also, I have a few addresses that have already been given to me through email or PM, I'll pass them to you.

Unfortunately not.  Compressed and uncompressed keys have different addresses.  Even if you get the uncompressed version from Bitcoin Core and import it into Armory, it will show a different address and no balance. 

As mentioned above, the new wallet format is coming soon and Armory will finally understand compressed keys and know what to do with them.

Sorry guys, I've been out all day, but I've been thinking about this.  You all are absolutely right.  We made two mistakes:

(1) We assumed that because we choose not to store/process the IP data, that users would believe us that we don't
(2) We incorrectly assumed the that space of user home paths on your desktop was big enough that the 4 byte identifier would not have adverse privacy implications. I did not consider that people's home usernames might be, say, their username on bitcointalk.org

It's quite clear that those two pieces of data do have pretty serious privacy implications.  I want to fix this ASAP.  

To be clear, the reason we made the unique identifiers is because we don't want to store any IP data for the reasons described: if there was a subpoena of some sort, we'd prefer to not have anything to reveal.  And we don't store it.  But, we incorrectly assumed that the unique identifiers would be sufficiently non-privacy-leaking while still allowing us to remove duplicates (in response to justus: we want an identifier that will be persistent between loads so that users that start the program over and over are not counted for each start--as we all know, a lot of users have difficulty with Armory and will start it 300 times to try to get it to work).  It is clear these were bad assumptions since we technically could be storing both which would be quite bad.  

I hope we've generated enough good faith with the community that we get a little slack that this was not our intention.  I take the blame for not realizing that, and I want to make sure that it is fixed.  ASAP.  I will happily take feedback on how this should be adjusted so that we can meet our goals without compromising the privacy of the users.  

I agree we should decouple the option from the announcement fetching.  We consider announcements to be extremely important, and why we made that difficult to disable:  if there's a critical security (or privacy!) vulnerability in Armory, there is a very short window where someone might try to exploit it to steal peoples' coins, and there's no better way to help users than to make sure a big scary warning pops up the next time they start Armory.  The fact that we coupled the OS/version reporting with meant that it was as hard to disable that as it is the announcement fetching.  We can easily separate them and will happily make it easy to disable the OS/version reporting.


Re privacy policy:  On the advice of our lawyer, we included the "may collect IP addresses" because we have no way to prove that we don't.  And since our website uses google-analytics, we don't have control over what google does with the access patterns of users to our website.  It was a bit of CYA that companies have to abide by, especially in the US.  Note we describe at the bottom of that page we describe how to disable it with a link to our troubleshooting page.

On the upside: another positive example of the power of open-source software.  We have casually encouraged users to go through the code base, and we even contacted the Open Crypto Audit Project to try to get a code review (and never heard back from them).  We are obviously believers in open-source, and here's the first solid example of Armory getting better because of it.  We will get this fixed.

So that we don't "count" that ping as a unique user.  Our goal is to get a rough gauge of how many people are using Armory, and what the OS & version distribution is.  That's all we use the data for.  If we send a ping without the ID, we don't know if it's a duplicate. 

Also, I shouldn't have suggested "just" hard-forks... a piece of secure software used by people with massive amounts of money has many different reasons users might need to be notified, including critical security issues with Armory, if they arise.