Documentation browser
Feather now has an offline documentation browser. It is accessible by pressing the 'Help' button in the wizard or by going to Help → Documentation.
Enter a keyword in the search bar to filter the list of articles and highlight matches.
If you spot an error or can't find what you're looking for, consider opening an issue on the feather-docs repo.
Improved error messages
In some cases error messages provide too little information to be helpful or too much and it becomes confusing. I recently came across this post, which highlighted this issue and prompted me to make a change.
Most error messages bubble up from the wallet library. It doesn't shy away from using internal terminology and often includes unnecessary information, like references to the source code. That's useful for developers, but not so much for users trying to understand what went wrong and what to do about it.
To address this, many error messages were rewritten for clarity and made more actionable. They should now adhere to a format that aims to answer the following questions:
- What action went wrong?
- Why did it go wrong?
- [What can I do about it?]
- [Where can I learn more?]
For instance, trying to send a transaction when the wallet has not yet finished synchronizing now shows:
Pressing 'Help' opens the docs browser with more information about wallet synchronization to help a curious user understand why the wallet must be synchronized in order to send a transaction.
Writing good documentation for every case is very much a work in progress. If you see a confusing error message, consider reporting it.
Seed recovery
A seed recovery tool was added that can help recover damaged or partial Polyseeds.
Occasionally, I get an e-mail from someone trying to restore a wallet from a backup seed, but they can't make out what some of the words are. Bad handwriting, a coffee stain, a picture that was badly cropped, etc. Too much information is missing to make it practical to go through by hand, but not enough to make recovery computationally infeasible.
The tool allows you to enter all information you do have about the seed phrase. Regex is supported for partial words. It will then iterate over all possible phrases given the (whole, partial or blank) words provided. Polyseeds include a 11-bit checksum, so only a subset of seed phrases are valid. An address associated with the wallet can optionally be provided to automatically check if any of the valid phrases produce a wallet that contains the address.
For information on how to access and use the tool, see the docs here.
Time machine bump
Feather releases are bootstrappable. This means that the tools used to build Feather are built from source, and the tools that build those tools are too, and the tools that build those tools are too, and so forth.
But surely, this can't go on forever and something can't come from nothing. At the root of the package graph sits a binary seed, a minimal set of binaries that can't be built from source. This used to be the ~60 MB Further Reduced Binary Seed.
With this release, our Guix time-machine was updated to a commit on May 15. Feather builds now benefit from the Full-Source Bootstrap. The root of the package graph is now a heavily annotated 357-byte program, known as hex0.
It's source code all the way down! Every step of the build process is auditable and we do not have to trust someone's potentially malicious binaries.
One important caveat is that while all packages are built from source, the driver that is used to build the initial packages is not. Eliminating this driver is the next step in bootstrappable builds.
(Work is underway to bring bootstrappable builds to the core Monero repo.)
Release attestation
Feather releases are reproducible. Anyone with a x64 Linux machine and Guix (the package manager) installed can create a bit-for-bit identical copy of all release artefacts by running a single command.
The only way to verify that a release is in fact reproducible is to build it multiple times, on different systems. While builds are done inside a container with a normalized build environment, non-determinism can still creep in from (among other things) properties of the build machine, like the kernel, CPU architecture or the bind-mounted filesystem. The more diverse the set of machines the software is built on, the more confident we can be that there are no undocumented requirements for reproduction.
This release adds release attestation, sometimes called verified reproduction. If you're familiar with Monero's reproducible build process, this works the same way as gitian.sigs. Anyone can build Feather, sign the hashes of the outputs and submit it to a common repository. The hashes can then be compared to verify that the builds are reproducible.
With release attestation, users that don't build from source can be more confident that releases are reproducible because multiple contributors will have independently produced identical binaries. Should non-determinism occur, it can be fixed before a release.
A special thanks to /u/MoneroArbo for helping verify reproduction of this release. Their first build (for 2.5.0) revealed an undocumented assumption about the host's umask, which leaks into the container and can introduce non-determinism when newly created files are archived.
If you would like to help verify this release, follow the instructions here to build Feather and create an attestation. We recommend using a machine with at least 8 cores and 32 GB of memory, though this is not a requirement.
Official Flatpak release
Feather now has an official Flatpak.
A lot of effort has gone into making sure that it has the same build security guarantees as our other releases. The Flatpak is bootstrappable and reproducible. It has no dependency on any third-party runtime and does not require trust in Flathub's infrastructure.
The repository is hosted on featherwallet.org and all commits are signed with our release signing key, allowing users to verify the authenticity.
It's also tiny compared to most Flatpaks, weighing in at only ~30 MB (compressed). That's the (empty) runtime + application. It only includes files that are necessary for the application to run, not even a shell or coreutils.
For more information about the considerations that went into this, see my post here.
To install the official Flatpak, simply run:
flatpak install --from https://featherwallet.org
and follow the instructions here to verify your download.
Bugfixes and improvements
- Feather now starts exactly one second faster
- Receive: added an option to show change addresses
- Wizard: automatically select the first wallet, if it exists
- Ledger: private viewkey is now available in Wallet -> Keys
- Node username/password are no longer forgotten upon restart
- Mining: allow adding additional command line options
- All files can now be selecting when importing (un)signed transactions
- Windows installer will now abort if it runs on an unsupported version of the OS
- Fixed an issue that could cause the History tab not to update on an incoming transaction
- Send: clear donate description if address was changed
- Fixed an issue that could lead to a crash
- Fixed a build issue on musl platforms
- Some cosmetic improvements for macOS
Other changes
Many (statically linked) dependencies were updated in this release. Including Monero to v0.18.3.1, Qt to 6.6.0, OpenSSL to 3.1.3, Boost to 1.83.0, and Tor to 0.4.7.15.
In anticipation of animated QR codes for offline transaction signing, the ZBar library, used for QR code scanning, was replaced with the faster and actively maintained ZXing-cpp library.
Our type2 AppImage runtime was updated to the latest version and now uses fuse3.
This does not resolve an issue with AppImageLauncher, which throws an error when trying to install the AppImage. Users are recommended to uninstall AppImageLauncher or remove the .AppImageextension from the file.
This release drops support for Qt 5, which has been EOL since May 26 and no longer receives public security updates. The minimum required Qt version to build Feather is now 6.3. Official releases already switched to Qt 6 in January.
Two documents were added to the repo:
- RELEASE.md describes the release process.
- MAINTENANCE.md outlines maintenance priorities and development goals.
Check out the last document if you're interested in learning more about where the project is headed.
macOS codesigning requirements
It is becoming increasingly difficult to ship non-codesigned applications for macOS.
Apps for Apple Silicon that target macOS 10.15 or later will not start if downloaded over the internet, even if they are ad-hoc codesigned which is what Feather does now.
A workaround involves removing an xattr using the terminal, but this is not something we can reasonably ask from non-technical users.
It is unfortunately not possible to obtain an Apple-issued Developer ID certificate without jeopardising my identity, which is not something I feel comfortable doing at this time.
If you are able to obtain an Apple-issued codesigning certificate and are willing to grant me access to it, please contact [email protected]. Any expenses and time incurred will be compensated in XMR.
Note: while current releases are not "codesigned" according to Apple's definition, all releases are GPG signed with our release signing key. To verify the authenticity of a release, follow the instructions in the installation guide.
Downloads: https://featherwallet.org/download/
Full changelog: https://github.com/feather-wallet/feather/compare/2.4.9...2.5.2
