If you still have funds trapped in Samourai, nostr:npub1r709glp0xx2zvgac45wswufjst5xgr7cear5a8me7x9vazhjzmksp2sf7d wrote some tips on what to do next to recover them here:
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 nostr:npub1wu4aye7ll0lnrrg638e90sehzsgpzx5t39t3mwl05aa0d0ap08esdz3vw0
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?
https://github.com/Coldcard/firmware/blob/master/stm32/repro-build.sh 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 https://coldcard.com/downloads/ yet the script appears to assume the download always to contain "mk".
Where can we find the documentation to reproducibly build the Q1 firmware?
nostr:npub1r709glp0xx2zvgac45wswufjst5xgr7cear5a8me7x9vazhjzmksp2sf7d found something ... https://github.com/Coldcard/firmware/pull/332
So we list the product as unreleased for the time being.
Well, not on nostr. At least that's Fiatjaf's marketing. Did he merge the shadowban nips?
Hi nostr:npub1wu4aye7ll0lnrrg638e90sehzsgpzx5t39t3mwl05aa0d0ap08esdz3vw0
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?
https://github.com/Coldcard/firmware/blob/master/stm32/repro-build.sh 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 https://coldcard.com/downloads/ yet the script appears to assume the download always to contain "mk".
Where can we find the documentation to reproducibly build the Q1 firmware?
Apparently the Coinkite account is not so talkative ...
Pinging nostr:npub1az9xj85cmxv8e9j9y80lvqp97crsqdu2fpu3srwthd99qfu9qsgstam8y8
Hi nostr:npub1wu4aye7ll0lnrrg638e90sehzsgpzx5t39t3mwl05aa0d0ap08esdz3vw0
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?
https://github.com/Coldcard/firmware/blob/master/stm32/repro-build.sh 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 https://coldcard.com/downloads/ yet the script appears to assume the download always to contain "mk".
Where can we find the documentation to reproducibly build the Q1 firmware?
In the end, reproducibility is something, people can attest to in order to extend trust or you have to reproduce it yourself which means you could as well just compile it from source always.
As we care about extending trust, we care about attestation and see jumping pixels more as a gimmick than anything else but if people like it, it's easy enough to record a screen session.
https://walletscrutiny.com/android/com.samourai.wallet/
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": https://walletscrutiny.com/android/de.schildbach.wallet/
For all I know they might escalate this internally but certainly their staff should have protocols for this. After all, people that do lose their money to these apps also do contact them.
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 https://capital.com
Does anybody know how
https://walletscrutiny.com/android/com.kapital.trade.crypto
relates to
https://walletscrutiny.com/android/com.capital.trading
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.
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?
We don't list web wallets so far. Mutiny appears to work for Android but is not on Google Play yet. https://play.google.com/store/search?q=mutiny%20wallet&c=apps
We analyze binaries that we pull from Google Play or the App Store.
?ex=65327bae&is=652006ae&hm=55e8edc5a4ae9bba385f0ed8b48ac66c8f6314ca4790a8a7316bbebdbdec687f&
Join our Space! We will talk about Bitcoin Wallet security!
Among the reproducible Android wallets, Zeus appears to be the first to have switched to Android App Bundles. We tested what we got from Google - the arm64-v8a version and found all bytes accounted for, giving it the verdict "reproducible" but with somewhat of a headache …
Android App Bundle or AAB in short allows Google to provide each user a tailored version of the product. For example in the case of this wallet, the older format contained binaries for arm64-v8a, armeabi-v7a, x86 and x86_64 CPUs. The new format only for "your" CPU.
https://void.cat/d/B44P1WNKFjQqSaYg6VTUng.webp
And that makes the app much smaller. In this case the zeus-universal.apk weighs 92MB while the zeus-arm64-v8a.apk only weighs 32MB.
With games where assets for bigger screens can be excluded for lower end devices, this can make even more of a difference.
But it also implies that Google gets the developer's signing key, theoretically enabling them to also tailor security aspects of your apps - on a case by case basis.
Google is pushing for AAB to trim MBs off all these apps but this comes at a cost:
* Security: Where before, only the developer could sign an update, now Google engineers can, too.
* Transparency: Where before, only one binary was circulating per version, now many circulate.
The full analysis of the latest Zeus wallet can be found here:
Among the reproducible Android wallets, Zeus appears to be the first to have switched to Android App Bundles. We tested what we got from Google - the arm64-v8a version and found all bytes accounted for, giving it the verdict "reproducible" but with somewhat of a headache …
Android App Bundle or AAB in short allows Google to provide each user a tailored version of the product. For example in the case of this wallet, the older format contained binaries for arm64-v8a, armeabi-v7a, x86 and x86_64 CPUs. The new format only for "your" CPU.
https://void.cat/d/B44P1WNKFjQqSaYg6VTUng.webp
And that makes the app much smaller. In this case the zeus-universal.apk weighs 92MB while the zeus-arm64-v8a.apk only weighs 32MB.
With games where assets for bigger screens can be excluded for lower end devices, this can make even more of a difference.
But it also implies that Google gets the developer's signing key, theoretically enabling them to also tailor security aspects of your apps - on a case by case basis.
Google is pushing for AAB to trim MBs off all these apps but this comes at a cost:
* Security: Where before, only the developer could sign an update, now Google engineers can, too.
* Transparency: Where before, only one binary was circulating per version, now many circulate.
The full analysis of the latest Zeus wallet can be found here: