Dev branch - print backup doesn't work

[Aethereal]

Hello @goatpig
As of the current commit b252ce4 "wallet creation progress report in GUI" the wallet creation seems to work flawlessly
The creation process still throws a warning about "No crontrol passphrase" for the global protection but now the single wallet created is correctly encrypted with the set password. Previously, the wallets were actually created as Not Encrypted.
I can tell because:
a- previously created wallet now are listed as not encrypted and the new ones are listed as encrypted in the Available Wallets grid
b- when asked to make a paper backup during the creation phase, I'm asked again (for a fouth time) the password to unlock it

There are still some minor quirks with the windows management: if you choose to add additional entropy, the wizard window is enlarged to accomodate the card pictures, but once accepted the new entropy the windows is not sized back when asked for the passoword, so the two input fields are occupying just a corner of the still big window. The next step recreates the window so it all turns back to normal.
When not using the additional entropy, there's still the error about being unable to get a screenshot.
When printing the paper backup, the window with the actual paper wallet to be printed is very small, to the point that on one system I tried it neither the picture nor the buttons were visible, and I had to manually resize it to show them.

When creating a new wallet, hitting the "print" button during the "print single sheer paper backup" phase throws an error:

(ERROR) Traceback (most recent call last):
  File "/home/test/Armory/BitcoinArmory/qtdialogs/DlgBackupCenter.py", line 632, in print_
    LOGINFO('Printing!')
    ^^^^^^^
NameError: name 'LOGINFO' is not defined

Since the wallet property window buttons aren't yet working, I couldn't test if the error is specific to the creation flow or is present also on on-demand wallet backup.

Thanks for the update and keep up the good work!

[goatpig]

The creation process still throws a warning about "No crontrol passphrase" for the global protection but now the single wallet created is correctly encrypted with the set password.

Updated the verbose to be more specific about what's happening.

a- previously created wallet now are listed as not encrypted and the new ones are listed as encrypted in the Available Wallets grid

The private keys are encrypted nonetheless. You're running into a GUI quirk. It parses the used address data to determine encryption state and a fresh wallet that never went online has no provable used addresses, so there is nothing to parse, hence the issue on fresh wallets. Get one address from the wallet, reload Armory and it should show as encrypted. I have to use a better heuristic for this...

As for the new wallets you made showing as encrypted, I've had the creation process put the first address in use to avoid the quirk. Again, I have to think of something better.

b- when asked to make a paper backup during the creation phase, I'm asked again (for a fouth time) the password to unlock it

Will fix.

he wizard window is enlarged to accomodate the card pictures

This is really wonky atm, made somehow even worse on Hyprland. Probably something to do with qtpy and/or qt5/6, I'll get to it eventually.

When creating a new wallet, hitting the "print" button during the "print single sheer paper backup" phase throws an error

Ah, I completely ignored that, we'll see what I can do.

Since the wallet property window buttons aren't yet working, I couldn't test if the error is specific to the creation flow or is present also on on-demand wallet backup.

Next commit will add unlock testing, should be within the hour of writing this.

[Aethereal]

b- when asked to make a paper backup during the creation phase, I'm asked again (for a fouth time) the password to unlock it

Will fix.

Actually, that's not really wrong. Assuming at this point the wallet was already created and saved in encrypted form, it's totally legit Armory ask again the password to unlock it if the password was already discarded from memory. I suppose the on-demand "make backup" option will have to ask for the password anyway if done at a later time.

[goatpig]

Actually, that's not really wrong. Assuming at this point the wallet was already created and saved in encrypted form, it's totally legit Armory ask again the password to unlock it if the password was already discarded from memory. I suppose the on-demand "make backup" option will have to ask for the password anyway if done at a later time.

This is a regression. Old armory (python wallets) did not have you submit the password to generate the backup after creation. The password does live in memory for the whole wizard lifetime, just as before, but decryption happens in the cppbridge now.

New Armory unlocks via a callback process: encrypted assets list their encryption key id, the code tries to resolve that. If it finds no key, it prompts the caller for candidates. I can force feed the passphrase by hijacking the prompt, I was just lazy to.

[Aethereal]

Hello
as of commit 9b16dcb "fix backup print feature", the "Backup Wallet" button in the wallet properties window still isn't working with error

Code:

(ERROR) Traceback (most recent call last):
  File "/home/test/Armory/BitcoinArmory/qtdialogs/DlgWalletDetails.py", line 559, in execBackupDlg
    DlgSimpleBackup(self, self.main, self.wlt).exec_()
    ^^^^^^^^^^^^^^^
NameError: name 'DlgSimpleBackup' is not defined

The backup feature inside the new wallet creation wizard is now able to print the paper backup. Though, just after that a dialog "Verify Your Backup!" pops up, and clicking on the button "Test Backup" nothing happens, the dialog closes and you are again at the create backup. You can go "Next" and make a read-only copy, but the wallet is still marked as not backup-ped.
On the console, I have the following error:

Code:

Traceback (most recent call last):
  File "/home/test/Armory/BitcoinArmory/ui/WalletFrames.py", line 1033, in clickedDoIt
    isBackupCreated = OpenPaperBackupDialog('Single', self.parent(), self.main, self.wlt)
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/test/Armory/BitcoinArmory/qtdialogs/DlgRestore.py", line 1542, in OpenPaperBackupDialog
    DlgRestoreSingle(parent, main, True, wlt.uniqueIDB58).exec_()
                                         ^^^^^^^^^^^^^^^
AttributeError: 'PyBtcWallet' object has no attribute 'uniqueIDB58'

I'll wait for further commits to try again

[Aethereal]

Ah, now things become interesting...
as of commit 2449 "fix passphrase reading..." I have different behavior on different systems.

On my RPI5 the wallet creation works fine. The print dialog now comes up, I can print the actual paper backup (currently on pdf for test purposes) and also perform the verify step with success.

On my Garuda (arch-based) I can't get to the OS (Qt actually) print dialog, I get this error:

Code:

Traceback (most recent call last):
File "/home/lab/BitcoinArmory/qtdialogs/DlgBackupCenter.py", line 638, in print_
self.printer.setPageSize(QtGui.QPageSize.PageSizeId.Letter)
~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: arguments did not match any overloaded call:
setPageSize(self, size: QPagedPaintDevice.PageSize): argument 1 has unexpected type 'PageSizeId'
setPageSize(self, pageSize: QPageSize): argument 1 has unexpected type 'PageSizeId'

I tried changing the local KDE setting for paper size to "A4" rather than "Letter", because opening the print dialog in a different program (kate) I noticed there wasn't a setting named just "Letter" but different settings with alternate names, so I though the problem could be this system didn't had a PageSizeId with a Letter property.
This didn't changed the behavior of Armory, that thrown the same exact error, including the "Letter" PageSizeId. I checked and turned out the page size is hardcoded.
I then tried to change the line indicated, using PageSizeId.A4 but I got again the same error.
I suppose it might be something specific of this system and the same won't happen to others, but I'm still curious about what could cause it.

[goatpig]

Are you using different versions of Qt across systems? That's the first thing that comes to mind, qtpy wraps "silently" around anything from pyqt4 to pysides6.

[Aethereal]

Yes, there are indeed different Qt versions

On the working RPI5 there's just Qt5 (default from distribution)
On the arch-based machine there are both Qt5 and Qt6 libraries (qmake reports using Qt 5.15.16)
There were probably some mistake when installing pyside6 that pulled some more libraries than needed. Other programs are still able to call the print dialog though, not sure which of them are doing that using python.
It's anyway a minor issue at the moment since it only happens on this "lab" machine that could have a quite "dirty" environment due to previous experiments.