BIP110 is heading towards "mandatory signalling" around August 7th with so far 3‰ miner support. How should we deal with this? Bitcoin isn't a democracy. My node, my rules. To say "miners decide" misses how bitcoin works. So ... at what point should we warn users about transactions executing on two blockchains? Bip110 users will see "0 confirmations" on their transactions long after they confirmed on the Core side. But do Core users also need a warning? When and how? Clearly if bip110 would get close to 20% mining support, things would get dicey but now ...

View quoted note → We will also ask for those juicy tokens although our repo is abysmally starred. We use GitLab after all ... If you want to support us, star our GitHub mirror anyway, please!

GitHub

GitHub - WalletScrutiny/WalletScrutinyCom: Mirror of https://gitlab.com/walletscrutiny/walletScrutinyCom

Mirror of https://gitlab.com/walletscrutiny/walletScrutinyCom - WalletScrutiny/WalletScrutinyCom

We’ve been busy but quiet these last months. @btc_remnant improved the site a lot by adding new features around #nostr based build verifications. We hope other projects in the nostr ecosystem like @franzap @Zapstore will see the value of these verifications and start integrating them. The more products that build on reproducibility, the more users can truly apply the principle of “Don’t trust - verify.” Binary transparency shouldn’t remain a niche feature - it needs to become the default. If you run software that touches your private keys - be it nostr clients or bitcoin wallets - without binary transparency, only whoever built the binary really knows what code you’re running. @dannybuntu and @keraliss checked the reproducibility of almost 300 binaries. The 304 verifications by @WalletScrutiny Bot are all the old verifications we had migrated to nostr. And the backlog keeps growing as we cover more and more products with frequent updates. Are we doing something valuable for the space? A @Spiral grant says yes, and community endorsements confirm it - but the project itself also needs scrutiny. We recently introduced "verification endorsements": This is a simple contribution many could provide. If you read a verification and it looked plausible and complete and you trust the author, mark the verification as verified. If you ran the documented commands yourself on your hardware and got to similar results, please endorse the verification! Even more importantly label verifications as invalid and leave a comment about what's missing when you find issues! Don't be shy! Our goal is to document all steps such that all mildly technical users (you should be comfortable with a Linux shell) can reproduce our findings. If that's not the case, please provide your feedback and we will improve ✋. And if you maintain one of the products we check, share your own verification as a template for others!