Armory 0.96.3 fragment ID during test backup does not match

[prelude4]

The fragment ID does not match my paper backup during backup testing, however, it does resolved into the right wallet ID.
Would be nice to have the same fragment ID as my paper backup during backup testing as it currently confuses people.

I guess this is due to the new randomized SSS implementation?
Keep up the good work Armory team.

[1715688708]

1715688708

[1715688708]

1715688708

[1715688708]

1715688708

[1715688708]

1715688708

[goatpig]

From the changelog: https://github.com/goatpig/BitcoinArmory/blob/master/changelog.txt#L17

   - Fragment sets are now generated randomly, therefor an unique ID has been added to each set to identify them. You cannot mix
     and match sets.

The IDs are different because the fragments are different. You cannot mix and match fragments from within different sets. The randomized ID is by design, so that users don't end up mixing them.

[prelude4]

Understand. but when testing the backup or restoring a wallet from paper backup, the program prompts user to verify the fragment ID which do not match what was printed on the paper. It's a GUI issue i suppose. The wallet works perfectly after restoration. It's not a problem for veteran users but i think it will confuse new users.

[goatpig]

Understand. but when testing the backup or restoring a wallet from paper backup, the program prompts user to verify the fragment ID which do not match what was printed on the paper. It's a GUI issue i suppose. The wallet works perfectly after restoration. It's not a problem for veteran users but i think it will confuse new users.

You mean it tells you to check the fragment ID vs wallet ID? I thought I got rid of that stuff ugh. Can you pinpoint where that happens?

[prelude4]

if you restore from a fragmented paper wallet backup, you will enter the keys into the program, it will then ask you to verify the fragment ID is the same as the one on your paper. You won't miss it. And the fragment ID will always be different from the paper backup because now the fragment IDs are always random.

[goatpig]

if you restore from a fragmented paper wallet backup, you will enter the keys into the program, it will then ask you to verify the fragment ID is the same as the one on your paper. You won't miss it. And the fragment ID will always be different from the paper backup because now the fragment IDs are always random.

Hmm there may be some misconceptions here. Fragments have always carried 2 IDs: the wallet ID, and the fragment ID. The new fragment ID is random instead of derived from the secret, but there always was these 2 IDs on the paper fragments to begin with. Are you saying the fragment ID from old backups is off now?

When restoring fragments, the code presents you with the fragment ID to check against your fragments at first. Once enough fragments are provided and the secret is reconstructed, it then asks you to compare the resulting wallet ID with the wallet ID on the fragments, which they also carry. This is a 2 step verification that should make sense on its own.

Let me know if you there are specifics in the GUI that you believe are off.

[prelude4]

https://imgur.com/a/VlexU here's the screenshot of where I found the bug. In the Verify Fragment ID windows. the fragment ID displayed will never match my Fragment ID on my paper backup. However, if I click "yes", it will resolved to the correct wallet ID. I don't know how else can i explain it better. You have to go thru the restoration of the fragmented wallet backup to see what I discovered.

[goatpig]

The "Fragment:" field is not the wallet ID field. Are they mismatching in you restore attempt? Are you testing this with a pre or post fix backup?

[prelude4]

I am pretty certain I'm not mismatching Fragment vs Wallet ID.  The Fragment field do not match my Fragment ID in my paper backup nor the Wallet ID in my paper backup. I generated the fragmented backup and test it both with 0.96.3

[goatpig]

Will look at it.

[nsnbtc]

I can also confirm the same!

I have created 3 new wallets, with 0.96.3, using a 3 of 5 fragment printout.   Upon entry no fragment results in a fragment ID, which matches the printouts.


Ubuntu Package: armory_0.96.3-gcc5.4_amd64.deb

[smiles]

I am also having the same issue, none of the fragments when tested return the correct ID.

Edit: However, the fragments still seem to restore the correct wallet, even though the fragment IDs do not match. Maybe a bug in how the fragment IDs are generated?

[goatpig]

I've got it fixed, will be part of 0.96.4

[MrMik]

Good this thread exists, because this this bug can certainly throw a spanner in the works.
It does not inspire much confidence in a new user, when the 'Test your backup' feature is supposed to give peace of mind!
Will the bug still occur when a later version of Armory is used to restore a paper backup that has the bug when used with version 0.96.3 ?
Should I make a new backup when 0.96.4 is released?
Thanks for working on this!

[PhoenixFire]

Good this thread exists, because this this bug can certainly throw a spanner in the works.
It does not inspire much confidence in a new user, when the 'Test your backup' feature is supposed to give peace of mind!
Will the bug still occur when a later version of Armory is used to restore a paper backup that has the bug when used with version 0.96.3 ?
Should I make a new backup when 0.96.4 is released?
Thanks for working on this!

I think the fix made it into the release candidate builds. If possible, please try those. From what I'm reading, testing the backup should succeed with those builds.
Unsure about creating a new backup.

[MrMik]

I think the fix made it into the release candidate builds. If possible, please try those. From what I'm reading, testing the backup should succeed with those builds.
Unsure about creating a new backup.

Thank you for the reply, much appreciated.

I took me a while to figure out that RC stands for 'release candidate'. Shows how green I am...
I think I better stay away from testing because I am too new to this. It's confusing enough as it is!

How come the Armory 0.96.3 version is not linked to at https://www.bitcoinarmory.com/ ?
Is 0.96.3 also a beta version of sorts?

Should I (as a total beginner) just install Armory 0.96.0 and forget about fragmented paper backups until https://www.bitcoinarmory.com/ lists the next version?

[PhoenixFire]

Thank you for the reply, much appreciated.

I took me a while to figure out that RC stands for 'release candidate'. Shows how green I am...
I think I better stay away from testing because I am too new to this. It's confusing enough as it is!

How come the Armory 0.96.3 version is not linked to at https://www.bitcoinarmory.com/ ?
Is 0.96.3 also a beta version of sorts?

Should I (as a total beginner) just install Armory 0.96.0 and forget about fragmented paper backups until https://www.bitcoinarmory.com/ lists the next version?

Honestly, haven't had any problems with RC3 - it largely contains fixes for problems in previous builds - I don't know when 0.96.4 will be released proper.
bitcoinarmory.com is the old site and apparently will only post major point releases. http://www.btcarmory.com is the new one. 0.96.3 is not a beta and definitely don't use 0.96.0.