Topic: Moving ALL OFFLINE from bitcoin-qt wallet.dat to Armory Offline HD, w/ multi-sig (Read 1111 times)

Paranoia is good, but it's important to focus that paranoia in the right direction.

First priority is to make a secure offline Armory wallet. You seem to have the right ideas for protecting yourself from an array of threats.

The next priority is to focus on protecting your new offline Armory wallet from yourself. You should think about how you want to fragment your paper backup. For my savings I use a 3-of-6 paper backup with a secure print code hand written on each page. If my printer has been hacked, the attackers will realize it's no use to them. I store the fragments in a combination of hiding places, and with family members. I protect my offline wallet with a long passphrase and the laptop is stored in a safe with a key. It's quite possible that I will forget the passphrase someday, or lose the key to my safe. However, that's OK, the chance that I will ever lose access to 4 out of 6 of my paper backup fragments has an engineering approximation of 0.

Focus on testing the new Armory wallet before you commit your bitcoin savings to it. Practice restoring the wallet from your backup fragments. Make sure that you can read your hand written secure print code. Practice receiving and sending small amounts of bitcoin with your offline wallet.

It's really important to make sure you can send transactions from your offline wallet. This requires a functional online Armory instance. This is the most common barrier between new users and their bitcoins. Many new users send bitcoins to their offline wallet before verifying that the entire blockchain has been loaded and scanned on their online Armory instance. Don't be that guy.

Remember that YOU are the biggest threat to your bitcoin savings.

Once you feel confident in your ability to secure and access your new Armory wallet, go ahead transfer your bitcoin savings to it. I recommend that you simply send a transaction for the entire balance from you bitcoin-qt wallet to your new Armory wallet. If you are in the process of emptying your bitcoin-qt wallet, there's no need to be so careful with it.

Do not over complicate sending bitcoins to your new wallet.

Import and Sweep have very specific use cases and yours is not it.  There are very few legitimate use cases for those two features. Unless you know for sure that you need to Import or Sweep an address, you don't. For example:

Use Import if you have a vanity address that you want to keep.

Use Sweep if you have bitcoins protected with a random private key on a piece of paper.

Good luck and enjoy sleeping at night.

I'd also like to add that if you import a private key, you have to have a separate backup for it... It won't be present on your regular Armory backup. Hope you're aware of that. That's why I don't recommend importing anything...

That temp wallet is still an HD wallet, there is not way to make a wallet that is not HD in armory. You have just imported all of your keys into it, and all of the addresses that were generated from the HD are still there. So any change will be sent to an address that is part of the HD keys in that wallet.

The best and fastest way to migrate is to setup Armory offline and send your coins there. If you want to respect (1) you just have to create the raw transaction offline on Bitcoin Core and then broadcast them on an online computer.

When you "sweep", you are importing the private key + sending the funds elsewhere. When you "import", you are just importing the keys to your wallet software.

You are over complicating things with your approach, in my opinion. I like to keep my online -> offline/cold storage interactions as simple as possible (the simpler, the less mistakes you make).

As for CD's vs USB's, yes, CD's are safer. You can search around this sub-forum, this issues has been discussed quite a lot recently

Dependencies: Armory's offline packages already have them.

Hi -

Sorry this message got kinda long, but I have lots of questions about tiny details, and I don't want to screw up my security! I tried to split everything up into numbered items to make it clearer.

What is the best way to migrate from bitcoin-qt to Armory Offline, while satisfying the following 3 Requirements:

(1) never put the old wallet.dat from bitcoin-qt into an "online" machine (i.e., don't use the old wallet.dat file with bitcoin-qt online, and don't use it with Armory Online)

(2) the final destination of the coins must be a HD (hierarchical deterministic) wallet

(But if it is necessary to do an an "extra" transaction to move the coins through a "temp" wallet which might be non-HD, then that would not be a problem.)

(3) use multi-sig

---

I have read several explanations of the difference between "sweep" or "import":

https://bitcointalk.org/index.php?topic=966137.0;wap2

https://bitcointa.lk/threads/sweep-vs-import.190631/

But I'm very paranoid and I want to make sure I really understand the difference between the two, and how they apply to this particular use case (especially requirement (1) above - to avoid putting the old wallet.dat into an online machine).

---

How about the following approach, would this be good?

(1) CREATE a new wallet W-NON-HD-TEMP-IMPORT in Armory on the Armory Offline machine, and IMPORT (don't SWEEP) the private keys into this new wallet.

This can be done entirely offline, right? No need to run bitcoin-qt online, and no need to use Armory Online - just do everything on the Offline Machine:

  (a) Export the private keys from wallet.dat, using the command-line interface of bitcoind

  (b) Import the private keys to wallet W-NON-HD-TEMP-IMPORT in Armory Offline - on this same permanently offline machine.

From what I understand, this might be equivalent to what a "sweep" actually does - but I don't mind doing it like this myself (and in fact, I suspect that doing it like this myself may be necessary in order to satisfy my requirement (1) above: never put the old wallet.dat from bitcoin-qt into an "online" machine).

Note: We will be using W-NON-HD-TEMP-IMPORT only as a "temporary" (non-HD) wallet - from which to send the coins using offline-signed transactions to the "permanent" wallets (which will be HD), to be created in the next step.

CONCERN: I'm still concerned about "change addresses" that might be generated during these "sends" from the temp non-HD wallet.

Maybe I need an 2nd "temp" wallet which is HD? So I would go in the following sequence:

  wallet.dat  =>  W-NON-HD-TEMP-IMPORT  =>  W-HD-TEMP-IMPORT  =>  HD wallets

where each "send" from the non-HD temp wallet W-NON-HD-TEMP-IMPORT to the HD temp-wallet W-HD-TEMP-IMPORT would use all the coins from the source address in the non-HD temp wallet?

This would serve two purposes:

(a) Get all the coins out of a non-HD wallet, into a HD wallet

(b) while using up all the coins from each source address during each send - so there would be no need to generate any "change" addresses during the "sends" from the non-HD wallet.

Of course, using a 2nd HD temp wallet like this may be overkill - if we assume that I'm only going to need the non-HD temp wallet for a few hours or a day, while I'm totally emptying it into the HD wallets W-HD-FINAL-1, W-HD-FINAL-2, W-HD-FINAL-3 etc. Even a non-HD wallet is able to generate change addresses, correct? It's just that for a non-HD wallet, these change addresses can't all be determined in advance based on a 72-letter code, correct?

(2) CREATE some new, empty wallets W-HD-FINAL-1, W-HD-FINAL-2, W-HD-FINAL-3 etc. on the Armory Offline machine. These will be HD wallets! So you can back them up to paper now.

(3) On the Armory Offline machine, create some transactions which send coins:

 - FROM wallet W-NON-HD-TEMP-IMPORT (the temporary, non-HD wallet into which the keys from the old wallet.dat from bitcoin-qt were imported without touching an online machine during that process),

 - TO the new, empty wallets W-HD-FINAL-1, W-HD-FINAL-2, W-HD-FINAL-3 (which are HD)

(4) Sign these transactions on the Offline Machine, copy the signed transactions from the offline machine to removable media, put the removable media into the online machine, and then broadcast the signed transactions to the network from the ONLINE machine.

---

Aside re Paranoia: If I'm really paranoid, could I use a CD for the removable media, instead of a USB drive?

I sometimes hear of exploits in USB drives, so CDs seem safer, since they seem more "inert".

I don't mind wasting a few cents on a fresh blank CD every time I want to copy a signed transaction from the offline machine to the online machine.

What I want to avoid is plugging the USB drive into the online machine, and then into the offline machine: this seems like a potential physical path to allow a virus to hitch a ride on the USB to copy itself from the online machine to the offline machine.

The only media which have ever been inserted into my offline machine are:

(a) the Debian/Ubuntu install DVD, and

(b) a CD containing:

  - the bitcoind / bitcoin-qt binaries

  - the Armory *.deb file

  - plus a bunch of other *.deb files for Armory's dependencies for my particular versions of Debian/Ubuntu & Armory

---

Aside re Dependency Hell:

By the way it took me several days to determine exactly the correct set of *.deb files for these dependencies, since most of the documentation out there for this is outdated, and so I went through several days of "dependency hell".

I think I managed to figure out the dependencies by doing:

(i) Install the Armory deb using apt-get

(ii) Check in the directory /var/apt/cache/... to see what debs it downloaded - these are the dependencies, to use to make your own Armory Offline Bundle, compatible with your version of Ubuntu/Debian.

(iii) On the Offline Armory machine, try running dpk -i against these *.deb files, and then try running dpkg -i against the *.deb file for Armory.

(iv) In my case, I still got error messages for two missing *.deb files which were dependencies for Armory, so I got these final missing *.deb files from a Debian/Ubuntu repository online, and added these *.deb files to the set used in (ii) above, and re-ran dpkg -i against these *.deb files, and then against the Armory *.deb, and everything finally worked.

Yeah, I've basically been doing this for several weeks, on my own, repeatedly re-installing Debian/Ubuntu from scratch on my Armory Online and Armory Offline machines, to the point where I think I finally have a deterministic recipe that works, and I've put it all onto a set of DVDs & CDs & USB drive:

1 - Debian/Ubuntu installer DVD

2 - CD with bitcoin core *.tar file, Armory *.deb file, and a bunch of *.deb files for Armory's dependencies - plus the GPG-verified ASC files

3 - a 64-gig USB drive to hold the already-downloaded blockchain (through repeated wipe-cleans and re-installs of the Armory Online machine) to quickly copy onto the freshly installed Armory Online machine

---

(5) After some confirmations, the HD wallets W-HD-FINAL-1, W-HD-FINAL-2, W-HD-FINAL-3 should now have coins in them - and the "temporary" non-HD wallet should be empty. And no private keys were every exposed on an online machine.

To verify that the HD wallets W-HD-FINAL-1, W-HD-FINAL-2, W-HD-FINAL-3 do indeed contain the coins, would I do the following:

(a) Make "watching-only" versions of existing offline wallets W-HD-FINAL-1, W-HD-FINAL-2, W-HD-FINAL-3 (on the offline machine); and then

(b) copy them to the online machine, and there I could confirm that the addresses have the correct number of coins?

--

Final questions:

(1) Is the above approach correct / sensible / optimal?

(2) What about multi-sig?  Does using multi-sig impact the above steps at all?

Thanks for any help!