Paper backup test not working.... [resolved]

[opentoe]

I made a paper backup of my wallet and did the built in test and it kept failing. I must have typed out the root key letters a million times and it does not pass. It comes up with a completely different wallet. There really is only one way to type in all the letters. Just go across the page. In the first field type in the sets of letters, all nine of them and do the same into the second field. I've tried many times and it just keeps failing. Is this a known bug or something? I'm very glad I didn't dispose of any of my digital backups.

Also, is the Armory *.wallet file that Armory uses when running, is that encrypted at all itself? If not then anyone can just copy that file and import it, right? Is there a way to encrypt that file while Armory is running?

[etotheipi]

Well this is why there's a test-backup feature.  We've never seen an example of it not working, it's usually a problem with the way it's typed in.  Have you selected the proper backup version?  Did you enter the SecurePrint code?  (does your backup have one?)

Unfortunately, without seeing the paper backup, there's only so much we can do to figure out what's wrong (I'm not encouraging you to send me the backup, btw, I just don't know how much I can do for you).

If you did not use SecurePrint, you can go to make a backup, and under the "More Backup Options" go to "Export Key Lists."  In this window it will display the non-SecurePrint paper backup root (and chaincode, but if your backup is 1.35c, you can ignore the chaincode if displayed).  This should match what you have on the sheet of paper -- but only if the backup does not user SecurePrint.  I don't know if there's any way to show the SecurePrint version.

Also, if an Armory wallet file is encrypted, it will only ever write the encrypted data to disk.  The decryption happens in RAM only and immediately zeroed out as soon as the data is no longer needed.  The only way to end up with unencrypted data on disk is if you explicitly remove the encryption through wallet properties.

[opentoe]

Well this is why there's a test-backup feature.  We've never seen an example of it not working, it's usually a problem with the way it's typed in.  Have you selected the proper backup version?  Did you enter the SecurePrint code?  (does your backup have one?)

Unfortunately, without seeing the paper backup, there's only so much we can do to figure out what's wrong (I'm not encouraging you to send me the backup, btw, I just don't know how much I can do for you).

If you did not use SecurePrint, you can go to make a backup, and under the "More Backup Options" go to "Export Key Lists."  In this window it will display the non-SecurePrint paper backup root (and chaincode, but if your backup is 1.35c, you can ignore the chaincode if displayed).  This should match what you have on the sheet of paper -- but only if the backup does not user SecurePrint.  I don't know if there's any way to show the SecurePrint version.

Also, if an Armory wallet file is encrypted, it will only ever write the encrypted data to disk.  The decryption happens in RAM only and immediately zeroed out as soon as the data is no longer needed.  The only way to end up with unencrypted data on disk is if you explicitly remove the encryption through wallet properties.

I will mark this as resolved. The test paper backup defaulted on version 1.35C, and I had to manually select 1.35A. What does this mean? Is my wallet an older version or something? Does it need to be updated? I was under the impression that it defaulted to the correct version I was using. So paper test is %100.

[etotheipi]

I will mark this as resolved. The test paper backup defaulted on version 1.35C, and I had to manually select 1.35A. What does this mean? Is my wallet an older version or something? Does it need to be updated? I was under the impression that it defaulted to the correct version I was using. So paper test is %100.

The wallet files are identical for all backup types -- it's the version of the backup not the wallet.  In version 0.90-beta, we were able to reduce backup size in half without breaking backwards compatibility (because the saved .wallet is indistinguishable).  Hence why they are all "1.35", just with another letter.  But we can't tell what version it is without seeing the wallet's private keys: hence why you have to select it yourself.  Absolutely nothing to be concerned about

The next version will use checkboxes instead of a dropdown box, which will make it more obvious that it may be required.