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!