I put an offline wallet on my netbook.. a watching only on my desktop and

[notig]

I printed out 2 paper backups. Should I put ALL my coins that I am saving on this with essentially 3 backups?
Should I do more backups? Is it possible to backup to a usb stick as well?

(when I rescue a wallet and it has all that data... is the passphrase involved at all? is the passphrase somehow stored in the data as well? What if the passphrase is lost? Just curious.

[Anon136]

i cant see any reason not to. Just dont put all your backups in the same house, incase it burns down.

[etotheipi]

I printed out 2 paper backups. Should I put ALL my coins that I am saving on this with essentially 3 backups?
Should I do more backups? Is it possible to backup to a usb stick as well?

(when I rescue a wallet and it has all that data... is the passphrase involved at all? is the passphrase somehow stored in the data as well? What if the passphrase is lost? Just curious.

Paper backups are forever!.  Protects you from your hard-drive dying, and forgetting your passphrase.
Digital backups are literal copies of your wallet file, which is encrypted if your wallet is encrypted. Obviously doesn't protect you if you forget your passphrase.  If necessary, you can always write the passphrase on the DVD or USB key that you saved it on.

Don't put all your coins in until you're comfortable.  Put a little bit in.  Try it out.  Get used to the process of sending.  It is hopefully guided well.  Once you do a few such transactions, then you'll decide for yourself whether to put all of them in there.

And as Anon136 said -- it's probably best not to keep all your backups in one place.  In the future, Armory will have split backups that make this a little safer.  Until then, protect them very carefully.  Anyone who gets a paper backup gets your wallet.

[notig]

  Anyone who gets a paper backup gets your wallet.

(but it could be encrypted so still useless if they don't know the passphrase right?

[etotheipi]

  Anyone who gets a paper backup gets your wallet.

(but it could be encrypted so still useless if they don't know the passphrase right?

Paper backups are never encrypted.  You can use them to recover your wallet if your forget your passphrase.  Digital backups are just copies of your wallet, and thus encrypted if your wallet is.

[w1R903]

And as Anon136 said -- it's probably best not to keep all your backups in one place.  In the future, Armory will have split backups that make this a little safer.  Until then, protect them very carefully.  Anyone who gets a paper backup gets your wallet.

Question: there's no relation between the seeds of different wallets, through, correct?  If someone gets the paper backup for one wallet, is the other wallet still safe?

[etotheipi]

And as Anon136 said -- it's probably best not to keep all your backups in one place.  In the future, Armory will have split backups that make this a little safer.  Until then, protect them very carefully.  Anyone who gets a paper backup gets your wallet.

Question: there's no relation between the seeds of different wallets, through, correct?  If someone gets the paper backup for one wallet, is the other wallet still safe?

Correct.  BIP 32 will change that, though it depends what part of a BIP 32 you are backing up.  The new Armory wallet files based on BIP 32 will contain multiple "wallets", each of which is derived from that master seed.  But you'll be able to create multiple wallet files, with different seeds, and back them up separately.

[justusranvier]

Correct.  BIP 32 will change that, though it depends what part of a BIP 32 you are backing up.  The new Armory wallet files based on BIP 32 will contain multiple "wallets", each of which is derived from that master seed.  But you'll be able to create multiple wallet files, with different seeds, and back them up separately.

Doesn't BIP 32 allow for the creating of hierarchies of arbitrary depth?

[etotheipi]

Doesn't BIP 32 allow for the creating of hierarchies of arbitrary depth?

Yes, you create wallet "trees".  Standard users will have a single wallet file that is backed up by the seed once.  Creating new "wallets" will still be covered by the old seed . You can see a graphic of it here. 

Since Armory is multi-wallet, though, I will be expanding it to accommodate multiple wallet files when I get the new wallets implemented (for Expert users, probably Advanced, too).  When such a user makes a new wallet, they'll have the choice of whether to generate one already protected by their existing backup, or generate a new wallet file.

I still need to work out how to deal with the multiple layers, such that you might have a wallet "chain" 2 levels deep, for which you want to import just the public/watching-only part of that chain.  Or the full chain.  I have interface details to work out on that front.  (like, company creates master wallet, and gives each employee their own subwallet/chain.  It could be a full chain or watching-only chain.  The point being that the company can sweep each employee's work-wallet at any time, refill it, or just watch/verify what they're doing.

[justusranvier]

I have interface details to work out on that front.  (like, company creates master wallet, and gives each employee their own subwallet/chain.  It could be a full chain or watching-only chain.  The point being that the company can sweep each employee's work-wallet at any time, refill it, or just watch/verify what they're doing.

Or a company can create sub trees for each location, which get broken down by department, then employee, and maybe even further.

A question I had about BIP 32 that I never saw a conclusive answer to is how much of the total tree can be recreated from the private key of a single node. I hope it means an employee can use his private key to generate the private keys of all descendents from his node, but not those of sibling or ancestor nodes.

[w1R903]

I have interface details to work out on that front.  (like, company creates master wallet, and gives each employee their own subwallet/chain.  It could be a full chain or watching-only chain.  The point being that the company can sweep each employee's work-wallet at any time, refill it, or just watch/verify what they're doing.

Or a company can create sub trees for each location, which get broken down by department, then employee, and maybe even further.

A question I had about BIP 32 that I never saw a conclusive answer to is how much of the total tree can be recreated from the private key of a single node. I hope it means an employee can use his private key to generate the private keys of all descendents from his node, but not those of sibling or ancestor nodes.

I thought that was the idea, too, but reading over the proposal, I'm not 100% sure:

"Somewhat more care must be taken regarding extended keys, as these correspond to an entire (sub)tree of keys. One weakness that may not be immediately obvious, is that knowledge of the extended public key + a private key descending from it is equivalent to knowing the extended private key (i.e., every private and public key). This means that extended public keys must be treated more carefully than regular public keys."

From: https://en.bitcoin.it/wiki/BIP_0032

[etotheipi]

I have interface details to work out on that front.  (like, company creates master wallet, and gives each employee their own subwallet/chain.  It could be a full chain or watching-only chain.  The point being that the company can sweep each employee's work-wallet at any time, refill it, or just watch/verify what they're doing.

Or a company can create sub trees for each location, which get broken down by department, then employee, and maybe even further.

A question I had about BIP 32 that I never saw a conclusive answer to is how much of the total tree can be recreated from the private key of a single node. I hope it means an employee can use his private key to generate the private keys of all descendents from his node, but not those of sibling or ancestor nodes.

I thought that was the idea, too, but reading over the proposal, I'm not 100% sure:

"Somewhat more care must be taken regarding extended keys, as these correspond to an entire (sub)tree of keys. One weakness that may not be immediately obvious, is that knowledge of the extended public key + a private key descending from it is equivalent to knowing the extended private key (i.e., every private and public key). This means that extended public keys must be treated more carefully than regular public keys."

From: https://en.bitcoin.it/wiki/BIP_0032

There's a lot of discussion about this right now.  The nature of the offline/watching-only wallet split, makes it possible to actually go backwards up the tree, only if you have the private extended key for the node, and the public extended key for the parent node.  That's why BIP 32 may be changed.  We are pretty sure we can avoid that.