Please Help Test Armory 0.91-beta!

[etotheipi]

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

Code:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

a89fb24c98d88e991b96d309d2890c285e0012fd4eac6ec3e9b31c3f0e5eb4f9  armory_0.90.99.7-testing_32bit.deb
761e4aaf285b28c530a34f522d487ada88733607e297ec7bd61ab7f163738dac  armory_0.90.99.7-testing_64bit.deb
1bbac95eb56046b86cf63b96c0957da6a4dbee9bbf1ca2836a70d517b4534b65  armory_0.90.99.7-testing_osx.tar.gz
076368590875b4ff2faf1446a4aa1aec4fd94abe0790caf0f323ba703fc5f836  armory_0.90.99.7-testing_raspbian.tar.gz
c797a9e08e8d845bb085dd45d86d2d82b9911db735e276ff9e7cc85ce4c7ba87  armory_0.90.99.7-testing_winAll.exe

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQIcBAEBCAAGBQJTPwqEAAoJEEqxauqYgyIjrVEP/2rsGzJO0HouDgw5ppguM2zS
S/UandijMzsgt4VmfvBHmjDtB4U17uOmle48lWiMNLQb4Pa8eqzw9IxpjSW/QxwZ
FGVWlw+3hN34dvvC/SdsouKowy4YBvl1+NCQ73utzkJfD4RlPn/a1zqESwi0cq6E
ZtgZDvn+cSe/wT/v2mXXf4UM2Ptf61Xsy+Hmd3fJEnuPVTzbbUmbQPfHbjK1iO4Z
AK8U5W67/LzilZsMnWRrfHGRyZGPPtj0YeEBJZlgnTG/Qd00osUoSQ+mZ5TYoEJY
wFd6RMrLNustsvRVKhWrwpTDC25M0IOnCvyNYChV6kQvoAItzSAsiXKiR87QDCM/
v0/fHtZCY5YWY90PR25nSTkUDH7Yny/FFqy2urHzrPFnPsBVmDd5o33UeKKo7tsa
Ngo9o8/Ll44NFWWFj8WSC1tSWjXh/bWhE20t0Yei1SKSKjcq3rAtx1X3+JZDuIQJ
XqEBWfb5uwpuJAB6MEkGWFaiwSaB07w1Sd6JNuU0lBCebFFJNIAJ33LvbZNRUB4m
B28uWZ+iRwZPq3vbSuv59po73iS3ZYzKtMI3qyuuCtvqi9xe6GXo5PZEoLyDjiCc
2VW68bXhzODZe6J7tWko2L3h3+wyKGZ4ZevpvcXfj80sBjdbCNQGmS7nStEUArKp
mvOb00LkDYRLl9C4M9yS
=bdkA
-----END PGP SIGNATURE-----

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.

[1715389464]

1715389464

[1715389464]

1715389464

[1715389464]

1715389464

[LOL]

Quick bug report:

It appears as if I'm unable to open the "Transaction Info" popup on transactions that have a P2SH output as is standard in mastercoin transactions. In previous releases, the P2SH output was just marked as (I believe it was) "strange." It's not a huge deal considering that no wallet recognizes or can spend those outputs anyway, but it would be nice if the popup worked.

Here's an example:

Code:

OP_1 <pubkey1> <pubkey2> OP_2 OP_CHECKMULTISIG 

https://blockchain.info/tx/cba042a1e4b4b072084c06e94f84843cdbd17a30f13dd038fabca67baeb20b53

[etotheipi]

Quick bug report:

It appears as if I'm unable to open the "Transaction Info" popup on transactions that have a P2SH output as is standard in mastercoin transactions. In previous releases, the P2SH output was just marked as (I believe it was) "strange." It's not a huge deal considering that no wallet recognizes or can spend those outputs anyway, but it would be nice if the popup worked.

Here's an example:

Code:

OP_1 <pubkey1> <pubkey2> OP_2 OP_CHECKMULTISIG 

https://blockchain.info/tx/cba042a1e4b4b072084c06e94f84843cdbd17a30f13dd038fabca67baeb20b53

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?

[etotheipi]

Quick bug report:

It appears as if I'm unable to open the "Transaction Info" popup on transactions that have a P2SH output as is standard in mastercoin transactions. In previous releases, the P2SH output was just marked as (I believe it was) "strange." It's not a huge deal considering that no wallet recognizes or can spend those outputs anyway, but it would be nice if the popup worked.

Here's an example:

Code:

OP_1 <pubkey1> <pubkey2> OP_2 OP_CHECKMULTISIG 

https://blockchain.info/tx/cba042a1e4b4b072084c06e94f84843cdbd17a30f13dd038fabca67baeb20b53

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...

[LOL]

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...

Sorry about that. I actually realized right after that post that I'd been using P2SH interchangeably with multisig in a multitude of places recently. I suppose I'll live with the embarrassment.

But while we're on the subject of multisig, do you mind commenting on the feasibility of a wallet recognizing strange outputs as spendable? That's a pretty broad question, but I didn't want to narrow it down so far as to only be applicable to the multisig example I provided. The reason I ask is largely due to mastercoin. Mastercoin uses 1-of-n multisig outputs as a method of storing data in the blockchain without creating unspendable outputs. The catch is that there isn't a wallet that will recognize or spend those outputs. As far as I'm concerned, they are unspendable by the average user. Anyway, do you find reason or incentive to recognize and support fringe case outputs such as the one in the example? If so, would you consider pursuing a wallet model that aims to recognize and spend all outputs that can be spent? Please note, this isn't a request - I'm just curious what a developer's thoughts are.

Thank you for the awesome work on Armory! I'm excited to use Armory over the coming months.

[Automatic]

Am I glad I backed up my wallets, I launched it to the majority of my comments being wiped out:-


Every single one of them had a comment before.

EDIT:- And one of my bitcoin wallets (of four, not the one that had all it's transaction comment's lost) is also corrupt (Not surprisingly, I manually hex edited this one):-


EDIT2:- Deleted and imported wallet, nothing of interest:-

Code:

2014-03-20 07:18 (INFO) -- qtdialogs.pyc:4386 - ***Completely deleting wallet
2014-03-20 07:18 (INFO) -- ArmoryQt.py:2931 - removeWalletFromApplication
2014-03-20 07:19 (INFO) -- ArmoryQt.py:3272 - Copying imported wallet to: --dest--
2014-03-20 07:19 (INFO) -- ArmoryQt.py:3340 - Raw import successful.
2014-03-20 07:19 (INFO) -- ArmoryQt.py:3399 - User requested rescan after wallet restore
2014-03-20 07:19 (INFO) -- ArmoryQt.py:2438 - Starting blockchain rescan...
2014-03-20 07:19 (INFO) -- BDM.pyc:492 - Blockchain rescan requested
2014-03-20 07:19 (INFO) -- ArmoryQt.py:5553 - Dashboard switched to "Scanning" mode
2014-03-20 07:19 (INFO) -- BDM.pyc:384 - Reading blockchain, pct complete: 14561.6
2014-03-20 07:19 (INFO) -- ArmoryQt.py:4857 - Switching Armory state text to Mgmt:User, State:ScanWithWallets
2014-03-20 07:19 (INFO) -- ArmoryQt.py:4857 - Switching Armory state text to Mgmt:Auto, State:NewUserInfo
2014-03-20 07:19 (INFO) -- ArmoryQt.py:4799 - Switching Armory functional mode to "Scanning"
2014-03-20 07:19 (WARNING) -- BDM.pyc:966 - It does not look like we need a rescan... doing it anyway
2014-03-20 07:19 (INFO) -- BDM.pyc:970 - Rescan requested, but <1 day's worth of block to rescan
2014-03-20 07:19 (INFO) -- ArmoryQt.py:5543 - Dashboard switched to fully-online mode
2014-03-20 07:19 (INFO) -- ArmoryQt.py:4857 - Switching Armory state text to Mgmt:User, State:OnlineFull1
2014-03-20 07:19 (INFO) -- ArmoryQt.py:4799 - Switching Armory functional mode to "Online"
2014-03-20 07:19 (INFO) -- ArmoryQt.py:4857 - Switching Armory state text to Mgmt:User, State:OnlineFull2
2014-03-20 07:19 (INFO) -- ArmoryQt.py:2909 - addWalletToApplication
2014-03-20 07:19 (INFO) -- ArmoryQt.py:3419 - Import Complete!
2014-03-20 07:19 (INFO) -- ArmoryQt.py:5543 - Dashboard switched to fully-online mode
2014-03-20 07:19 (INFO) -- ArmoryQt.py:4857 - Switching Armory state text to Mgmt:User, State:OnlineFull1
2014-03-20 07:19 (INFO) -- ArmoryQt.py:4799 - Switching Armory functional mode to "Online"
2014-03-20 07:19 (INFO) -- ArmoryQt.py:4857 - Switching Armory state text to Mgmt:User, State:OnlineFull2
2014-03-20 07:19 (INFO) -- ArmoryQt.py:2504 - Syncing wallet: --one--
2014-03-20 07:19 (INFO) -- ArmoryQt.py:2504 - Syncing wallet: --two--
2014-03-20 07:19 (INFO) -- ArmoryQt.py:2504 - Syncing wallet: --three--
2014-03-20 07:19 (INFO) -- ArmoryQt.py:2504 - Syncing wallet: --four--
2014-03-20 07:19 (INFO) -- ArmoryQt.py:2514 - Current block number: 291449
2014-03-20 07:19 (INFO) -- ArmoryQt.py:2528 - Blockfile corruption check: Missing blocks: 0
2014-03-20 07:19 (INFO) -- ArmoryQt.py:5543 - Dashboard switched to fully-online mode
2014-03-20 07:19 (INFO) -- ArmoryQt.py:4857 - Switching Armory state text to Mgmt:User, State:OnlineFull1
2014-03-20 07:19 (INFO) -- ArmoryQt.py:4799 - Switching Armory functional mode to "Online"
2014-03-20 07:19 (INFO) -- ArmoryQt.py:4857 - Switching Armory state text to Mgmt:User, State:OnlineFull2
2014-03-20 07:19 (INFO) -- ArmoryQt.py:5543 - Dashboard switched to fully-online mode
2014-03-20 07:19 (INFO) -- ArmoryQt.py:4857 - Switching Armory state text to Mgmt:User, State:OnlineFull1
2014-03-20 07:19 (INFO) -- ArmoryQt.py:4799 - Switching Armory functional mode to "Online"
2014-03-20 07:19 (INFO) -- ArmoryQt.py:4857 - Switching Armory state text to Mgmt:User, State:OnlineFull2

EDIT2:- Can't even downgrade now without Armory crashing. *Yay*, rebuilding databases.

[goatpig]

The missing comments, are they Tx or Address comments?

[Automatic]

The missing comments, are they Tx or Address comments?

Address comments are still there, transaction ones are gone.

[Finnminer]

OMG, it's actually working! For the first time in ages I have a properly working Armory!

I've had a ton of different problems before. They're all gone now.

Great job guys!

[goatpig]

The missing comments, are they Tx or Address comments?

Address comments are still there, transaction ones are gone.

Do you have an approximate idea of how many comments were in your wallet? The wallet recovery tool displays that so you can compare, and let me know the comments are just gone or if its Armory not displaying them.

OMG, it's actually working! For the first time in ages I have a properly working Armory!

I've had a ton of different problems before. They're all gone now.

Great job guys!

Not quite done with the ledger fixing yet but I'm glad to hear it works so far.

[Automatic]

The missing comments, are they Tx or Address comments?

Address comments are still there, transaction ones are gone.

Do you have an approximate idea of how many comments were in your wallet? The wallet recovery tool displays that so you can compare, and let me know the comments are just gone or if its Armory not displaying them.

Armory 0.90-beta, all 128 of my transactions have notes (In the UI).

Armory 0.90.99.3-testing:- You lie, nowhere on the UI could I find it telling me, except for this in the log, which, doesn't specify if they're address or transaction comments:-
284 chain addresses, 0 imported keys and 324 comments were found

Although, 284 (Addresses) + 128 (Comments from .90-beta) = 412 ~ 324 comments found (Well, closer than any other numbers.

Although, just hex editing the .wallet I can't seem to find any blocks starting with 0x02 (Transaction comment), just 0x01, although, I'm not really the best at parsing files (Just skimming over it). If you give me a minute, I'll throw something together quickly to parse it.

[Finnminer]

Not quite done with the ledger fixing yet but I'm glad to hear it works so far.

Yeah, I added another wallet that has a large amount of pooled mining transactions and Armory became pretty unresponsive. But it's not crashing so I can live with for now.

[Automatic]

Okay, threw this together:-
http://pastebin.com/raw.php?i=YcX5b2rR

Not the best code (Actually, results in "Corrupt wallet!" about half the way down the wallet), but, it's 9:30AM, and, it's just going to be used for this, so, what does it matter?

I believe that's the format of your wallet (You may want to verify it, which is why I posted it), but, it results in:-

Code:

Address:- {MyFirstEverAddressComment}
Address:- {SecondAddressComment}
Address:- {ThirdAddressComment}
Address:- {ForthAddressComment}
Address:- (Literal null character here, I can tell as it fucks up my clipboard trying to copy this, terminates here. Yay for null-terminated strings!)
Address:- [[ Change received ]]
Transaction:- {LegitimateTransactionComment}
Transaction:- {ReferAbove}

So, I'm going to say yes, there are transactions in that wallet, although, the wallet does fuck up my program (Although, that's probably my shoddy 9:30AM programming), so, it may just slightly be corrupt (But, then again, your previous version of Armory (Which I just downgraded to, and, it works fine), still accepts it, so, obviously it's something you've changed between the two versions. How fun.).

[goatpig]

I can't reproduce the comment issue on my end. Try this:

1) Load you wallet in Armory offline.
2) Restore it from paper. This will rip the meta data from the wallet if it's currently loaded.
3) Load the restored wallet and see if the comments show up

[digipl]

In windows 7-64 the problems persist.

The first time I run the program, slow scanning and freezes before finish.

The next times the scanning is faster and I can see my balances but the programs freeze again. The process service show that Armory steal alive and consume 25% of my CPU but I cannot do anything except finish process (I will try wait several hours).

In my case the only version who works is the 0.88.1. All the 0.9 versions I try, freeze or broke.

In this situation even I cannot send a bug reporting.

[Automatic]

I can't reproduce the comment issue on my end. Try this:

1) Load you wallet in Armory offline.
2) Restore it from paper. This will rip the meta data from the wallet if it's currently loaded.
3) Load the restored wallet and see if the comments show up

Issue with that is it's an offline wallet, I don't really want to restore it from paper to my online computer.

Can I just use a digital backup (Watch-only) from my offline computer? Or is there some way to do that without using the paper backup?

[Sukrim]

Why is the torrent created as "private" (no DHT, no PEX...) and not just the one jgarzik published (https://bitcointalk.org/index.php?topic=145386.0), which is already quite well seeded? You make it much harder than you need to for others to help seeding.

Also your tracker (tracker.bitcoinarmory.com) is a single point of failure that way, without it your users will NOT be able to find each other.

If you want a more recent bootstrap file, maybe suggest a change to https://github.com/bitcoin/bitcoin/blob/master/src/checkpoints.cpp but please at least make your torrent public, so people can find each other via DHT, LPD and PEX too.

[CircusPeanut]

In case you have trouble cutting and pasting the signature into the Verify Signed Message Block window, just "Quote" the message as if you want to respond to it, and cut and paste from the editor.

[etotheipi]

But while we're on the subject of multisig, do you mind commenting on the feasibility of a wallet recognizing strange outputs as spendable? That's a pretty broad question, but I didn't want to narrow it down so far as to only be applicable to the multisig example I provided. The reason I ask is largely due to mastercoin. Mastercoin uses 1-of-n multisig outputs as a method of storing data in the blockchain without creating unspendable outputs. The catch is that there isn't a wallet that will recognize or spend those outputs. As far as I'm concerned, they are unspendable by the average user. Anyway, do you find reason or incentive to recognize and support fringe case outputs such as the one in the example? If so, would you consider pursuing a wallet model that aims to recognize and spend all outputs that can be spent? Please note, this isn't a request - I'm just curious what a developer's thoughts are.

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.

[etotheipi]

Why is the torrent created as "private" (no DHT, no PEX...) and not just the one jgarzik published (https://bitcointalk.org/index.php?topic=145386.0), which is already quite well seeded? You make it much harder than you need to for others to help seeding.

Also your tracker (tracker.bitcoinarmory.com) is a single point of failure that way, without it your users will NOT be able to find each other.

If you want a more recent bootstrap file, maybe suggest a change to https://github.com/bitcoin/bitcoin/blob/master/src/checkpoints.cpp but please at least make your torrent public, so people can find each other via DHT, LPD and PEX too.

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.