It appears that Riverbank Computing released a new version and killed the old PyQt4 link I had posted.  I have updated the links on the Get Armory! page, and Cypherdoc claims that it worked for him.  He ran into another problem, but it was either due to not clicking the "install_zope.py" script, or needing to do it twice, not sure which.

I know that installing programs and having a console window open is super annoying in Windows.  Unfortunately I have no other option -- I have spent hours trying to figure out how to get Armory to shut down cleanly in Windows.  If I were to make binaries right now, all the RAM used by Armory will stay locked, even after you close the program.  I will figure it out, and I will make binaries.  Thanks for your patience!

Also, I just posted a powerpoint presentation on Using Offline Wallets on the webpage.   Please take a look and give me feedback.  Alternatively, you can view it locally by downloading it here.  It will look a little better locally, anyway -- it appears that slideshare butchered the quality of the presentation, but it's still readable.

Cypherdoc,

PM me with the exact error.  I'll help you figure it out.

New version!  0.5.1-alpha.  Download at:  http://bitcoinarmory.com/index.php/get-armory

This is a minor-complexity update, but a very important one!  The Feb 20 protocol switchover was not previously handled in Armory, which is fixed in 0.5.1.  If you don't upgrade to 0.5.1, Armory will stop working sometime on Feb 20. 

This also gave me the opportunity to commit a fix for P2Pool coinbase transactions.

At least it's an easy upgrade.  It amounts to changing half a line of code in Armory.  I'll be pushing the update tomorrow or the next day and post on the Armory thread.

I would guess that timezones don't matter.  Worst case, some users fail to connect to peers for a couple hours, but even that's a stretch (any peers in the same time will be sync'd with you)

I suppose I can add such support, but it feels like a step backwards.  I believe the security improvement of non-deterministic wallets over deterministic wallets is tiny (if any) , yet creates all kinds of backup problems -- requiring a persistent backup solution, along with having to backup hundreds of individual keys instead of one master key (which also means a paper-backup could be many pages, and recover would require entering hundreds of keys).

That doesn't mean that no one should have the option.  It's just that I haven't seen any demand for it.  And it might be a bit of work to get it right, so I would need more than one person to request it.  Anyone else, please speak up if you want non-deterministic wallets as an option.  Otherwise, if you need help being convinced that there are basically only advantages to deterministic wallets with negligible downsides, I'll be happy to debate that with you

At the moment, all network information comes through the Satoshi client, I don't have a choice.  Once I bring down the RAM requirement I will work on more independent networking (or integrating existing Satoshi networking code into Armory).   I wouldn't consider not having some kind of validation for incoming network data.

btc_artist,

(1)  Did you try the LD_PRELOAD command before running Armory?  I've noticed I need that on any Ubuntu after 10.04:
  Make sure that /usr/lib/libcryptopp.so exists, or check for libcrypto++.so and use that instead.   But they should be there if you installed all the packages on the first step.

(2)  If that doesn't work, there's a different problem.  From the project directory, go into a python shell and type "import CppBlockUtils".  It will fail again, but will give you a more-descriptive error message.  If it's something like "InteratedZZ8CHashZ5Function", go back to step 1 (cryptopp has a problem).  If the error is something else, please PM me and I'll address this off-thread.   So far, I haven't seen any other errors besides the cryptopp linking at runtime (which is what the LD_PRELOAD line resolves).

There's nothing stopping the charity from importing their previously-created private keys into their Armory wallet before forking the watching-only copy for you (imported addresses will be copied-without-private-key data the same as the deterministic addresses).   It would be in the charity's best interest to consolidate all such addresses into the same wallet, anyway.  Having loose addresses like that is a liability.

Arguably, maybe they consolidate addresses later after you have already received the watching-only wallet.  So they will send you the address, but Armory doesn't allow you to import watching-only addresses!   I argue, if they're sending you the address by email, they could just as easily send you the updated watching-only wallet instead.  It's mostly redundant information, but wallet files are very small unless they contain tens of thousands of addresses.

I agree that you are promoting a desirable feature, and I will implement it eventually.  But I believe that the current capability of Armory covers most use cases already, and current priorities eclipse this one (like bringing down the RAM ).  I will add this to my list of things to do before a final release.

The charity situation you mentioned is a prime example of a problem that's already solved by Armory.  If the charity wants to allow me to see the charity funds, they'll give me a watching-only version of the wallet they are using.  If they don't want me to see their funds, they wouldn't give me anything, and I won't have anything to monitor anyway.   I believe that most use cases are covered by existing Armory functionality, simply using watching-only wallets.    Because deterministic, multi-wallet clients are not widespread yet, most users still think in terms of individual addresses in a single wallet.  When you do consider it, you'll see that most of what you want is there.

However, I believe that it wouldn't be a bad idea to allow watching-only-address importing into watching-only-wallets.  I will have to revamp the import/sweep functionality a bit anyway, to accommodate bulk key imports (due to slower blockchain scanning).  It might be straightforward to expand it for this purpose. 

It appears that there really is a one-line fix, or very close to it.  I confirmed it only saw 2/13 tx before, and sees 13/13 with the fix.   But it will have to be more thoroughly tested, so I'll throw it in with the other updates I've been working on, for the next round of testing.  I hope that Armory provides plenty of satisfaction even with the bug, until the next release.

Actually, yes!  Until now, I haven't run into any "strange" transactions that "regular" users would be encountering, but this appears to be an exception.  As I look back to the code, I see that once I hit a strange TxOut, the code skips the entire tx, marking it as "Non-standard."  In hindsight, I don't see why I can't just skip that TxOut and keep going.  When I originally wrote the code, I guess I expected the "transaction" to be non-standard or not... didn't consider the individual inputs and outputs.

Could you give me the address (just the address string, no private keys), of an address that receives coins from at least one of these transactions, but also has a few other regular transactions in the blockchain?  There may be a one-line fix to the C++ blockchain utilities, but I won't know for sure until I do some testing with a relevant address.  

I'll look into it ASAP! (PM it to me, so you don't have to advertise any extra addresses to the forum!)

The other option I saw was BundleBuilder.  That might be worth looking into as another option.  Unfortunately, I still don't have any OSX system yet.  But I'm working on it...

Actually, the offline systems have no RAM requirement at all, as long as it can run a modern OS.   Simply because there is no blockchain to hold.  It only has to hold your wallet.

This is already possible with Armory.  You create a full wallet that has the private keys (which might be created on an offline computer that never touches the internet), then "Create a Watching-Only Copy" of it, which doesn't contain any private keys.  You can even import private keys into the full wallet before you fork the "watching-only copy" and those addresses will be monitored the same way.  Import that wallet into Armory on your online computer, and you can watch all the addresses without having the private keys exposed to the internet.

If you only have one computer, you could create the full wallet, print a paper backup, then delete it from the computer and keep only the watching only version.  However, this would make it super-annoying to spend any of that money, requiring you to re-import that wallet from paper every time (though, what other options do you have if you don't want to keep the private keys on any computer, anywhere?).

What I don't have, is a way to import public keys directly into a watching-only wallet (only private keys into a full wallet).  But that should be an easy upgrade if it's a high-demand feature.   But, in the end, the private key has to touch some computer at some point, unless you plan on calculating the public key and address from the private key, with pencil&paper.

The beauty of Armory is that the watching-only wallet, will be able to generate an infinite series of [deterministic] keys, that can be used to receive Bitcoins, and the addresses it generates are exactly the same as are generated by the full wallet (this is described by gmaxwell as a "type-2 deterministic wallet").  This allows you to manage all your money from an online computer without the private keys, and use new address for every incoming transaction.  The only real risk is that, if the online computer is compromised, your privacy is breached but the security is not (they can't spend your coins, but they can link all the addresses used by that wallet).

If you want to spend the money in these addresses:  well that's what the "Offline Transactions" interface is for -- allowing you to shuttle transaction data between online and offline computers using a USB key, and the private keys can stay offline.  And Armory will walk you through the whole process.  See Using Offline Wallets in Armory for more information (illustrated tutorial coming soon!).

I think that completely covers the use-cases you asked about.  If there is a feature missing from this description, please let me know, and I'll see how I can accommodate it in a future release! 

EDIT: I realize now that you were talking about "trade value."  I assume you are talking about grabbing MtGox+Tradehill price for your local currency, and displaying the balance of your wallets in that currency...?  That would literally be a few lines of code added to Armory to query the prices online, and then replace the "Balance (BTC)" field with "Balance ($)" field.  After that, everything I wrote above is applicable.

That was the fundamental issue I had when developing BIP 0010 for offline/multisig transactions.  How do you verify that the what you're signing is absolutely what you intended?  I do not support a device that blindly signs txs, and that's why I went a step further with BIP 0010 and made sure that input values can be verified (without it, someone can't steal your money, but they can have all your funds emptied into your next transaction's fee).  I wanted to make sure that the signing device has the capability to understand (and verify!) what is being signed and present it to the user.  If someone wants to create a device that blindly signs it... well that's their choice, but I won't be using it.

In the case of offline computers, there might be a way for someone to use my computer to inject a USB virus which infects the offline computer, and then uses that trick my offline computer to show the same incorrect/malicious data.  That's orders of magnitude less likely than someone simply breaking into open ports on my internet connected computer, but a TPM-device would close that gap:  the TPM chip was designed without the ability to modify the software, and without the ability to pull off the private keys.  It's simply a hardware-like black-box wallet with a display. 

I believe Bitcoin needs these devices, but offline systems will do, for now.  As I found out when I sent out an email at my work about spare, ancient laptops:  everyone seems to have one they want to get rid of.  Perhaps Armory gives them a reason to keep it and use it

I absolutely plan to have that, but not until Armory can be used without the Satoshi client running with the same wallet.  I found out yet another thing that can go wrong when you have multiple apps using the same wallet (I've got 8.2 BTC locked by the Satoshi client right now, possibly due to such issues)...

I believe what you're looking for is TPM Chips.  I don't know much about them, but I know a lot of laptops actually come with them.  However, you would need a customized TPM chip, specifically for accommodating multiple private keys, and ECDSA operations which are not usually part of the onboard encryption ops.  Actually, I guess you could have one master key, and use a deterministic key generation algoritm with random access.  Then the device takes the data to be signed, and a list of "key indices."  Then, generating the correct keys will just be a preprocessing step of the signing algorithm.  (btw, I believe the IronKey is a TPM-like device... all encryption/decryption happens on the device itself)

At least, the nice thing about an offline computer is that you could technically do other stuff with it.  It might be slightly less convenient for Bitcoin ops, but as long as you have it, you might as well do financial stuff on it that you would prefer to be offline, anyway.  I'm sure there's other things you can do that would be appropriate for a crappy, offline laptop

FYI, I finally remembered to update the original post about the encryption issue.  Should be complete now.

torus,

That looks great.  You make it seem like it was so easy!  I think I'll be getting my hands on a Snow Leopard machine 10.6.7, so I will try these instructions when I get it, and I will update the webpage with this information, too.

Are you familiar with py2app?  I would like to create Mac binaries, if possible, and that seems like a good option for it, especially for Mac where compiling has been so difficult.  Are such binaries likely to work on all Mac systems?  Only 10.6.X systems?  


runeks,

I have quite a bit of experience with cryptography, but not specifically secure programming.  The python/C++ mix probably "hurts" security a bit due to not respecting the memory-management rules I designed into the C++ code (i.e. the SecureBinaryData container).  But I believe there are very few attacks that would be able to take advantage of sloppy python garbage collection that wouldn't also be able to take advantage of a solid, pure C++ solution -- if they have access to your local process-memory or DMA, you're pretty much screwed no matter what solution you have implemented.  There's a slightly higher risk that keying data could be left in memory and then written to swap space, but again, they would need low-level access to your HDD to get it, which again usually implies the whole system has been compromised.  In nearly all cases, if they can leverage one of those attacks, they already have enough access to the system to install a keylogger on the system, and then get your encryption passphrase and wallet next time you unlock.

The other major point of failure would be what you mentioned: actual wallet-encryption.  Here is the post about it, which I updated recently for-the-record:
    

• https://bitcointalk.org/index.php?topic=51474.0

This was the inspiration for Armory's wallet files, which were designed to be straightforward for other developers to implement, while at the same time guaranteeing in-place overwriting of key data, or blanking of deleted data.  I was frustrated with the difficulty of accessing wallet information, as well as the general uncertainty about how BSDDB was handling the data.  I figured, a manual binary solution, with error-correction and manual ACID-like operation was not terribly difficult.  Mainly because the access patterns for a wallet are much simpler than an arbitrary application:  usually only appending key data and comments, or overwriting data with equal-sized strings.

Some might say that your OS/filesystem might not actually delete stuff, and instead rewrite the whole wallet to a new location and leaving the old one (much like the BSDDB bug described in the other post).  The Bitcoin devs themselves acknowledge such concerns are outside the scope of the application.  They/I could spend months coming up with something 1% more robust against specific kinds of attacks, for a specific filesystem types, but in the end, the user error/laziness will dominate the security concerns.  

My attitude was that you should do everything you can to protect online wallets, but you'll never fully succed.  Enter offline wallets.  If the keys never touch the online computer, the available attack vectors are two orders-of-magnitude harder, and require much more specialized viruses.  Those might even be avoided by using pure visual communication (QR code exchange via dual webcams, or IR tx/rx of binary transaction information).  But in the end, I think that's tremendously more complexity than necessary to keep yourself secure (it would confuse people more than it would add security).

Finally, python development is about 3x faster than C++.   And it already took me 3-4 months, as-is, to produce the existing python codebase (the rest of the time was spent on the underlying C++ code).  I'm not sure if Armory would even exist if I hadn't done most of it in python.  I'm a patient person, but I'm not *that* patient (which means you should give a lot of credit to Satoshi, for having been able to do it by himself, and took him 2 years).

I want to brag that not only did I just release Armory Alpha, but I bought a few Casascius bitcoins (because they're cool), and just peeled off one of the holograms on a 1 BTC coin and swept it using Armory.  It works!  I guess it would've been a good idea to take a screenshot... d'oh!

Also, the 10 BTC rounds are damned sexy.  They're expensive (20 BTC for a 10 BTC coin), but they're also an ounce of solid silver, and come in a nice jewelry box with protective case.  Even if BTC crashes, it's about $35 worth of silver (like a dual investment!)

Just FYI:  I already applied those patches to the codebase and verified that they don't affect Armory running in Windows or Linux.  The only thing that might need to be modified, still, is the Makefile (but I'm pretty sure that was patched, too). 

After Joric posted, I patched, tested and committed it, then modified the directions slightly and posted them on the Building Armory from Source.  Probably doesn't fix your problem, but it's worth mentioning since I don't think I responded to Joric's post directly.