We have long been working on testing desktop wallets but it's really tricky as there is just so many binaries floating around for what claims to be the same product. Even Bitcoin Core is showing 8 download options depending on your operating system or distribution channel preference: image With snapcraft obviously being tricky: image Either way, for desktop wallets, most of the time people have download links and want to verify those downloads, so Chris is working on a binary checker. It's still only a draft merge request and clearly needs a design but what it will enable is actually pretty cool: WalletScrutiny calculates the hash of the file dropped onto it and if it's an apk, it also determines the appId which allows finding the right product. If the hash is known, the verdict is immediately displayed. If not, the page invites the user to upload the file for analysis. The attestations for artifacts will live on nostr as signed events and nostr will also be used to advertise the existance of new binaries for reviewers.
Not all metal backups are made equally. If you use metal to not have to also worry about your bitcoins when your house is on fire, don't use this product: image But running these tests must have been great fun, right @Jameson Lopp? If we add these backup solutions to our website, we would certainly heavily lean on Jameson Lopp's work as a hydrolic press and acids isn't what we had planned to play around with ourselves for now. Jameson are you planning to test more products any soon? Adding "backup tools" to WalletScrutiny might get excessive if we don't draw lines like you did. If it's not at least claiming to be heat resistant, we won't bother to list it or else we end up listing a million different ways to print on paper.
Some fan art โœจ ๐ŸŽถ ๐ŸŽถ Which one do you like best?
Hi @Coinkite (old npup) We were asked to attest to the reproducibility of your Q1 wallet and while the shop looks like it's maybe not released, we think it's just out of stock? May we ask for a release date?
GitHub
firmware/stm32/repro-build.sh at master ยท Coldcard/firmware
โ„๏ธ Firmware and simulator for Coldcard Hardware Wallet - Coldcard/firmware
 appears to not support compiling the firmware for the Q1, right? We found for example 2024-04-02T1416-v1.1.0Q-q1-coldcard.dfu at
COLDCARD - Latest Firmware Downloads
Download the latest firmware for your COLDCARD hardware wallet.
 yet the script appears to assume the download always to contain "mk". Where can we find the documentation to reproducibly build the Q1 firmware?
WalletScrutiny
Samourai Wallet
Review of Samourai Wallet (verdict: sourceavailable)
 Samourai Wallet did not share source code for their latest version on Google Play.
Has anybody noticed that we now have "screen recordings" in our reproducibility tests? As another project is sharing "video proof" of reproducibility, we were asked to also do so but it felt kind of pointless to produce GBs of data for every reproducibility test. We did however start playing around with console recordings that are somewhat more optimized as they record the ASCII on the screen and not every pixel. Resulting files are much more manageable but for example, running the compile script for the Electrum for Android app resulted in 72MB of output. As we test a lot, this is a lot to add in a single day. Does anybody care about screen recordings? Can we throw them at some nostr relay instead of our git repo, with some expiry date in three months, so that interested users can grab it while it's hot? Any other ideas? Currently the tiniest ascii cast is the one for the Schildbach "Bitcoin Wallet":
WalletScrutiny
Bitcoin Wallet
Review of Bitcoin Wallet (verdict: sourceavailable)