Importing Armory paper wallet backup without Armory

[Rampion]

Imagine I create an offline wallet with a Linux LiveCD. I print a paper backup (or save an encrypted copy of the PDF), and I send all my savings to the addresses in that wallet.

In 10 years I need to access my funds. Imagine that Armory was discontinued, I don't have any copy of the old Armory I used to produce the paper backup, and I only have the piece of paper with me. Can I import that wallet to the standard Bitcoin-Qt? Is any way to retrieve the private keys in the Armory wallet using the paper backup, but without using Armory?

[1714912760]

1714912760

[1714912760]

1714912760

[etotheipi]

Imagine I create an offline wallet with a Linux LiveCD. I print a paper backup (or save an encrypted copy of the PDF), and I send all my savings to the addresses in that wallet.

In 10 years I need to access my funds. Imagine that Armory was discontinued, I don't have any copy of the old Armory I used to produce the paper backup, and I only have the piece of paper with me. Can I import that wallet to the standard Bitcoin-Qt? Is any way to retrieve the private keys in the Armory wallet using the paper backup, but without using Armory?

You have to know the algorithm that was used to recreate the keychain from the data on the paper backup.  This has been the same ever since the very first release of Armory, and it's not complicated.  Brainwallet.org has the algorithm implemented in javascript.  Even when I update Armory to the new wallets, it will still have support for the old ones.  I find it difficult to believe that even in 20 years, it would be impossible to find any copy of Armory that ever existed.  Information persistence on the internet is pretty good.

If you are still concerned about it, it you can write down the algorithm yourself.  It will fit in the corner of the piece of paper.  Or you could print off the piece of code, which is a bit more verbose, but will still fit on one piece of paper:

Code:

SecureBinaryData CryptoECDSA::ComputeChainedPrivateKey(
                                 SecureBinaryData const & binPrivKey,
                                 SecureBinaryData const & chainCode,
                                 SecureBinaryData binPubKey)
{

   if( binPubKey.getSize()==0 )
      binPubKey = ComputePublicKey(binPrivKey);

   // Adding extra entropy to chaincode by xor'ing with hash256 of pubkey
   BinaryData chainMod  = binPubKey.getHash256();
   BinaryData chainOrig = chainCode.getRawCopy();
   BinaryData chainXor(32);
     
   // XOR hash of pub key and chain code 
   for(uint8_t i=0; i<8; i++)
   {
      uint8_t offset = 4*i;
      *(uint32_t*)(chainXor.getPtr()+offset) =
                           *(uint32_t*)( chainMod.getPtr()+offset) ^ 
                           *(uint32_t*)(chainOrig.getPtr()+offset);
   }

   // Hard-code the order of the group
   static SecureBinaryData SECP256K1_ORDER_BE = SecureBinaryData().CreateFromHex(
           "fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141");
   
   CryptoPP::Integer chaincode, origPrivExp, ecOrder;
   // A 
   chaincode.Decode(chainXor.getPtr(), chainXor.getSize(), UNSIGNED);
   // B 
   origPrivExp.Decode(binPrivKey.getPtr(), binPrivKey.getSize(), UNSIGNED);
   // C
   ecOrder.Decode(SECP256K1_ORDER_BE.getPtr(), SECP256K1_ORDER_BE.getSize(), UNSIGNED);

   // A*B mod C will get us a new private key exponent
   CryptoPP::Integer newPrivExponent = 
                  a_times_b_mod_c(chaincode, origPrivExp, ecOrder);

   // Convert new private exponent to big-endian binary string 
   SecureBinaryData newPrivData(32);
   newPrivExponent.Encode(newPrivData.getPtr(), newPrivData.getSize(), UNSIGNED);
   return newPrivData;
}

  That function is how to get from one private key n to private key n+1.  The only other thing you need to know is how the "easy-type-base64" alphabet maps to hex:

Code:

NORMALCHARS  = '0123 4567 89ab cdef'
EASY16CHARS  = 'asdf ghjk wert uion'

The mapping was chosen to make slightly obfuscate the data, but also because it's easier to type than raw hex (most people don't touch-type numbers well).

[Rampion]

Imagine I create an offline wallet with a Linux LiveCD. I print a paper backup (or save an encrypted copy of the PDF), and I send all my savings to the addresses in that wallet.

In 10 years I need to access my funds. Imagine that Armory was discontinued, I don't have any copy of the old Armory I used to produce the paper backup, and I only have the piece of paper with me. Can I import that wallet to the standard Bitcoin-Qt? Is any way to retrieve the private keys in the Armory wallet using the paper backup, but without using Armory?

You have to know the algorithm that was used to recreate the keychain from the data on the paper backup.  This has been the same ever since the very first release of Armory, and it's not complicated.  Brainwallet.org has the algorithm implemented in javascript.  Even when I update Armory to the new wallets, it will still have support for the old ones.  I find it difficult to believe that even in 20 years, it would be impossible to find any copy of Armory that ever existed.  Information persistence on the internet is pretty good.

If you are still concerned about it, it you can write down the algorithm yourself.  It will fit in the corner of the piece of paper.  Or you could print off the piece of code, which is a bit more verbose, but will still fit on one piece of paper:

Code:

SecureBinaryData CryptoECDSA::ComputeChainedPrivateKey(
                                 SecureBinaryData const & binPrivKey,
                                 SecureBinaryData const & chainCode,
                                 SecureBinaryData binPubKey)
{

   if( binPubKey.getSize()==0 )
      binPubKey = ComputePublicKey(binPrivKey);

   // Adding extra entropy to chaincode by xor'ing with hash256 of pubkey
   BinaryData chainMod  = binPubKey.getHash256();
   BinaryData chainOrig = chainCode.getRawCopy();
   BinaryData chainXor(32);
     
   // XOR hash of pub key and chain code 
   for(uint8_t i=0; i<8; i++)
   {
      uint8_t offset = 4*i;
      *(uint32_t*)(chainXor.getPtr()+offset) =
                           *(uint32_t*)( chainMod.getPtr()+offset) ^ 
                           *(uint32_t*)(chainOrig.getPtr()+offset);
   }

   // Hard-code the order of the group
   static SecureBinaryData SECP256K1_ORDER_BE = SecureBinaryData().CreateFromHex(
           "fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141");
   
   CryptoPP::Integer chaincode, origPrivExp, ecOrder;
   // A 
   chaincode.Decode(chainXor.getPtr(), chainXor.getSize(), UNSIGNED);
   // B 
   origPrivExp.Decode(binPrivKey.getPtr(), binPrivKey.getSize(), UNSIGNED);
   // C
   ecOrder.Decode(SECP256K1_ORDER_BE.getPtr(), SECP256K1_ORDER_BE.getSize(), UNSIGNED);

   // A*B mod C will get us a new private key exponent
   CryptoPP::Integer newPrivExponent = 
                  a_times_b_mod_c(chaincode, origPrivExp, ecOrder);

   // Convert new private exponent to big-endian binary string 
   SecureBinaryData newPrivData(32);
   newPrivExponent.Encode(newPrivData.getPtr(), newPrivData.getSize(), UNSIGNED);
   return newPrivData;
}

  That function is how to get from one private key n to private key n+1.  The only other thing you need to know is how the "easy-type-base64" alphabet maps to hex:

Code:

NORMALCHARS  = '0123 4567 89ab cdef'
EASY16CHARS  = 'asdf ghjk wert uion'

The mapping was chosen to make slightly obfuscate the data, but also because it's easier to type than raw hex (most people don't touch-type numbers well).

Thanks for your prompt reply. New wallets on the way? Could you point me where I can find some info about these new wallets?

Thanks

[Piper67]

Funny, I was just thinking this morning "what if Armory was discontinued" and came onto the forums to ask exactly this same question.

Would it be possible to guarantee that the wallet can be restored even for someone with absolutely no skills? My main concern, and one of the reasons I chose Armory and the offline wallet option, was to ensure that in the event of my sudden demise, my family would still have access to my wallet. I'll try to keep up with Armory as the years go on, but I'd like to know that even in the worst-case scenario timing-wise, my kids would be able to access them.

As an aside, I love Armory, great concept!

[etotheipi]

Thanks for your prompt reply. New wallets on the way? Could you point me where I can find some info about these new wallets?

The new wallets are based on BIP 32.  This is a standard that was developed with the Bitcoin-Qt core devs, and planned to be adopted by Bitcoin-Qt, Multibit, Electrum, and I'm sure others.  It's a solid "deterministic wallet" algorithm that is secure and extremely flexible.  And soon "standard."  This means that you will have a root key and chaincode that can be plugged into any program and you'll get the same wallet (the programs most likely won't have the same wallet file format, but the addresses will all be derived the same way from the same seed data).

There's a lot of cool things I'm doing with the new wallets, but it'll be some time before I get them done.  And some other priorities popped up.  But the important part is that since it's based on BIP 32, it will be easier to switch to and from Armory without having to create and maintain different wallets.

Would it be possible to guarantee that the wallet can be restored even for someone with absolutely no skills? My main concern, and one of the reasons I chose Armory and the offline wallet option, was to ensure that in the event of my sudden demise, my family would still have access to my wallet. I'll try to keep up with Armory as the years go on, but I'd like to know that even in the worst-case scenario timing-wise, my kids would be able to access them.

This really isn't possible.  The algorithm for generating addresses is based on elliptic curve cryptography, which is "complicated" and critical to the security of the scheme.  No matter how you look at it, you're going to need an app that understands the input data and knows how to apply the algorithm (though, for a cryptographer, the algorithm is dead simple).  However, in the event of your demise, if your family finds your paper backup, they will see "Armory" and the logo on it, and only a little bit of googling should lead them to my website.  Once they are there, they will eventually recover your coins.  Also, as mentioned previously, brainwallet.org also generates that address chains for you, though you have to import them into an app (like Armory) in order to use them, so you might as well just get Armory and recover the wallet.  And as mentioned -- even if Armory was discontinued -- if Bitcoins are valuable enough to be worth recovering, any prior version of Armory will be sufficient for recovering the coins.

On that note, maybe I will add a screenshot of a paper backup to the front page, so in an event like you are talking about, the person who shows up at the website will immediately see they're at the right place.  

[Piper67]

Thanks for your prompt reply. New wallets on the way? Could you point me where I can find some info about these new wallets?

The new wallets are based on BIP 32.  This is a standard that was developed with the Bitcoin-Qt core devs, and planned to be adopted by Bitcoin-Qt, Multibit, Electrum, and I'm sure others.  It's a solid "deterministic wallet" algorithm that is secure and extremely flexible.  And soon "standard."  This means that you will have a root key and chaincode that can be plugged into any program and you'll get the same wallet (the programs most likely won't have the same wallet file format, but the addresses will all be derived the same way from the same seed data).

There's a lot of cool things I'm doing with the new wallets, but it'll be some time before I get them done.  And some other priorities popped up.  But the important part is that since it's based on BIP 32, it will be easier to switch to and from Armory without having to create and maintain different wallets.

Would it be possible to guarantee that the wallet can be restored even for someone with absolutely no skills? My main concern, and one of the reasons I chose Armory and the offline wallet option, was to ensure that in the event of my sudden demise, my family would still have access to my wallet. I'll try to keep up with Armory as the years go on, but I'd like to know that even in the worst-case scenario timing-wise, my kids would be able to access them.

This really isn't possible.  The algorithm for generating addresses is based on elliptic curve cryptography, which is "complicated" and critical to the security of the scheme.  No matter how you look at it, you're going to need an app that understands the input data and knows how to apply the algorithms.  However, in the event of your demise, if your family finds your paper backup, they will see "Armory" and the logo on it, and only a little bit of googling should lead them to my website.  Once they are there, they will eventually recover your coins.  Also, as mentioned previously, brainwallet.org also generates that address chains for you, though you have to import them into an app (like Armory) in order to use them, so you might as well just get Armory and recover the wallet.  And as mentioned -- even if Armory was discontinued -- if Bitcoins are valuable enough to be worth recovering, any prior version of Armory will be sufficient for recovering the coins.

On that note, maybe I will add a screenshot of a paper backup to the front page, so in an event like you are talking about, the person who shows up at the website will immediately see they're at the right place. 

That would be a fantastic idea. In fact, why not a simple dedicated page with clear instructions, and a link that reads something along the lines of: Have you found this kind of paper wallet? Click here to learn how to recover the bitcoins from it.

[bitbutter]

I'm reassured by this thread. Thanks for providing the code sample, that's great as a 'last resort' for recovering paper wallets.

However, in the event of your demise, if your family finds your paper backup, they will see "Armory" and the logo on it, and only a little bit of googling should lead them to my website.

Is the continued availability of the Armory website likely in the event of _your_ demise?

[deadweasel]

I'm reassured by this thread. Thanks for providing the code sample, that's great as a 'last resort' for recovering paper wallets.

However, in the event of your demise, if your family finds your paper backup, they will see "Armory" and the logo on it, and only a little bit of googling should lead them to my website.

Is the continued availability of the Armory website likely in the event of _your_ demise?

Good Question.

[TierNolan]

Is the continued availability of the Armory website likely in the event of _your_ demise?

One way to solve that would be to include a description of how to derive the keys on the paper wallet itself.

In the worst case scenario, you could take it to an ECC expert.

However, once the standard deterministic wallet is created, then all bitcoin client sites would have to be offline.

[redd]

Just wanted to to simulate the way etotheipi posted. I need a paper backup which lasts decades.

Only little more than half a year later etotheipi's instructions are almost useless (if I assume i printed this forum thread). The chaincode is history and so is the function ComputeChainedPrivateKey.

I'm very concerned that my paper backup is useless in the long term and nobody can then reconstruct the private keys from it.

Edit: Useless, if I printed a "Root Key only"-Paper Backup and this thread.

[etotheipi]

Just wanted to to simulate the way etotheipi posted. I need a paper backup which lasts decades.

Only little more than half a year later etotheipi's instructions are almost useless (if I assume i printed this forum thread). The chaincode is history and so is the function ComputeChainedPrivateKey.

I'm very concerned that my paper backup is useless in the long term and nobody can then reconstruct the private keys from it.

Edit: Useless, if I printed a "Root Key only"-Paper Backup and this thread.

Armory wallets still use a root key and chaincode, it's just that the new wallets simply hash the root key to get the chaincode, meaning they don't need to be backed up anymore (it turned out to be unnecessary to randomly select the chaincode). 

Again, the code for this is dead simple, and will easily persist for decades on the internet, github, googlecode, amazon S3, and random users' download folders, as long as Bitcoins still have value.  Anything that would somehow lead to this information becoming inaccessible would probably be accompanied by bigger problems that destroy bitcoin anyway (like nuclear war, collapse of the entire internet, etc).  It's just not going to happen.