Previously we added a " *" suffix to distinguish the selected/main server
in the list. However in case of an .onion address, anything we put as a
suffix inline is elided/truncated - as the address itself does not fit.
Hence we could instead use a prefix - and then why not use an icon.
- show payment options in tabs: URI, Address or Lightning
- use vertical tabs to save space
- switch between QR and text views
- open standalone QR window through menu, instead of clicking on QR code
This commit adds support for the BitBox02 hardware wallet.
It supports both single and multisig for the electrum gui wallet.
To use the plugin a local installation of the BitBox02 python library is
required. It can be found on PiPy under the name 'bitbox02' and can be
installed from the bitbox02-firmware repository in the py/bitbox02
directory.
All communication to and from the BitBox02 is noise encrypted, the keys
required for this are stored in the wallet config file under the
bitbox02 key.
The BitBox02 registers a multisig configuration before allowing
transaction signing. This multisig configuration includes the threshold,
cosigner xpubs, keypath, a variable to indicate for mainnet and testnet,
and a name that the user can choose during configuration registration.
The user is asked to register the multisig configuration either during
address verification or during transaction signing.
The check the xpub of the BitBox02 for other hardware wallets, a button
is added in the wallet info dialog.
The wallet encryption key is fetched in a separate api call, requiring a
slightly tweaked override version of the wallet encryption password.
ran "appimagelint" and apparently icon file needs to be a square
(could have just created another copy, but I guess a square icon
might make sense in other cases too)
see bitcoin/bitcoin@217208a36d
-----
A lot of time was wasted on this... over the years actually...
Some notes and rant here, for future reference.
During the initial effort to try to make binaries reproducible,
out of the three windows binaries being distributed (standalone, portable, setup),
only the first two were successfully made deterministic.
Later, we started to use Docker-based builds. At that point ThomasV and I
could reproducibly build the same setup/nsis exe but Travis kept building a different one.
Recently I have noticed that if I do two subsequent builds of the setup exe on
the same machine, adding a new file in contrib/build-wine/ between the builds,
then I get different binaries. Playing around with this a bit, it seems:
- other files that are in the same folder as contrib/build-wine/electrum.nsi affect the binary
- only files that are in exactly the same folder matter (not recursively)
- only filenames matter (not permission, owner, timestamps, or file contents)
To see the difference in the binaries, use vbindiff, and disable the compression done
by nsis (SetCompress off).
There is a ~48 byte diff near the very beginning of the "Uninstaller" section.
I am only guessing it is the uninstaller section based on the sizes of the sections
printed by nsis during the build.
I have downloaded the binary built by Travis, and the diff is consistent with this
(i.e. it's the same kind of diff that manifests if I change the filename of one of
the supposedly unrelated files).
Commenting out the "WriteUninstaller" line in .nsi fixes the issue. i.e. if no
uninstaller is created then the binary becomes deterministic.
Commenting out the "!define MUI_ICON" line in .nsi also fixes the issue.
At this point I remembered the above referenced commit by bluematt; which I had
thought we had already followed up on...
Replacing the .ico file fixes the issue.
Note that it's not actually clear what the exact requirements for the .ico file are.
Removing any of the layers in the image seems to introduce non-determinicity.
The new .ico file has layers with resolutions and properties the bitcoin.ico file has.
I guess NSIS must have strict requirements for the icon size, and if a given size icon is missing
it might be creating it itself?? And during the downscaling it uses a non-deterministic
algorithm that initialises some RNG from the directory listing (bauerj's guess somewhat adapted :D).
Just crazy.
