I've had quite a few people contact me, excited about the fragmented backup.  It's essentially done under-the-hood already, and was going to go into the new wallets, but those are looking like they're going to be on the back-burner for a while.  I'd like to provide the feature now, but I'm concerned about a few things:

• It's a lot of data
• I am going to be reworking the backup system with the new wallets... I don't want to re-write it twice in order to support fragmented backups now, and then do it again later for the new wallets
• I don't want to end up with even more versions of backups that have to be supported in the restore-paper-backup dialog

As I said, I had hoped I could just finish the new wallets and get it all out there and make all the old wallet stuff, legacy.  In order to balance all these different things, how would you (whoever wants this feature), feel about a halfway answer?  I would create a "frag_wallet.py" script that would take a given Armory wallet, ask for your passphrase to unlock it, ask for M and N, and it would spit out N text files (of which you need M to reconstruct).  Similarly, there would be a "unfrag_wallet.py" script, which you would dump M text files in that directory and it would create a new Armory wallet file for you, exactly as if you had restored from paper backup.

The text files would contain everything that's needed, and each one could be loaded and printed separately, or copied to different devices.

Also, there is so little source code for doing this, it looks like the entirety of the code needed could be printed on one or two sheets of paper.   Granted, the script itself for reading and writing files, error checking, opening Armory wallets, is quite a bit longer -- but the raw code needed to reverse-engineer the calculations is small.  But if users were concerned about not having the source code that generated the finite fields and how to reverse it, this could resolve any concerns (either way, it'll permanently be part of Armory code-base, but I know some people prefer that specific code to be backed up, too).

So would people use it as a command-line utility?  Even knowing that in a couple months there will be new wallets, with shorter seeds, with a native GUI interface?  There's no reason this script would have to go away... I'd leave it in the "extras" directory and you'd always have access to it by downloading the repo, and it would serve as further example code.  It would still be there and still work in 10 years from now.  It would simply create an older Armory wallet that would have to be migrated to the new wallet format (which will have to be done with all older wallets, now, anyway).

Thoughts?

First of all: please keep your paper backup secure.  There is no encryption on it.  It's to protect you from hard-drive loss or bad memory (now had two more people email me asking how to recover their wallet after forgetting their passphrase, and I had to tell them their coins might be lost).  In the future there will be more options to back up your wallets, but it's not there yet.

To answer your question:  the only way you will know that someone has restored your back up is when it's too late.  They will transfer all the funds from that wallet to their own wallet that you don't have access to.  By the time you realize it, you will see the target address that the coins were sent to, but it won't be an address you control.  There have been attempts in the past to try to track down such thefts, but it's generally futile -- it's too easy for a thief to hide their identity and mix the coins to obscure its path out of your wallet. 

I recommend keeping your paper backup in a safe-deposit box.  When the new wallets are done, I will have a way to do "fragmented backup" so that the paper will be split up between, say, 5 sheets of paper, and any 3 of them will recover your wallet. 

Wtf.  You're right.  I can't believe I confused myself with bits and bytes!  

But my point of reference was still correct:  I know that typing a regular paper backup is "annoying", so typing 6 times as much would be more than "annoying."  Granted, I use hex right now, and should probably use base 64 instead as you suggested.  Though, part of the reason the paper backup uses a different alphabet than normal hex is so that it's easier to touch-type, since most people don't touch-type numbers very well.  If anything, I'd probably switch to base-32, but then I'm not gaining much over hex...

On a related note, can someone please find for me one of the few largest 512-bit prime numbers?  My lookup table of primes stopped at 400 bits, and I haven't been able to find an appropriate one for 512.  Having that would make it much more straightforward to fragment the current paper backups, rather than fragging the root key and chaincodes separately.

I got the RPC thing figured out -- I securely create it myself if it's not there, before starting bitcoind (using a 128-bit random password).

If the user doesn't have bitcoind available, I want to have a button that will basically get it for them, along with links in case they want to get it themself.  In Windows, this means downloading the .exe into a temp directory and then executing it.  In linux, this may mean setting up the Ubuntu PPA, or downloading and unpacking it for them.  It sounds like there is not really an equivalent option in OSX...

Also, I don't want to bundle bitcoind with Armory, because I don't want to be responsible for quickly releasing new versions of Armory when vulnerabilities are found in Bitcoin-Qt requiring an update.

Crap!  So then... should I just make "Manage Bitcoin-Qt/bitcoind myself" the only option for OSX?  I think loading Bitcoin-Qt is a problem, because Armory will expect to manage it, but then the user may close it and Armory won't know what to do.  The number of permutations of things I have to handle to implement this is already annoying, I don't want to add that to it.

I assume you can still use RPC with Bitcoin-Qt on OSX?  If not, then it's not even an option.

It won't.  It's an unrelated task.  But it's one that I need to do to make Armory a little more accessible, and quite a bit less error-prone.  No more asking the user to press buttons or start applications at the right times, with wacky behavior if they get it wrong.  It will just "Do the Right Thing" and Armory will look like a single program.

One more thing:  you mentioned "/Applications/Bitcoin-Qt.app/Contents/MacOS/Bitcoin-Qt".  Does the default installation include bitcoind?

Thanks for the info, that's exactly what I was looking for!  

FYI, I'm hard at work plotting out my move to reduce RAM usage...

But I'm also working on having Armory manage bitcoind/-qt for the user.  I'm fairly confident I can have Armory find Bitcoin-Qt and run it in the background in Linux and Windows, but I don't have a clue in OSX.  And since upgrading my OS, I no longer can get VMware running in order to load my OSX VM (which I spent so much time finally getting working!). 

There will be an option to use Armory the old way (run Bitcoin-Qt yourself, and wait for it to sync), but I want to make that the non-default setting, and just manage it automatically for the user if I can find it.

So, is there a semi-standard location that I can use to go find the Bitcoin installation?   It doesn't have to be precise, I can search directory trees pretty easily with python, but I need a hint of where to go.

It's best to use a different address for every transaction you receive.  Otherwise, every person you transact with will be able to see every transaction you've ever made and your entire balance.  That's a pretty serious privacy issue, especially if you hold a lot of Bitcoins.

Every time you hit the "Receive Bitcoins" button, you're going to get the next address in that infinite chain of addresses.  Since thye're all derived from that initial seed, you don't have to backup each one of them, you only have to backup the seed.  If your HDD dies, you only have to install Armory on another computer and "Restore from Paper Backup."  Armory will recompute all the same addresses, and show you the same balance you had before.  You'll still lose all the comments/labels that were stored in the other wallet, but better than losing the coins!

With a deterministic wallet, there is a root piece of information (in Armory it's a "Root Key" and "Chain Code", in other applications it's just a "seed").  In all cases, that root information is used to derive all addresses ever created by the wallet.  If the wallet is destroyed, you can "Restore Paper Backup" and put that data back in, and it will generate the same [almost-]infinite sequenece of addresses it did the first time.

Even more importantly, because of the algorithm it uses to derive the private keys, you can actually generate the same sequence of addresses only knowing the public keys.  Hence the "watching-only wallet" -- you copy it once from the offline computer to online computer (it's just a copy of the wallet but without the private keys blanked out), and it will produce the same sequence of public keys (and hence, addresses) as the full wallet does on the offline computer.  So you can use the watching-only wallet identically to a full wallet (generate addresses, monitor incoming payments), but you just can't send funds without getting a signature from the offline computer.

I think the process is documented well enough in the program itself, and there's the Offline Wallet Tutorial for backup.  Let me know if you still find anything confusing!

-Alan

Any OS that handles USB keys will work (and runs Armory).   See the Armory Quick Start Guide

As for memorizing the data... it's a lot of data, and it's not in a good form to memorize it.  As Justus pointed out, you would want to memorize the root key and chain code, since all private keys are derived from that, but it is 64 bytes (128 hex characters).  I don't know if you can/should try to memorize that.  And I don't support any such activities that lead to your life savings going to the grave with you when you get hit by a bus ...

What's the timeframe on that?  What is the criteria we're using to say it's final?  I ask, because I've been hitting my new wallet format pretty hard, and I realize you're right -- if there's any chance BIP32 will change, then it could cause a mess for any users that already created wallets with the old ones.

Related:  I actually ran into this in my first couple releases of Armory where I was still tweaking the wallet algorithm (this was 12+ months ago).  I created "Wallet ID" strings that are 6 bytes long, used to distinguish wallets.  The problem was, different wallet versions using the same seed were producing the same ID because it was only based on the public key of the root.  I later decided it should be based on both the root public key and the first derived key (in this case, it would be root public key, M, and M/0 public key).  This way, the ID is encoding the root and the chaining algorithm at the same time.  It seems like a small thing, but as a developer playing with different wallet versions, it made it very easy to determine whether a wallet was generated with the same chaining algorithm you are expecting.

By the way, for reference, my BIP 32 implementation in C++ using Crypto++ is here.  Rather, that's the ChildKeyDeriv function, which is the core of BIP32.  There's some test vectors there, too, but I won't make it too obvious how to find them, since we aren't promoting it yet

Indeed.  This is something I noticed which happens when there is a re-org/orphaned block.  It inspired me to re-run some unit-tests that hadn't been run in a while, and led to semi-release of 0.87.2 (only available from the googlecode download page).  I never made an official release, because I had released 0.87 a couple days earlier and didn't want to spam users with it.

Until you upgrade, restarting is the only thing you can do. 

EDIT: Actually, I don't think it was re-orgs, I think actually when two blocks are received at the same time...  well doesn't matter... both were fixed in 0.87.2.


I don't have a good way to describe the entropy generation:  it is handled by the Crypto++ library's AutoSeededRandomPool, which is a FIPS-140-2 validated cryptographic library.  It is considered "suitable for cryptographic purposes."



Armory does test system speed and sets the encryption parameters.  This is not the same as the deterministic key generation ... that always takes the same amount of time.  What is adjusted is how long it takes to convert your passphrase into the encryption key used to encrypt your wallet.  Basically, how long you have to wait between entering your passphrase and pressing <Enter>, and when the keys actually get unlocked.   

When you create the new wallet, there will be "Advanced Options" where you can adjust the time and RAM usage of the key-stretching.  The longer the amount of time you specify, the more computation it does, and the more RAM it will use.  Note that RAM usage above 64 kB is acceptable for disarming GPU-acceleration.   If you set the time really long, you will get up to 32 MB, which is extraordinary overkill.  The point is, it is configurable.  You can make it up to 20 seconds if you want, but it will be pretty annoying to sign transactions.


You are correct, the paper backup is not encrypted.  The goal is to protect against digital/virtual threats, not physical threats.   If you are concerned about physical security, you should put it in a safe-deposit box at a bank.  There is no encrypted paper backup option, though there is a "fragmented" backup option coming with the new wallets!  If you really want to encrypt your backup, then make a digital backup of your wallet to a USB key or a CD (which will be encrypted if your wallet is encrypted).  Just be sure to make a couple copies in case one fails.  Though, it's highly recommended you make at least one plaintext backup and keep it physically secured.  Your family will thank you for that (post-mortem) if something terrible were to happen to you.

When I'm done with the new wallets, I'll be reworking the backup system into a single, complete dialog that will walk you through the process and provide all the appropriate warnings.



Luckily, all Linux distros are expected to default to no-autorun at all.  However, the default is to automount and *ask* you if you'd like to run something on the inserted drive.  This isn't the same thing as "no autorun vulnerabilities", but it does cut down on them by an order of magnitude.   You can google for a few ways to configure this behavior.  I left it out because it's probably confusing to some users and not so necessary when the autorun is already disabled.  Here's some links. 

http://ubuntugeek.com/forum/index.php?topic=4639.0
http://ubuntuforums.org/showthread.php?t=974087

FYI, I ordered an Acer 24-inch, 1920x1200, IPS LCD monitor from BitcoinStore.  I received it in the time frame expected (in a couple days), and everything was peachy.  

There was a problem with the purchase, displaying an error about shipping calculations and I had to contact customer service.  It was resolved very quickly, and it may not have even affected overall delivery time.

By the way, a 24-inch, 1920x1200 IPS LCD monitor is an excellent deal for ~7 BTC.  Granted, the backlighting is a little weird, and the colors were slightly off, but I was able to adjust the settings and it feels close to my other IPS monitors  (in terms of display quality).  If you don't know, "IPS" monitors are typically much more expensive than "regular" monitors because of the display technology.  Most importantly, the viewing angles are dramatically better.  This is especially important for large monitors, since the wingspan of the flat monitor typically induces non-90-degree viewing angles towards the edges of the screen.

By the way, I do agree that the search & organization of the site could use some improvement.  You need to at least make it easier to find the higher-demand products.  I was disappointed to find out you didn't carry any smartphones ... but then I found you do!  But I had to do some digging. 

P.S. -- If you start offering the Google/LG Nexus 4, you'll get my money right away

To further clarify:  the offline computer has just about NIL system requirements:  256 MB of RAM should be enough to run offline Armory.   Online Armory... needs quite a bit more (I'm working on reducing it, now!).

There is a version of Armory for each 32-bit and 64-bit Windows, and it works in both XP, and Windows 7 (not sure about Vista and Windows 8, but I don't know why not).

In Linux, I recommend what Justus mentioned:  install 10.04-32bit and download the offline bundle.  It has everything you need to install and run Armory on the first boot of a fresh 10.04 installation.  It works in most other versions of Linux, but installation usually relies on fetching dependencies from the internet, and it can be challenging to do that in an offline environment.

For reference, here is the Armory Quick Start Guide.  That has a link to the offline tutorial, too.

Strange.  Can you confirm that they aren't all in your wallet, now?  Just to be sure that it didn't silently succeed!  

If 1-3500 succeeded and it failed at 3501, can you try importing just 3502+ and see if it works?  There's certainly no limit on the number of keys that can be imported, I'm just wondering if there's something funky about the first key that failed.  Also, I suppose something like invisble binary characters in the text stream could be the problem.  Can you try copying and pasting just the 64-hex-chars without any trailing or leading whitespace?  

Also, I doubt this is your problem, but if that key is higher than 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141, then it's not actually a valid key and Crypto++ chokes on it.  I have run into this before, when I was making fake keys just to test some armory code and "FF"*32 was causing garbage answers (and frequently segfaults!).  Now that I mention it, I don't know why I don't put a check for this in the GUI... 

EDIT: Just to be clear:  of the 2²⁵⁶ 32-byte integers, the top ~2¹²⁸ are not valid ECDSA keys, approximately 0.000000000000000000000000000000000000001% of them -- no one bothers talking about it because the chance of picking an invalid one by accident is nil.  But if you are creating simple keys manually for whatever reason, it's possible to run into this -- I know at least one other user who has done the same thing!

By the way, I saw your extract-keys pull request... I will look at it in a bit... I'm a bit swamped with things.  But I've been meaning to update the app to be a little more flexible with those things...

Weird!  I've never seen that before!  Can you send me a log file?  I can't even think of how that is possible without actually being on testnet.  But Armory is very good about not mixing networks -- it's always checking prefix bytes and magic bytes to make sure you're not connected to the wrong thing.

Glad it's [mostly] working for you!  Let me know if you run into anything else.

You can just manually copy the code from the paper backup.  It's a nice convenience to be able to print it, but not strictly necessary.  Just copy the four lines by hand and store it in a safe place.

The problem with this is that "putting it in your will" is essentially equivalent to "giving it to your attorney".   Someone else has access to it in some capacity, since they obviously need to access it in the event that you die. 

Just like the bank employee snooping thing, it might be far-fetched, but some people are too paranoid.  I think it makes sense that your will would contain a significant portion  (say 2 of the 5 required pieces), making it considerably easier for your family to recover your funds once they see the will but not allowing your attorney full access to it if he "turns" on you.

There's a lot of permutations, and I fear that this could be "too complicated" for many folks.  I think I'll limit it to "require 2 or 3 fragments" below Expert usermode, and you can make any number of fragments.   By the way, the algorithm that I have implemented uses deterministic fragment generation.  i.e.  You require any 3 pieces to reconstruct the wallet.  You print out 5 such pieces.  Now lets say you decide too much risk is involved in losing a couple of the pieces, so you can print out fragments #6 and #7 and know that they will compliment the other pieces.  Or if one of your fragments is destroyed, you can reprint #2 and know it will be the same as before.

As for peace of mind that the fragments will reconstruct properly... I'm not sure how to do that "right".  I can show the user the result of recombining fragments (as I did in my first post in this thread, showing that I did the calculations and got the same answer, but that's not necessarily comforting to the user.  They won't be satisfied until they manually enter each fragment into a fresh version of Armory that's never seen the wallet, and they get the correct answer.  There's nothign I can really do about that.

This is the right place.  And stop apologizing!  Bug reports are good.  Thank you.

The install location is not the important part, it's the home directory.  It sounds like you're in Linux, so it's looking for /home/<username>/.bitcoin.  This value can be overridden using the "-datadir" arg when running bitcoind/-qt.  If it is different, run Armory with the " --satoshi-datadir=/path/to/new/home" option.

The other thing it needs is the correct port:  Armory expects to find bitcoind/-qt responding on port 8333.  If you changed that, you need to run Armory with the " --satoshi-port=X" option.

If that doesn't help, can you please email or PM me the end of your log file?  You should be able to export it from Armory in offline mode.

That means that Armory is not finding the entire blockchain.  My guess is that the first blkfile (128 MB) stores 101,000 blocks.  Armory believes that's the only file you have on your system.  Can you please post the listing of your .bitcoin directory (or C:\Users\username\AppData\Roaming\Bitcoin)?  Inside that directory is a "blocks" subdirectory (if you are using 0.8).  If that directory is there, can you post that too?

Finally, can you send me the logfile?   You can export it from Armory (File menu), or copy it from .armory/armorylog.txt.  Feel free to browse it for any sensitive information to calm your nerves, but it never includes any security-relevent information (but it may contain evidence that you own certain addresses).