I vibe coded this standalone python app for checking your seedsigner firmware is converting sample/test dice rolls to seed phrases as it's supposed to. It is purely for testing and should not be used on a final seed phrase. Can also be used on a coldcard if you're still game. Other hardware wallets that take d6 dice rolls use a different algorithm.

A little more than 10 hours to go before our next run for a Rigly block via CK Pool. (Shoutout to: @ckpooldev) The hashrate is stacking to a nice 241 PH! Can't win if you don't play... 🎲🎲🎲 YOLO:

We have some difficult news to share. Unfortunately, one of our shipping providers has experienced a data breach that exposed sensitive order data. This affects new customers in the US, UK, Sweden, Colombia, Brazil, Italy, and Portugal who received an order within the 90 days prior to August 8th, 2026. The data exposed: - Full names - Shipping addresses - Phone numbers - Email addresses The incident affects 11,742 customers with full exposure (name, email, phone number, shipping address) and 1,947 customers with partial exposure (name, city, email). The breach is limited due to Trezor’s strict 90-day data storage policy (we were also able to negotiate the same terms with fulfillment partners, who follow the same policy). All affected customers have been contacted separately by email. Our systems and devices remain secure, but affected customers could experience an increase in phishing attempts. NEVER enter your wallet backup on a website or share it with anyone, and only check for updates on official Trezor channels. We are deeply sorry to the community and those affected. We are investigating this situation and will post updates on our blog:

After a day of dealing with C code in the linux kernel, which is about as hard and subtle a task I could ever deal with, I have a better feel for Grok 4.6's capabilities by comparing it side by side with Claude Opus5. First, 4.6 in Grok Code has a new effort level of extra high, compared to its default and previous max of high. If you're going to do anything serious it's a big step up from high and worth the extra time and tokens. Its reasoning appears to be even better than Opus 5 - I had them argue out potential solutions and Grok more often than not outdid Opus 5. Its code is better than 4.5 was, but still below what I got out of Opus 4.8, missing some subtle detail that Opus would not have. It also does just what you ask it to do in code, and nothing more. Opus 5 on the other hand, if you ask it to write code, it will write the code, then go off and create well thought out test frameworks, and execute them without being asked. Either approach is valid depending on your viewpoint or workflow, but in the end Opus 5 won out for me with its approach for my task. I can certainly see the improvement in Grok, and directionally that it could easily overtake the competition with its rapidly expanding parameter models coming up, but Opus5 won this battle. That said, I have cancelled my Claude account as I mainly got it for the free Fable5 access and for the subtle work I was doing it was better, more concise, and actually faster than Opus5. But I kept tripping safeguards and ran out of credits and it became nigh on useless. So I'm running on remaining credit till my account terminates. The next grok model probably won't be out before my account terminates so I'll probably give in and re-subscribe for another month to fill that gap. Also having two completely different models check each others' reasoning leads to a much better result than either alone, and perhaps I'll need it regardless for that superpower.

Long term I'm betting on Grok getting there. Grok 4.5 was just below opus 4.8, and Grok 4.6 looks better but it's too early to tell (and remains the same number of parameters as 4.5). I expect 5 will be insanely good. That guy has more money than Satoshi to throw at it.

Announcing linux-7.1-ck1. The -ck patchset aims to improve desktop/laptop responsiveness and interactivity mostly by replacing the CPU scheduler en-bloc with my MultiQueue Skiplist Scheduler. It's been 10 long years since the last -ck patchset. I wasn't planning on ever updating it because of the amount of time involved to resync with each new kernel version. However, I'd missed its improvements, and Claude AI has made it a fraction of the workload it used to be. So, here is the first updated patchset which is mostly just a resync of the old patches for the latest linux kernel. The only new changes are MuQSS now uses P/E core aware idle balancing. Only lightly tested and may not build on other configs, so use usual precautions.

Bitcoin Core v32.0 is targeted for release in October: - Up to 3x faster initial sync. Block validation now fetches transaction inputs from disk in parallel instead of one at a time - The libevent external dependency is fully removed, continuing Core's push to cut third-party dependencies - Max peer connections raised from 125 to 200 to have more open slots for new nodes to sync from, faster block propagation, and a harder network to eclipse or partition - Mempool-based fee estimation to cut fee overestimation (in progress) - Transaction relay rate limiting is now global instead of per-peer, keeping a node's CPU and memory usage steady when transaction volume spikes - Ships with features from libsecp256k1 0.8.0 with verification up to 11% faster, plus the new Silent Payments module (BIP 352) - PSBTv2 (BIP 370) support, now the default for PSBT-creating RPCs for better coordination of unsigned transactions for multisig and hardware wallet setups - New exportwatchonlywallet command to export a wallet as a watch-only file, no private keys, and restore it on your online node - Core now enables Tor's proof-of-work DDoS defense on the onion service it creates for your node, where the Tor daemon supports it Additional tests, bugfixes, and features included as well. Feature freeze is ~August 20, rc1 ~September 10, final release targeted for ~October 10. (Test the release candidates when they ship!)

I sometimes get asked how to configure bitcoin core for mining, and whilst you can go mad with custom patches, there are some basic rules anyone can apply. Here are a quick set of basic bitcoin mining node optimisations that come to mind for mining: Use a dedicated node that is only doing mining and no other node tasks - use a separate node on a different machine for other duties. Do not run more than one bitcoind on the same machine. Run your node on fast hardware - CPU architecture and raw clock speed matter MUCH more than total CPUs as there is a lot of serialised code. A high clock speed i5 with few cores is better than a lower clock speed i7 with many cores. Have plenty of ram, ideally 32GB, and set dbcache to 12GB so it can contain the full UTXO set in time. Leave your node running permanently - each time you restart it, it will be very slow and get progressively quicker on subsequent block changes. Don't be afraid to prune a node if your drive is more than half full and it's being used purely for mining. Filesystems inherently slow down once they are more than 70% full, and provided a pruned node remains in sync it offers zero disadvantage in mining. Use an SSD. A pruned node on an SSD is infinitely better than a full node on a spinning drive. Don't increase the number of connections - this will increase mutex contention in the code. Don't connect it via wifi. Use ethernet where possible, and preferably a wired connection to the internet, though starlink is not too bad. Don't enable transaction indexing. This serves no purpose in mining. Do not use blocksonly mode or your node will be slow to confirm and rebuild new blocks. Build your own bitcoind from scratch for your hardware which will enable CPU optimisations specific to it.

Yesterday I began fully integrating the @OpenAI trust cyber program into my Bitcoin Red Team efforts. This morning I woke up to see this. I am now being blocked from doing additional analysis on a codebase which I've already responsibly disclosed to, and have received confirmation had legitimate findings. To be clear, this is after having already KYC'd and completed the onboarding process months ago to use the cyber capabilities OpenAI has to offer. I am now prevented from being able to continue the investigation in a further effort to make sure their code changes are sufficient, as well as understand if there are other issues that have yet to be discovered. It absolutely guts me as a patriotic American to have to do this, but I will be going back to using Chinese open source models to conduct my research to protect Bitcoin infrastructure. Black hats will not hit these issues. The white hats will. We've hit a local minima in policy. Intelligence is unrestricted for those who don't follow rules, and those who engadge in harm reduction are left on the sidelines. What are we doing in this country? How is this keeping people safe? Please do something @DavidSacks @sama @realDonaldTrump

Stratum V2 is now live on all servers after extensive validation and testing - thanks to all who pointed their hashrate to the experimental server. Regular stratum (V1) mining continues unaffected. Restarts also would have caused no discernible downtime to miners. SV2 is accessible on the unified stratum URL on discrete ports: :3336 /9anrRNhBh7869XtNnFcCuGBRZP51E635qGbu457J5kHdszhfRc3 and port 4336 for highdiff mining rentals only. As per stratum V1, you will be directed to the lowest latency pool for your location. Job declaration is supported on port 3337 but I am recommending against using it until further stratum V2 developments make it sensible to use on a solo pool. The sv2solo domain used by testers will keep working as an alias to the stratum domain so you need not reconfigure your miners if they're already connected. Final shout-out and thanks goes to @mineracks for providing hardware and hosting for the AU server, and dealing with my demanding support requests. Mine on!

Update after 3 days of the stratum v2 experimental code. I'm very pleased with the performance of the protocol and plan to make it a permanent feature of solo ckpool. After a few more pool updates to tighten sv2 conformance and performance upgrades for anticipated heavy usage in future, everything is still running smoothly. At this point I'll let it run till next week unchanged, and if no further improvements come to mind and it remains stable I'll deploy it on all the solo pools as dual instance SV1/SV2 endpoints from all locations. This should be a transparent process to miners. Regular stratum mining should remain unaffected, and there should be no discernible downtime to miners.

Update after the first day of experimental stratum v2 support. The sv2 pool is currently sitting around 300TH from 6 users/10 workers (including my own hashrate) and all seems to be working fine. For those configuring SV2 mining, the mining endpoint is: and the job declaration endpoint is What's currently missing is a high diff port for rentals (@Braiins already offer native SV2 rental hashrate) and I will deploy that in the near future. Assuming SV2 is here to stay, these URLs will likely remain and propagate across all the pools. Stratum V1 mining is here to stay indefinitely and will be unaffected - they will both be running from the same ckpool code. The ckpool code itself will eventually be made public once it reaches a stable state. In addition I'm working on extending ckpool in proxy mode aka ckproxy to be a stratum v1 to v2 proxy. This will also follow the public release of ckpool with v2. I'm also aware that some people took my initial post to be very negative regarding stratum v2, but that was not my intent at all - I was trying to describe the compromise nuances on a technical level. So I'll try to clarify: - Native stratum v2 end to end is a positive on all fronts. My benchmarking v1 vs v2 on ckpool specifically shows latency is basically identical. The advantages are security, privacy, and a trivial bandwidth decrease. - Stratum v1 to stratum v2 via a proxy I can now say after benchmarking it has no significant latency increase so can still obtain many of the benefits of Sv2 but is currently not that straight forward to set up. - Stratum v2 with job declaration (mine your own templates/transactions) is a decentralisation aid that comes with a modest latency hit tradeoff. It is significantly more complex to set up than basic v1 to v2 proxying. It should become the defacto standard for regular pooled mining, but _currently_ offers no advantage in lottery aka solo pools. Hopefully highlighting this will help the devs focus their attention to minimise or even abolish the tradeoff in time. On a technical level, I think pools should be allowed to send work in JD mode on an updatedtip and simply allow the client to decide whether to use that work or not until it updates its own tip. It will provide the best of all worlds. Leaving the decision to the client takes away the concern that a pool will override the client's work. Mine on!