image Most people don't dig that deeply but when they do, they have this question. Computers are 1s and 0s. They are digital. How can they be non-deterministic?? Software development mostly revolves around performance both in the end product and the development process. Only very few developers even spend a thought on reproducibility. So if they compile something and it compiles 5 seconds faster, they can test the feature they were working on 5 seconds quicker. These two reasons result in stuff being non-reproducible as: Files are processed in the order they come and that order depends on many factors. For example some file systems sort by date and others by file name. Compilers can optimize the result, so compiling something with one version of the compiler will often give a different result than when compiled with another version. The compiler might process multiple files in parallel and pack them into the result as they finish compiling. Other sources of problems are timestamps or file paths that end up in the result. Some tools on purpose use randomnes to generate IDs that are unique to every build. Of the above issues, all result in non-reproducibility by our standards. While some lead us to comment on the build looking benign as the diff is only some random number appearing twice, others might also be benign but result in differences far too big to quickly judge with the tools we are using. The more developers care about reproducibility over only performance, the better it will get but there are some widely used tools that consistently cause issues and maybe should just be avoided in wallets.
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? 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 yet the script appears to assume the download always to contain "mk". Where can we find the documentation to reproducibly build the Q1 firmware?
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":
It can be really frustrating to hunt after fake apps when not even the provider of the original seams to care ... Here is our attempt at reporting a fraud at View quoted note โ†’
Does anybody know how relates to The former has 500k users but looks like a fake app given the "typo" in the app ID and given that capitalCom links to the latter, only.
Sadly Mycelium hasn't published any source code updates since June, yet their latest release on Google Play was days ago. As of now, Mycelium for Android has to be considered closed source. We poked Alexander Pavlenko - the author of the last commit and probably maintainer - on Telegram yesterday but did not get a reply yet.
image
Good news eveyone! Spiral renewed the grant. We have high goals for this year with more community engagement and expansion to Desktop products.
We'll do another Twitter space tomorrow with Mo and Leo. Should we do a Nest next? image https://twitter.com/i/spaces/1PlKQDWmwNyxE?s=20