Dettmer commit-history analysis of the entropy bug
btcpp-dettmer-commit-history
https://insider.btcpp.dev/p/when-randombytes-runs-but-doesnt
- Organisation
- bitcoin++ Insider Edition
- Evidence role
- Independent primary analysis
- Published
- 2026-08-01
- Source changes
- 1
- Detected differences
- 1
- Unreviewed
- 0
- Copies held
- 2
Dustin Dettmer's walkthrough of the COLDCARD firmware commit history tracing how the predictable generator path was introduced. Published on the bitcoin++ Insider Edition substack; its commit-level claims are checkable against the pinned repository clones held by this archive.
Every check is recorded, including checks that found no text change. A detected edit is therefore bounded between two checks. The publisher's exact save time is not observable from this record. Last checked 2 Aug 2026, 01:00 UTC.
Snapshot and diff bodies for this chain monitor are held in the local evidence archive but withheld from the public site because they can contain victim addresses. Integrity hashes, capture times and reviewed change summaries remain available below.
-
A reader comment from Frank Corva was added to the post's discussion, posted after the preceding capture rather than progressively rendered from it. Substack like and restack counters changed in the same capture. The guest post's own text was unchanged.
Recovered from the Internet Archive rather than captured by this project. The row records that third-party provenance separately from captures made by this project.
What changed from the previous capture 9 lines
What a commit message tells us about the recent COLDCARD bug Dusty Daemon Aug 01, 2026 +8 +1 1 Share This is a guest post from noted Core-Lightning developer, ddustin, who dug into the Coldcard firmware commit history to uncover what happened and why the code failed. I hope that we, as an industry, can learn from this and lean on each other to ship secure code, as a community of developers. Thanks for reading bitcoin++'s Insider Edition! Click below to share this post with your GC Share +8 +1 1 Share A guest post by Subscribe to Dusty Discussion about this post CommentsRestacks +Frank Corva +34m +Great piece. Thank you, Rusty and Nifty. +Reply +Share TopLatestDiscussions No posts Ready for more?Extracted text as captured
SubscribeSign in OpEd When random.bytes() runs but doesn't work What a commit message tells us about the recent COLDCARD bug Dusty Daemon Aug 01, 2026 8 1 1 Share This is a guest post from noted Core-Lightning developer, ddustin, who dug into the Coldcard firmware commit history to uncover what happened and why the code failed. Intro I began investigating the Coldcard hack and was immediately shocked. I need to explain why. When we developers work on code, we organize or code changes into changesets we call “commits.” The purpose of doing so is to show a clear history of what code was changed including why and how. This is done precisely for instances like this where it appears Bitcoiner’s funds are being stolen en masse, so we can investigate and understand exactly how it could happen. Good developers write clear commit messages, written notes that go along with the code changes that explain what the specific change is accomplishing. To make a clear commit message, you typically want to the commit to represent a smaller change of code, so there’s less to comment on. A good goal as a developer is a high commit message to change ratio. The more lines of code that you change, the more comments explaining why you’re changing the code. More message and less code changes per commit is generally a good idea. Here is an example chosen randomly from some of my own work. The commit message is 235 characters, and the commit changes 15 lines of code. That’s a ratio of 235/15 = ~16. In the cold card, the commit that introduced the low entropy bug is here. The commit message is 5 characters and is simply the word “runs.” The commit changes 1534 lines of code making the ratio 5/1534 = ~0.003 This is an atrociously bad comment to code change ratio. There are some rare instances where a low comment ratio is justifiable -- but changing the most important part of the code is not one of those cases! Code that touches functions critical to the security of the project need to have a higher ratio of comments to changes and more stringent review. The second commit contributing to the weak entropy issue on Coldcards is here. The commit message is 1 character: simply the character “x.” The commit changes ~1000 lines of code making the ratio 1/1000 = ~0.001 The Issue In the commit titled “runs” (ratio: ~0.003), it appears they are importing and configuring C code to make custom micropython code work on the STM32, the board that all Coldcards run on. STM32 is the most common CPU for small devices like this, and configurations like what this commit introduces are common. In the ‘runs’ commit, the hardware RNG (Random Number Generation) was disabled with the following line of code. #define MICROPY_HW_ENABLE_RNG (0) This is what caused the bug. Setting this value to zero tells the default micropython rng code to not use the hardware RNG device and that it should use the Yasmarang RNG instead. The developer added an inline comment “explaining” this change // We have our own version of this code. The COLDCARD version of this code appears to be in reference to the functions added in rng.h and rng.c rng.h MP_DECLARE_CONST_FUN_OBJ_0(pyb_rng_get_obj); MP_DECLARE_CONST_FUN_OBJ_1(pyb_rng_get_bytes_obj); These appear to be an attempt to override the stm32 rng library’s `pyb_rng_getobj` function. This approach ran into trouble. The stm32 rng.c file already defines the pyb_rng_et_obj variable and sets the value to `pyb_mg_get`. You can’t have two definitions of the same variable and have it compile.Excerpt only. The complete copy is held offline and backs quotations on this site. The original publication remains the canonical public source.
-
Recovered from the Internet Archive rather than captured by this project. The row records that third-party provenance separately from captures made by this project.
What changed from the previous capture 0 lines
Extracted text as captured
SubscribeSign in OpEd When random.bytes() runs but doesn't work What a commit message tells us about the recent COLDCARD bug Dusty Daemon Aug 01, 2026 1 Share This is a guest post from noted Core-Lightning developer, ddustin, who dug into the Coldcard firmware commit history to uncover what happened and why the code failed. Intro I began investigating the Coldcard hack and was immediately shocked. I need to explain why. When we developers work on code, we organize or code changes into changesets we call “commits.” The purpose of doing so is to show a clear history of what code was changed including why and how. This is done precisely for instances like this where it appears Bitcoiner’s funds are being stolen en masse, so we can investigate and understand exactly how it could happen. Good developers write clear commit messages, written notes that go along with the code changes that explain what the specific change is accomplishing. To make a clear commit message, you typically want to the commit to represent a smaller change of code, so there’s less to comment on. A good goal as a developer is a high commit message to change ratio. The more lines of code that you change, the more comments explaining why you’re changing the code. More message and less code changes per commit is generally a good idea. Here is an example chosen randomly from some of my own work. The commit message is 235 characters, and the commit changes 15 lines of code. That’s a ratio of 235/15 = ~16. In the cold card, the commit that introduced the low entropy bug is here. The commit message is 5 characters and is simply the word “runs.” The commit changes 1534 lines of code making the ratio 5/1534 = ~0.003 This is an atrociously bad comment to code change ratio. There are some rare instances where a low comment ratio is justifiable -- but changing the most important part of the code is not one of those cases! Code that touches functions critical to the security of the project need to have a higher ratio of comments to changes and more stringent review. The second commit contributing to the weak entropy issue on Coldcards is here. The commit message is 1 character: simply the character “x.” The commit changes ~1000 lines of code making the ratio 1/1000 = ~0.001 The Issue In the commit titled “runs” (ratio: ~0.003), it appears they are importing and configuring C code to make custom micropython code work on the STM32, the board that all Coldcards run on. STM32 is the most common CPU for small devices like this, and configurations like what this commit introduces are common. In the ‘runs’ commit, the hardware RNG (Random Number Generation) was disabled with the following line of code. #define MICROPY_HW_ENABLE_RNG (0) This is what caused the bug. Setting this value to zero tells the default micropython rng code to not use the hardware RNG device and that it should use the Yasmarang RNG instead. The developer added an inline comment “explaining” this change // We have our own version of this code. The COLDCARD version of this code appears to be in reference to the functions added in rng.h and rng.c rng.h MP_DECLARE_CONST_FUN_OBJ_0(pyb_rng_get_obj); MP_DECLARE_CONST_FUN_OBJ_1(pyb_rng_get_bytes_obj); These appear to be an attempt to override the stm32 rng library’s `pyb_rng_getobj` function. This approach ran into trouble. The stm32 rng.c file already defines the pyb_rng_et_obj variable and sets the value to `pyb_mg_get`. You can’t have two definitions of the same variable and have it compile. rng.c MP_DEFINE_CONST_FUN_OBJ_0(pyb_rng_get_obj, pyb_rng_get);Excerpt only. The complete copy is held offline and backs quotations on this site. The original publication remains the canonical public source.
Each copy above is identified by the SHA-256 of its extracted text, shown beside it, and the diffs are plain unified diffs. To verify a quotation, compare it against the page itself or against the Internet Archive's copies, which are independent of this project.
Complete captures are held offline rather than mirrored here, so this page shows diffs and excerpts. If a quotation is ever disputed, the full copy can be produced. Ask.
The SHA-256 prefixes above identify each held copy without turning this page into a mirror of somebody else's post. Compare a quotation against the original. If the post has since been edited or deleted, ask and the held copy can be produced.