To follow up on the Revoke & Replace idea.  I think it could be somewhat secure if you use the following conditions:

Revoke and Replace:

(1) Must include a valid signature
(2) Must be in a tx sending exactly 2,000 BTC to company address X
(3) Replacement considered valid after 4032 blocks

Replacement Cancellation: (revocation still valid)

(4) Within that 4032 blocks, if a another transaction shows up sending 2,000 BTC to company address X, the replacement is cancelled (though revocation will still be permanent)

Basically, you're allowing revocation of the replacement, which is potentially the most dangerous part of a Revoke&Replace capability.  Revocation remains permanent, since the system has clearly been compromised, anyway.

Again, this adds a hardcore asymmetry to the situation, since it costs the company nothing to exercise any step, but extremely costly to an attacker.  And if their goal is to replace the key, they have to risk 2,000 BTC to even try, and most likely they fail and lose the money.  

Abstract:

Design an authentication system that uses the blockchain as a revocation "list" (for say, software signing keys).  By doing this, you can add extra conditions for a revocation to be considered valid, such as requiring a large payment to the person or company that controls the original key.  The payment is "free" for the authorized individuals, but not anyone else.


Situation:

You are an individual or organization with some kind of signing key or certificate that is used for Important Things (such as signing Armory installers).  You'd like a way to permanently revoke the key/cert if it is compromised or lost, to prevent users from trusting it anymore.  And you'd like the revocation to be timestamped so that users can still trust messages signed before that time.

Since you are also protecting yourself from simply losing the key/cert, just like in GPG, you may pre-sign a revocation cert, and keep it in a secure place until it is needed one day.  The problem with revocation is that it relies on permanency -- you can't unrevoke a key.  It is revoked one time and permanently updated in all key servers, etc.  So it would be great if you were the only one who had that power.

But you can't keep it too secure, because it needs to be available quickly in case it's needed -- for instance, you find evidence that the signing key was compromised, and want to revoke it before the attacker can sign and distribute malicious versions of your software.  If it's kept in a safe deposit box, and it's Saturday, you may have to wait two days to revoke.  Also, if you are the only person trusted to control the private key, and you die, it would be good for someone else to be able to revoke it for you.

So you also may want to back it up, and/or distribute it to semi-trusted individuals to make sure it's available if needed.  But you don't want those individuals to have access to the signing key itself, and would like to be protected if they don't secure the revocation cert properly.

An attacker that gets access to the revocation cert can do a lot of damage to you or your organization, even if they don't personally benefit (blackmail?).  Or maybe they can find a way to exploit the power vacuum while the key is revoked and not yet replaced (perhaps they know how to poison the key re-distribution process).  As always, most solutions are a balancing act of security and convenience.


My Solution: (assume the signing key is controlled by a company)

Use the Bitcoin network as the revocation "server", but add a large payment to a company address as a condition of revocation.  The software that relies on verifying signatures from this key, will track of the latest blocks on the network, looking for the revocation trigger.  Perhaps, they are hardcoded with the revocation cert message, and simply watch for OP_RETURN strings that contain a valid signature  (and of course you get natural timestamping from this tx being mined).

So make the revocation condition 2-fold:
(1) Requires a signature from the key being revoked in an OP_RETURN string
(2) The tx with the OP_RETURN must include a payment of 2,000 BTC to company address X

(X is probably a 3-of-5 address controlled by the 5 directors of the company, etc)

This is cool, because if the company itself decides to issue the revocation, it doesn't cost them anything because they are simply sending 2,000 BTC to themselves.  They don't actually lose any money.  But if someone else wants to maliciously revoke it without company permission, they're going to have to cough up 2,000 BTC to a company address, and won't get it back.  Even if the company doesn't have that much BTC on hand, they can simply borrow it, send it to themselves, then return it (the existence  of the 2,000 BTC tx is the trigger, doesn't matter where the money goes after that).   Perhaps the value chosen is the perceived cost to the company of a malicious revocation -- an attacker has to pay them the cost of fixing the problem, if he's going to revoke maliciously.

While we don't like people dumping data into the blockchain, revocation happens exactly 0 or 1 time, ever.  Very few people/orgs would use this technique, and even fewer would need to actually ever revoke.  I'm fine with this, personally, in terms of blockchain bloat.


Revoke & Replace: ()

In general there is no safe way to include revoke&replace in the same operation, since it would make the revocation certificate exactly as sensitive as the private key itself.  However, if you employ pay-to-revoke, you've made it extremely expensive for anyone but the company to exercise that option.  In some contexts, this still wouldn't be considered safe as an attacker may be able to profit more than 2,000 BTC by being able to quickly replace the signing keys.

OTOH, if you're going to do key revocation & replacement at the same time, you could also add a third and fourth condition, where the new key will not be considered active until after 30 days, and can be canceled by an even bigger payment to the same address! Then the company has 30 days to detect the attack, and send themselves >2,000 BTC to cancel the revocation -- and they get to keep the attacker's money!

@LOL

I just fixed the multisig display issue with a one-line change.  All the code was already written and integrated, but I didn't account for the variable number of addresses/keys when analyzing a transaction with a multi-sig output.

Will push the update shortly to 0.91-dev (in case you're impatient )

Testing version 0.90.99.4 for Windows, Mac and Linux*

*Any linux with python2.6 is still borked.  However this package should work on any linux system with python 2.7 (we thought we'd found a way to compile universal installers, and we did...as long as it uses the same python version!).


YES Mac version compiled and seems to be working!
YES The crashing at 99% done scanning seems to be fixed!

Downloads and info in the testing thread.

Congrats!  You get to try the new blockchain download via torrent!   But we think your other problems will be fixed when you are done.

Please install the new version of Armory I just posted.  Use "Help"->"Factory Reset" and choose to destroy everything, including redownloading the blockchain.

If it goes right, you should get to redownload via torrent.  The new version should work out of the box.  (no more --test-announce is needed)

Testing version 0.90.99.4 for Windows, Mac and Linux*

*Any linux with python2.6 is still borked.  However this package should work on any linux system with python 2.7 (we thought we'd found a way to compile universal installers, and we did...as long as it uses the same python version... we think...).


YES Mac version compiled and seems to be working!
YES The crashing at 99% done scanning seems to be fixed!
Offline-signed announce data.  No longer need --test-announce for torrent and secure downloading

Downloads and info in the top post.

Thanks rxgrant (github) for pointing us to that solution, and then goatpig figured out how to make it even better!  Sounds like it was more successful than any of us were expecting!

Also, thanks to picobit for helping figure out how to fix the mac builds after we revamped the makefiles.  I haven't gotten it working on my system yet, but it's close!

Should have 0.90.99.4 out tonight for Windows, Ubuntu 12.04+ and OSX  (at least the first two).  It will include the moster-tx fix, as well as a ton of robustness improvements.  Also, I should have  a properly-signed announce file, so you don't have to run with --test-announce to get those features. 

Zoella, rocks, etc:

https://bitcointalk.org/index.php?topic=522866.msg5807344#msg5807344

i.e. try the latest 0.91-dev branch if you can, with your problem wallets (make sure you rebuild).



You need 500+ outputs per transaction to trigger this.

Goatpig just pushed a change that might push people through the BDM-timeout barrier if they have these wallets with huge numbers of large transactions.  Curious how the performance is after it gets past the synchronization, but at least you should get through it.

Zoella, rocks*, if you can, please checkout the latest 0.91-dev, make clean and make, then try it with your large wallets that were crashing (assuming you are on Linux... if not, we'll make a windows version after we know this solves it)

The torrent library we found (BitTornado) is kind of old and doesn't support DHT.  We setup the tracker to accommodate this, and our guy actually found a way to bridge the peer swarms using a tracker compatible with this library (assuming we're using the same torrent, which we will when new official ones are released).  We had to make the appropriate design decisions:  BitTornado worked flawlessly out of the box on all OS, pure-python, and stupid-easy to integrate.  It was more work to change BitTornado than it was to simply do it this way.

One problem with the official one is that it's not updated regularly.  Until Core 0.9.0, the checkpoints are 3 months behind, and so is the torrent.  We wanted to make sure we can provide a more-frequently-updated torrent, as "topping off" the blockchain after bootstrapping appears to be a huge bottleneck.  For me, using the old torrent required 2 hours of bootstrapping and 2-3 hours of "topping off".  With the newer torrents, it's 2-3 hours total.  We're already setting up all the peers to do it, we wanted to optimize that.

We have a variety of seedboxes setup across a dozen services to guarantee that our peer swarm is flexible and robust to any one (or 5) service providers going down.  I understand the tracker thing, and it's in our plan to get a couple more, setup the same way to add extra robustness.   But in the end, it's not really a single point of "failure", because Armory will fall back on regular P2P download if torrent doesn't work.  Worst case is status quo. 

The answer to your question is basically:  determining spendability of an arbitrary script is an intractible problem.  I'm sure it's related to the halting problem.  Either way, the only way to do this is to simply identify a set of scripts templates and conditions that we know are spendable, and code those directly into the app.  When we have a multi-sig solution in Armory, it would be easy to automatically recognize such 1-of-N scripts as spendable.   But tying that into the interface may be complex:  do we really show those tx as spendable money the same as all the regular single-sig money?  It's in a 1-of-N for a reason, maybe it should be identified separately, in which case we need to show that in a different interface or in a different way.  Etc.

On that note, do you have a watching-only wallet that I could use to test the multi-sig thing.  I went to go fix it, and then realized I don't have a good way to get multisig address into any of my wallets.  Once i have one, I can fix the display problem pretty fast.

We have tried to respond to as many support emails as we can.  But we are a dev team, not a customer support team, so we can't get to everything.  Since we hadn't isolated the cause of your issue yet, the majority of emails we received from users with your symptoms we could not respond intelligently. 

Like I said, we want to respond to everyone, but we're an open-source project that makes no money (yet) and we have no customer support staff.  We respond to the emails that have the easiest response.  And we certainly take note of of the problems we see. 

On that note, I think we found a solution to this.  We may be able to get it into 0.91 after all.  We're excited that many of users reporting these symptoms may be resolved with this fix (hopefully all of them!)

Btw, I just posted a new testing version and forgot to link to it from here:

0.90.99.3-testing is posted for both Windows and Ubuntu 12.04+

Unfortunately, we upgraded the makefiles, etc, and OSX building broke.  We don't think it will be tough to fix, but gotta fight through it.

---

@rocks -- we do take every report seriously, but we can't magically fix things just because a report was made.  There's been a lot of reports of the BDM hanging that we were only recently been able to identify.  Until we isolate the issue, we can't do anything about it.

In your case, there is obviously a pattern, because we test it regularly on new installs, and many users install on clean installs without issue.  (the exception is WinXP 64, which has always had problems).

--Are you using a paritcular wallet on each system?
--Are you using a particular bitcoin.conf?
--Are these all on the same computer?  What are its specs?
--Are you installing in non-standard locations?  
--Do you use command-line flags?
--Do you have non-english characters in your path names or use them in the interface?
--Do you run bitcoind/bitcoin-qt manually, or auto-managed?

As for the leveldb-error... I'm not sure exactly what that is.  Is it an error that there's a problem with the databases?  Or leveldb itself appears to be missing?  If leveldb is there but reports problematic files, try running with --rebuild.  

Again, I'm not here to discredit you or say anything is unimportant.  But clearly something is awry, as we've had plenty of users report success with every one of those environments (except WinXP64).  It would be great to know what is different, if anything.

Figured it out!  It's because that's not actually P2SH, it's a plain multi-sig address.  P2SH is one way to execute multisig scripts, but it's not used in the transaction you linked.  I would totally believe that I broke multisig display because I didn't test that.  Whoops!

I'll see if I can get it back to the way it was before.

P.S. - Just posted an Ubuntu 64-bit installer for testing...

Yes, I added P2SH support throughout the interface.  I'm surprised it doesn't work because I did spend a quite bit of time testing that.  Anything interesting in the log file?

EDIT:  I actually see that tx is unconfirmed and I just remembered seeing a bug with unconfirmed transactions a while back.  Can you just check again after it's got one confirmation?

Please Help Test Armory 0.91-beta!

This new version has a ton of new stability and performance improvements.  Including a fix for most users that had crashes at 99% scanning!

GPG signature of hashes at the bottom

---

Armory 0.90.99.7-testing for Ubuntu/Debian 64-bit*
761e4aaf285b28c530a34f522d487ada88733607e297ec7bd61ab7f163738dac

Armory 0.90.99.7-testing for Ubuntu/Debian 32-bit*
 a89fb24c98d88e991b96d309d2890c285e0012fd4eac6ec3e9b31c3f0e5eb4f9

Armory 0.90.99.7-testing for Windows (including XP!)
c797a9e08e8d845bb085dd45d86d2d82b9911db735e276ff9e7cc85ce4c7ba87

Armory 0.90.99.7-testing for MacOSX
1bbac95eb56046b86cf63b96c0957da6a4dbee9bbf1ca2836a70d517b4534b65

Armory 0.90.99.7-testing for Raspberry Pi (raspbian; armhf)
076368590875b4ff2faf1446a4aa1aec4fd94abe0790caf0f323ba703fc5f836

---

*Apparently we have broken Python2.6 support with this release, and so cannot make a version (yet) that is compatible with older versions of Ubuntu like 10.04.  We are working on that...

New stuff in 0.90.99.5-testing:

• Major fix for crashing at 99% scanning!  We finally isolated the cause for most reports of crashing at 99%.  If you've previously had wallets with this problem, please download and try 0.90.99.5!
• Torrent downloading for initial blockchain sync.  Armory Technologies is now running a private swarm of seedboxes to make sure there's enough capacity for everyone (it's the "Armory CDN" - content distribution network)
• New announcement system, that includes a secure downloader for Bitcoin Core and Armory, as well as offline bundles with ATI signatures that can be verified on the offline computer. This will also be used in the event that there are critical security alerts, either by the core Bitcoin devs, or Armory team.
• Extra entropy from keyboard, mouse and filesystem, are now used when creating new wallets (this is done invisibly, but a log message tells you how much is collected).
• Use --nospendzeroconfchange to not allow spending of any unconfirmed TxOuts (Armory already deprioritizes ZC change, but it's off-limits with this flag)
• Full P2SH support in send-BTC dialog, address book, tx info, etc
• WinXP support
• Proper unicode path handling (new wallets will support unicode in 0.92-beta)
• No more choking on bad blocks written by Bitcoin-Qt/bitcoind
• Major improvements to OSX compatibility!  (hopefully)
• Fixed fonts in OSX
• Bug reporting window -- Use "Help"-->"Submit Bug Report"
• Progress bars for long-running operations
• Factory reset window -- including "Delete Bitcoin-Qt databases and re-download"
• Raspberry Pi offline bundle (process ironed out, will create test bundles soon!)
• Minimize-on-open (in settings)
• Wallets->"Recover Damaged Wallet"
• Wallet creation wizard
• Faster rescanning and rebuilding
• Better logic to prevent unnecessary rescans
• Better zero-conf tx handling
• Fee calculation fixes
• armoryd.py fixes and upgrades
• Multithreading improvements
• Code refactoring

A few points to emphasize:

• Dramatically reduced rescanning and rebuilding.  Armory is much smarter about when it really needs to rescan.  It's not perfect, but it should be solid now  (will have a more robust fix in 0.92)
• The new announcement system uses an offline Bitcoin private key that is protected at the same level as our offline GPG key.  We plan to start releasing new versions signed with both.  The benefit of the Bitcoin key, is that Armory can verify the signatures, without the user having to have GPG or find our offline GPG key.  The expected public key is hardcoded into Armory.  For now, use --test-announce which uses a different key, protected to the same extent as my email GPG key, which allows for easy testing.  (btw, the offline Bitcoin key is hardcoded in previous versions, it just wasn't used, yet)
• Torrent downloading uses a swarm of seedboxes provided by Armory Technologies.  Using Bitcoin Core 0.9.0, I can get online from a new system in about 6-8 hours (that includes download, bootstrapping, DB building and scanning).  If for whatever you wish to not use built-in Armory torrent'ing, you can use --disable-torrent, or even remove the entire BitTornado directory.  We have verified that Armory works with all torrent code removed.
• Slowness and UI freezes should be mostly gone.  It turns out that large wallets were choking on the number of zero-confirmation transactions on the network, combined with an inefficiency in Armory's handling of them.  It should be dramatically improved. If Armory previously worked well for you, but then got slower over time, this should fix it for you (at least, after the first invocation of Help->Clear All Unconfirmed)
• Please try the bug reporting window! (only if you have actual problems, of course!).  It will collect your system specs and log files and send them directly to our customer support tracking system.  Help->Submit Bug Report

Recently identified:

• Wallets that receive large numbers of small transactions, usually from pooled mining, certain types of gambling services, and advertising payments, will not work with Armory.  They freeze at 99% scanning.  This has been a problem for a while, but we only recently isolated the cause, since no one on our team uses a wallet like this.  We are not aware of a quick workaround for 0.91, but will have something in 0.91.1.  If you must get at your coins, you can export the private keys from Armory into another application, or export the key list, remove the wallet, then create a new one and sweep the private keys into it. Solution found! It's part of 0.90.99.4!
• The organization of the secure downloader is sub-optimal.  In a future version, we will make it easier to find what you're looking for, though the downloads there are valid and signed by our lower-security Bitcoin key.  (we are working on getting a signature from the offline key ... it's not convenient )

---

If you get this testing version, this should be the last time you need to use GPG to verify Armory installers!

Here's the Bitcoin keys we will use for signing announcements and downloads from the secure downloader -- they are hardcoded in the Armory source:

1NWvhByxfTXPYNT4zMBmEY3VL8QJQtQoei (offline key)
1PpAJyNoocJt38Vcf4AfPffaxo76D4AAEe (online testing key)

Until you get the new version, here is a GPG-signed copy of the 0.90.99.7


Version 0.91 automatically identifies messages that match the key and explicitly tell you it's signed by "Armory Technologies, Inc".  It's only if you're using an older version that you have manually verify the address.  Here's what it looks like in 0.91:



We will have OSX and Linux versions posted soon.  Some recent changes we made broke our build/release system -- it seems to work for local compiling, but building distributable packages is broken and hopefully fixed later today.

Absolutely.  Without it we'll have to manually hack together a wallet that exhibits the problem.  It would be much easier if we had one we already know causes problems. 

FYI we're stirring up our support email channel, so I'm not sure if a simple email with attachment will work.  Please try it and we'll find another way to get it if doesn't work (just support at bitcoinarmory dot com).

The point is that these transactions have identified an inefficiency in Armory that will have to be fixed.  However, I believe that most users do not have such transactions, and it is only now that we've been able to identify that as the cause for a lot of these reports.  Because no one on our team has a wallet with such transactions in it.  Those types of transactions simply do not exist in many use cases, and thus many people will not experience any such problems.

Please do not misinterpret my statement as blaming it on the user, or saying it's unimportant.  I'm simply identifying that you have fallen into a gap that many users do not, and thus will not have those problems.  Now that we've identified it, we'll try to get a fix into 0.91.1.  Fixing it will require a bit more work than we can put in for 0.91.

So there may be no short-term solution for 0.91-beta for these types of wallets.  We will move forward with 0.91 as-is, and plan to get a wallet with lots of these transactions and fix this issue in a point-release, 0.91.1.

Agreed.  We were not aware of the scope of the issue until now.  Most users don't want to send their wallets for privacy reasons, and we are left to speculate on why these issues are happening.  Luckily, we have isolated it now, and can act accordingly.

Waiting for Zoella to report back on the disablecomments branch.  If his wallet works with the mod, we can add that as a command-line flag until we have fixed the core issue.