Armory uses Bitcoin Core in the background so that we don't have to worry about the P2P stuff.  I mean, we have to understand Bitcoin network/protocol security, but we specifically use Core because Core is developed by a ton of people who've made it their job to harden all that stuff in all dimensions, better than we ever could.  As far as we're concerned, it's our obligation to use Core as our gateway to the network, if we want to be as secure as possible.

Armory uses a mix of Python & C++.  C++ is much more rigorous, low-level, and optimizable.  Just about any heavy-lifting is done by C++ (like scanning the 25 GB blockchain and computing balances).  But for application development, C++ isn't  fluid enough for us.  Python is extremely flexible and makes it easy to create complex interfaces, handle corner cases, threading, exceptions, and has a billion libraries available that save you time instead of reimplementing it yourself.  C++ development can be slow, and the syntax is rigorous and inflexible (for instance, it's very nice to be able to create python functions with a dozen args, set defaults, and then only specify the ones you want on a given call, you can't do that in C++).

We use a tool called SWIG which allows you to compile C++ code into a DLL and creates a wrapper to make it accessible via python.  It's actually quite magical, because python and C++ are kind of polar opposites, with a huge diversity of strengths and weaknesses.  Being able to combine them with SWIG means that you can avoid all the weaknesses and write new code on whichever side of the python/C++ fence has the strengths you need.

You can uninstall the existing version of Armory.  It will leave your wallets and blockchain and databases intact.  Nothing to worry about.  Of course, you should have a backup anyway, but an install/uninstall cycle only affects the installation directories, not the directories holding wallets or databases.

This is likely to get much better soon with the new version of Core (headers-first) announced recently.  Much of the startup time is not Armory's fault, it's the fact that Bitcoin core has a terrible system for "catching up" with the blockchain.  It's easy to get stuck behind one very slow peer and take 20 minutes to download a few megabytes.  There isn't anything Armory can do about that.

But the new headers-first Core should solve those problems, and allow you to synchronize and catch-up as fast at your full download speed.  The only time you would wait for Armory is when you need to rescan, but that should be rare these days, and will be even better in the next major release.

For reference, when I did the upgrade from RAM-only to LevelDB-backed databases, I designed the DB build&scan operations to accommodate out of order blocks in the blk*.dat files.  Basically because I heard murmurings of this change coming more than a year ago.

However, I never actually tested it and there might be something stupid preventing it from working, but it should be a very short upgrade path to make it work. 

In the future, I'd like to get away from blk*.dat files altogether and just pull things over P2P from your localhost Core instance.  If you do that, you can guarantee you get them in order, though there other nice benefits (like no longer even having to specify a --satoshi-datadir, and being able to use a single trusted Core instance on a network for a bunch of Armory instances).

If those apps are using truly poor RNGs, then I suppose it's possible.  But it would have to be pretty bad to be getting collisions within trillions of addresses +/- a few orders of magnitude.  Address strings are 160 bits.  So a collision means that two different public keys produce the same address.  If you want to "collide" with someone else, i.e. get an address string that matches someone else who has coins, it will take you approx 2¹⁶⁰/numberOfUsers.  Even if we assume a trillion users&addresses (2⁴⁰), that's still 120 bits left which is within range of universally secure (128 bits).

Now, if he wants to generate gajillions of addresses and find collisions within any two of them, that's remarkably easier, but also remarkably less useful.  The idea being that he wants any two public keys that have the same hash.  i.e. generate addresses until you have two that match.  Not useful, since you're guaranteed to collide with an address that has no money, but it would still be interesting.

In such cases, if the number scales with approx sqrt(N).  i.e. if you are generating 160-bit values, there's 2¹⁶⁰ possibilities.  You need to generate approximately sqrt(2¹⁶⁰)=2⁸⁰=1,208,925,819,614,629,174,706,176 to have a single collision.  That's a trillion trillion... while that might actually be possible with an extrardinary amount of computing power (in the future), you're still generating collisions that don't benefit you.

Scale all this by the quality of the RNG -- if the RNG is weaker, the state is reduced.  Technically, if the hash160 (ripemd160) is weak, the address space could be smaller too.  But I would have a tough time believing that desktop apps would not be producing enough entropy, as long as they are using a good RNG.

On that note, Armory uses Crypto++ was is considered a cryptographically-secure RNG (X9.17 with OS-provided seeding).  On top of that, Armory pulls in system files, mouse clicks, keypresses, and a desktop screenshot, to add to the Crypto++ RNG entropy pool.  I made sure when selecting these sources that it would guarantee at least 256 bits of entropy to be added to the pool even if Crypto++ was really weak.

You're right about the external entropy:  we don't provide an option for users to add their own entropy for the reason you described (it becomes a channel for creating brainwallets, too).  However, we do it ourselves because it's pretty simple with a deck of cards and a python shell with armoryengine loaded.  I've posted elsewhere how to do this, but I don't say it a lot because I don't want it too easy to find out  Primarily because I'm 200% comfortable with Cryptopp + external entropy, so I don't feel there's any practical reason to prefer that beside enjoying "seeing" the entropy yourself.

By the way, it's fairly established that the english language has 0.8 to 1.2 bits per letter.   Rather, grammatically correct, properly spelled english has appoximately one-eighth the amount of entropy as its length.  So for the phrase you picked as an example has 68 letters, so between 54 and 81 bits of entropy.  This is somewhat strong, but on the low-end, still brute-forceable.   

Root keys should never be generated with less than 128 bits of entropy.  That is both a reasonable, forever-secure value, and also the approximate protection level of a 256-bit ECDSA private key (ECDSA private keys have about half the seucirty of their length).

Even if you're holding $100, 54 bits of entropy is really quite terrible considering that an attacker can brute-force all brainwallets in the world with the same brute-force search.   You can improve it with some solid passphrase stretching, but for any significant amounts of money no one should even be taking this risk.

More specifically, the wallet is watching-only and not marked as belonging to you.  As a security precaution (stupid people importing watch-only wallets from others), it doesn't show you the history by default.

Either select "All wallets" on the filter at the bottom.  Or in the wallet properties, click on "Belongs to:" and change it to say it's yours.

Use the Secure Downloader within Armory.  It was designed to make this easy.  And it's especially easy on Linux:  two ways to get to it:

(1) Announcements tab at the bottom
(2) Help->Update Software

Select Ubuntu and 32/64 as appropriate.  Click on Bitcoin Core 0.9.3.  When it's done downloading, it will automatically check the digital signatures on it and then adjust your settings to use it.  Just restart Armory.

FYI - There's a few threads on this subforum already about this.  I wont' repeat them but they should be easier to find.

But when you do find them, I'll tell you something you can share with them:  the latest release 0.92.3 adds options explicitly for using Armory with Tor.  You can either use "--tor" from the command line (best option), or load Armory once and go into the settings and select the Tor-friendly option there.  There was some issues with previous versions of Armory doing various checks outside the proxy.  Make sure you're using the latest.

That error suggests a malformed transaction.  I'm not sure how that would happen since Armory is creating the Tx for you and thus it shouldn't be malformed.  Perhaps the DB is corrupt and it's blindly dumping a corrupt previous-tx into the one you're trying to sign?   Strange.

But it is true that if you have a lot of dust, you should try sending yourself many small transactions to try to clean it up.  If you have 0.1 BTC with 1,000 inputs, try sending yourself 0.01 at a time.  Your balance will remain the same, but then once it all confirms you'll be able to send all of it at once (then it only combines 10 inputs instead of 1,000)

You're confusing the paper backup and bitcoin private keys. 

- The paper backup is a seed that allows you to recover every private key ever created and will ever be created by your wallet.  It's called a "deterministic wallet," and Armory was the first wallet to implement that which is why it's not compatible with anything else.
- The individual private keys are what hold the actual money.  Those are derived from the paper backup.  Backing those up only backup the coins they currently hold, but don't help you if you use more addresses.

In your case, you want the private keys.  Start Armory in offline mode (there's usually a shortcut installed with it specifically for offline mode).  Then load the Armory wallet and go to backup options.  "Export Key Lists".  There you can get the first 100 raw private keys that can be imported into another app (you might have to click "Include unused" since Armory will think that all the addresses are currently unused).

 

Sorry for the delay guys.  First, my release script was broken, and I wasn't able to sign the 0.92.3 tag before making the full release.  I had planned to do it the next day.  The next day my primary hard-drive died before I could complete the process.  D'oh!

Anyways, I got everything sorted out now and I just pushed the tag v0.92.3.  That should complete the release.  Future releases should have the signed tag pushed at the same time the signed installers are uploaded to S3.

More specifically, if Armory runs Bitcoin Core for you in the background, sometimes it will leave Bitcoin Core running in the background if Armory crashes.  guardian.exe is a very short program with the sole purpose of killing Bitcoin Core if Armory fails to close it.  It was especially important on Windows where Armory would mysteriously fail to close Core even on a clean shutdown. 

If you quarantine guardian.exe and don't allow it to run, you'll be fine.  But you might occasionally start Armory and it will tell you Core is already running, even though you never started it.  You'll have to go into the task manager and kill it manually.

In wallets that are encrypted (should be most of them) it sometimes generates all the addresses from the public keys when it doesn't have your password to generate the private keys with it.  In that case, it marks all the private keys to be calculated next time you unlock the wallet, which could be a lot of keys.  But once it is done, or won't need to do it again so each subsequent unlock should be much faster

The act of hashing a password doesn't increase its entropy.  The number of possible passwords is the total entropy.    You can use sha256¹⁰⁰('bob') as your brain wallet, but anyone who looks at your applet will see that it uses sha256¹⁰⁰(pwd) and will write a program to start guessing through possible passwords passed through that function.   All users that used "bob" as their password will immediately have their coins stolen, regardless of how many times you hash it.

A while back there was a user here who write a program to do a brute force search of brainwallets that use sha256(sha256()).  I believe they found in excess of 100 BTC.  Because people pick memorizable passwords and wanted to believe that no one would find it.   And in reality, people don't realize just how fast computers are at guessing and how weak their own entropy is.  For your reddit login, the stakes aren't very high.  For $100,000 bitcoin wallet, I would be horrified if someone used a brain wallet.

Admittedly, your little javascript applet is very slick.  But Armory Technologies will not be supporting the functionality since it so easily leads to lost coins.  Our job is to not only create secure software, but to promote best security practices.  Having a solid backup solution is one of those best practices.

Bitcoin-Qt was relaying them (I had some of that dust, too).  It but it wasn't re-relaying them, so clearing the mempool made them go away. 

It's possible, if you restart Core, that its memory pool will clear allowing them to be re-relayed again if someone rebroadcasts, but I think the newer versions of Core should reject them as non-standard and not relay them.

Armory has a memory pool file that persists between loads.  However, you can manually clear it using Help->Clear All Unconfirmed

If they show up again, then Bitcoin Core is rebroadcasting them (perhaps to try to get them mined?).

First of all, there are some examples you can use in the extras directory in the project.  Also some stuff here:

https://bitcoinarmory.com/developers/python-scripting/

Those might be slightly out of date, but require minimal modification to make them work.  And for such a script, I recommend doing TheBDM.setBlocking(True), which is better for scripts ... it means that the BDM, while still in a separate thread, will behave like it's in the same thread, and every request will block until it's done.  The sample_armory_code.py in the extras directory shows you an example of both.

You can use wlt.getTxOutList('Spendable') to get a list C++ TxOut objects:

https://github.com/etotheipi/BitcoinArmory/blob/master/ui/TxFrames.py#L826

You can then run them right through Armory's coin-selection algorithm:

https://github.com/etotheipi/BitcoinArmory/blob/master/ui/TxFrames.py#L598

That should be enough to hold you over in the short-term

Armory Technologies strongly advises against the use of brain wallets under any circumstances.

• For most humans, a wallet with sufficient entropy to be secure would not be memorizable.  Thus, if it is memorizable, you're at significant risk of someone being able to steal your funds with brute-force searching.
• Human-generated passwords have terrible entropy.  You must use a cryptographically-secure random number generator to create your wallets.  Armory provides this for you, but not if you use a brain wallet.
• Humans brains are not well-adapted to remembering such information for long periods of time.  You may remember it now.  You might remember it in 6 months.  What about 3 years?  10 years?  If you've ever forgotten a password, do not use a brain-wallet.
• Even if you think you can get around the three points above, it still means that you take your Bitcoins to your grave with you.  If I was your parent/spouse/kid, I would hope that if something unfortunate happens to you that I'll have a way to get access to your savings.  Brain-wallets have no such mechanism and the coins will be lost forever.

To anyone who wants to better protect their wallets, we strongly encourage you to use a regular Armory wallet with fragmented backups instead.  They provide a flexible combination of physical security, redundancy, will have sufficient entropy, and be recoverabe by family members if needed.  

We can't stop people who are really determined to make brain wallets, just don't say you weren't warned!

Yes, that should still work for the regular non-offline-bundle installers.  And it was supposed to work with the debs inside the bundle, but it seems that I make the bundles before I sign the .debs (so the bundle ends up with the non-signed version).  But the whole tar.gz gets signed anyway, so the dpkg-sig signature is redundant, and the fact that I screwed up the redundant sig is what threw you off.  It's better to use the hash anyway, since it covers all the files in the .tar.gz, not just the Armory installer itself.

I'd like to make this simpler, but there's just so many OSes, so many signature layers, and a complex web of operations performed to make sure everything is consistent (such as making sure that the installers are signed before making the hashes file, which needs to be signed, before creating the announce digest, that needs to be signed, so the secure downloader gets the right file with a valid signature.  I wish we could just use the secure downloader for everything, but the fact is that people have to somehow verify the first version of Armory that they get, which requires the GPG stuff.