Nostr notes by

Not the best picture, but the pork green chile tonight did no ...

2026-10-12T02:10:15Z

Not the best picture, but the pork green chile tonight did no disappoint. Local pork, peppers, and tomatillos. Can’t believe I haven’t made this before.

#foodstr

I’ve been sleeping on jj (jujitsu) for too long. Today I asked ...

2026-09-27T16:49:41Z

I’ve been sleeping on jj (jujitsu) for too long. Today I asked my agents which they would prefer to use if working alone and all of them said jj but making sure it stayed git compatible.

I’m going to ask them to start working this way so I can learn. Excited to see if they are more efficient with my PRs

I try not to post links to X but some of the items in this list ...

2026-09-20T13:23:59Z

In reply to nevent1q…cnyj
_________________________

I try not to post links to X but some of the items in this list show you how powerful it could be. I also tested it briefly for flexible incoming structured data validation and it worked well. Long story short, anywhere you might consider a customer trained classifier to avoid an LLM call is a use-case for Jev.

https://x.com/layton_gott/status/2101450120466174351?s=46

I submitted for the waitlist and was surprised I got an invite ...

2026-09-19T23:52:15Z

In reply to nevent1q…nhhx
_________________________

I submitted for the waitlist and was surprised I got an invite pretty quick. Ran a few tests this morning and it seems like there are going to be a ton of ways to use it. Amazing how cheap it is and the agent was able to wire up quick tests on its own

Have you played with Jev yet at all?

2026-09-19T23:11:26Z

In reply to nevent1q…h0lv
_________________________

Have you played with Jev yet at all?

Despite all the hype this has been getting on X, I actually think ...

2026-09-19T20:41:20Z

Despite all the hype this has been getting on X, I actually think people might not understand how big of a deal it is. They refer to it as a system one model, but I think a better name is a general classifier.

Jev replace specialized machine learning models out of the box in many ways. May of the inefficiencies in current agent workflows like model selection or memory management can be improved. This is going to supercharge the speed and efficiency of agentic workflows and completely shift how AI and data analytics interact.

I pulled it into my agent this morning and had an improved proof of concept data validation workflow for a project I had been working on for years within 10 minutes. All the testing I did this morning over the course of a few hours cost me < 3 cents. Checking a 22k record database for errors (without needing to explicitly define failure criteria) might cost $1.50.

quoting
nevent1q…l4pm
Jev is nuts….. wish I understood more about how it works, but the opportunities this type of model opens up are incredible.

Now, we wait to see how fast someone can reproduce with open-source weights for local use.

Already stuff like this popping up… will test soon if I can. ...

2026-09-19T15:50:41Z

In reply to nevent1q…3ze2
_________________________

Already stuff like this popping up… will test soon if I can. github.com/trycua/cua

It’s gotta be something that could run locally right? The cost ...

2026-09-19T15:45:02Z

In reply to nevent1q…2300
_________________________

It’s gotta be something that could run locally right? The cost is so low. Or is it still a big model just with sparse cheap throughput? This is where I don’t know enough yet…

Jev is nuts….. wish I understood more about how it works, but ...

2026-09-19T15:39:46Z

Jev is nuts….. wish I understood more about how it works, but the opportunities this type of model opens up are incredible.

Now, we wait to see how fast someone can reproduce with open-source weights for local use.

Keeping it healthier tonight… Salmon burger with lemon dill ...

2026-09-13T02:47:23Z

Keeping it healthier tonight… Salmon burger with lemon dill Greek yogurt sauce with chard and cucumbers. Served with squash and green beans.

Can’t compare to a beef burger, but hit the spot and solid macros.

#foodstr

I would argue it’s always safer. A passphrase is either short ...

2026-09-04T05:00:47Z

In reply to nevent1q…qylp
_________________________

I would argue it’s always safer. A passphrase is either short enough to remember and likely easy to brute force OR long and secure and your single point of failure to lose your funds when you can’t reproduce it. Or your trust a password manager, which is maybe okay as long as you have a back up plan for that too.

You should talk to Keith from seed signer about entropy. He has ...

2026-09-04T03:30:12Z

You should talk to Keith from seed signer about entropy. He has been putting in the work including showing why dice rolls aren’t that “risky”

I’m unconvinced anyone should ever use a passphrase - should never be compared to multisig.

The single sig focused hardware marketing budgets will always try to convince you otherwise. I have no regrets in trusting level headed research from open source and DIY devs over corporate marketing.

https://fountain.fm/episode/RZ5nt9RBqnyOL13HAZip

quoting
nevent1q…9v0t

Yellow squash from the garden and jalenpeño cheddar brats from a ...

2026-08-31T03:26:41Z

Yellow squash from the garden and jalenpeño cheddar brats from a local farm picked up at the farmers market. Brats were beer-braised (Mack and Jacks) with onions and topped with apple cider vinegar picked onions and brown mustard. Grilled to finish and served on a brioche bun… I should probably just never cook a brat again so I can stop while I’m ahead 🤤

#foodstr

Not a software dev but I have heard at least 1 engineer say this ...

2026-08-11T12:37:48Z

In reply to nevent1q…xzxc
_________________________

Not a software dev but I have heard at least 1 engineer say this in conversation unprompted by Claude. I supposed it’s possible he started using it more after using Claude, but I doubt it.

May be more common in some spaces (like enterprises) than others

Sunday salmon and steak! Steak was a touch overdone but still ...

2026-08-10T01:37:41Z

Sunday salmon and steak! Steak was a touch overdone but still good. Smoked over cherry and finished in butter, garlic, and rosemary. Chard from the garden stir fried with ginger, garlic, soy sauce, rice wine vinegar, and sesame oil. Chard and summer squash were the first good batch of veggies from the garden! #foodstr

So it seems

2026-08-08T21:46:19Z

In reply to nevent1q…90a9
_________________________

So it seems

Can someone ELI5 what happened here? Was this not set to happen ...

2026-08-08T21:38:14Z

In reply to nevent1q…n0yn
_________________________

Can someone ELI5 what happened here? Was this not set to happen at a specific block height?

Sure thing! It looked like most findings around implementation ...

2026-08-08T17:18:36Z

In reply to nevent1q…3qqf
_________________________

Sure thing! It looked like most findings around implementation were already identified with know fixes as you mention. The things that are new are likely more supply chain improvement and repo hygiene related

@npub1tv8…7wn2 I built a security audit skill for Claude a ...

2026-08-08T16:44:49Z

KeithMukai (npub1tv8…7wn2) I built a security audit skill for Claude a while back that tries to establish a strong security system for software based on the documented claims. I pointed it at seedsigner this morning to see what it would do. It’s relatively opinionated and there are pieces like a CI/CD check for audit on each release that might be overkill, BUT I think it flagged some interesting things. It also drafted a SECURITY.md. Posted it as a draft PR in my fork so I could share.

Key suggestions:
- one instance of a potential string injection
- suggests to pin dependencies to hashes instead of versions to decrease supply chain risk
- establishes a SECURITY.md with clear claims

https://github.com/armstrys/seedsigner/pull/1

Nostr event nevent1qqsx5n9fwr5hqlwp5wjsx2n4qcqm4m83z7ch78w876mdv6tn08hl2sczyryqk5jgl0508y4u8wj9py0mfehzkkrj8pmqr0us75ueydntxrtjq6re9cv

2026-08-07T22:16:42Z

In reply to nevent1q…eerh
_________________________

How ironic is it that ColdCard got bit by a general purpose ...

2026-08-07T22:16:24Z

How ironic is it that ColdCard got bit by a general purpose function in their execution environment after endlessly complaining about the security of using general purpose hardware as a hardware wallet?

Woops!

Also how are we turning a blind eye so fast on open sats… ...

2026-08-07T04:44:33Z

Also how are we turning a blind eye so fast on open sats… sometime you have to hold integrity over money.

I hear rumors of big donations to catching up on the audit backlog - great… but there had better be a lot more resignations or governance changes in the next couple weeks before we accept open sats as a neutral actor.

One spurt of money doesn’t fix a decade of biased decision making.

calle (npub12rv…85vg)

Have been pulled over to x during the coldcard situation. Feed ...

2026-08-07T04:26:23Z

Have been pulled over to x during the coldcard situation. Feed become less useful and more random ass content over time.

How do we convince the bitcoiners still using that shit platform to escape?

What’s your read on the current state for private repos? ...

2026-08-06T02:39:23Z

In reply to nevent1q…f78p
_________________________

What’s your read on the current state for private repos? Supposedly buzz is the best as a self-hosted community yeah? Is the other tooling mostly public repos only?

Just finding out about loupe by spiral - man, the teams at block ...

2026-08-05T00:30:19Z

Just finding out about loupe by spiral - man, the teams at block really deliver.

What timing given the current conversations around CoinKite

💯

2026-08-04T23:44:22Z

In reply to nevent1q…jefz
_________________________

💯

No doubt in the link, but does it really mean anything? Both ...

2026-08-04T23:01:30Z

In reply to nevent1q…dgr2
_________________________

No doubt in the link, but does it really mean anything? Both doc-hex and switck were committing to libngu prior to adoption in coldcard. The nym use is weird, but doc-hex was already linked to the libngu library without the two profiles being the same person. There were also cases in the commit history with other coinkite devs using two user profiles scgbckbone (as avirgovi). There are also cases when doc-hex shows as the committer even when scgbackbone is the author.

I think the nym is a red herring. The whole repo reeks of poor dev practices. No PRs in some cases and even when there were switck merging doc-hex meant there was no independent review. Bonkers.

Peter did like 75% of the commits to coldcard. Pointing out that this all technically falls on him is no surprise. Claiming that it was malicious requires some additional evidence

I know some people don’t like the idea of assisted multisig but ...

2026-08-04T22:42:21Z

In reply to nevent1q…m8l9
_________________________

I know some people don’t like the idea of assisted multisig but this is exactly why I would push people in that direction first. Yes, it costs money, but think of it as training if you ever want to go full self-custody multisig. About the only real negative trade-off is privacy.

Some folks may graduate to full multi-sig, but it definitely adds risk of messing something up with no one to bail you out.

The more I look into this and uncover the git history of the repo ...

2026-08-04T21:19:58Z

The more I look into this and uncover the git history of the repo the more it looks like complete incompetence. The dual identity is the hardest to explain, but otherwise it looks like complete governance failure and poor programming.

quoting
nevent1q…7yw4
Oh shit… from Kimi K3. Smoking gun. Looks like doc-hex was also responsible for the code that added entropy on newer devices, but STILL fell below a reasonable threshold. This is super sketchy.

—————-
# Peter D. Gray and the Coldcard Entropy Incident

## Executive summary

Peter D. Gray, Coinkite engineer (GitHub: `doc-hex`, email: `peter@conalgo.com`), authored the commit that introduced the Coldcard entropy vulnerability and later authored the inadequate mitigation. On March 1, 2021, Gray pushed commit `b18723dd` directly to Coldcard's firmware master branch: a 120-file, 5,488-line change that replaced the hardware TRNG seed generation path with a call through the `libngu` library, which silently resolved to a non-cryptographic software PRNG called Yasmarang. The commit had no pull request, no code review, no CI pipeline, and no GPG signature despite Gray possessing a valid signing key. The same commit deleted the GPLv3 license and replaced it with MIT plus the Commons Clause.

Gray was not a passive consumer of libngu. He was an active contributor with 19 commits to the library starting February 10, 2021, 19 days before the integration commit. The library's primary author, `switck`, had no independent GPG key and signed their own commits using Gray's GPG key (`A2DCD558C2BE5D7C`), verified by raw PGP signature packet inspection. The two were collaborators: Gray was pushing to switck's firmware fork by January 2021, and Coinkite maintained their own fork of switck's library.

Thirteen months after introducing the vulnerability, Gray authored PR #18 to libngu (March 11, 2022): a 32-bit reseed function that brought newer devices (Mk4, Q, Mk5) from ~40 bits of effective entropy to ~72 bits. The design target was 128 bits. The person who introduced the vulnerability also wrote the fix that left users still below the security threshold.

The bug survived five years until July 30, 2026, when an attacker drained approximately 1,367 BTC ($88.6 million) from 4,500+ addresses. The attacker never touched a single device.

---

## Gray's relationship with libngu and switck

### The GPG key

Gray registered a GPG key on his GitHub account:

| Property | Value | Source |
|---|---|---|
| Primary key ID | `A2DCD558C2BE5D7C` | [GitHub API: users/doc-hex/gpg_keys](https://api.github.com/users/doc-hex/gpg_keys) |
| Subkey ID | `F0E6CC6AFC16CF7B` | [GitHub API: users/doc-hex/gpg_keys](https://api.github.com/users/doc-hex/gpg_keys) |
| Created | July 17, 2018 | GitHub API |
| Expired | May 28, 2023 | GitHub API |

switck has no GPG key registered on GitHub ([API returns empty](https://api.github.com/users/switck/gpg_keys)), no SSH keys ([API returns empty](https://api.github.com/users/switck/keys)), and uses only GitHub's noreply email. Location listed as "Cyberspace."

Despite switck having no registered key, switck's commits to libngu are GPG-signed. GitHub marks them `verified=False, reason=unknown_key` because the signing key is not registered to switck's account. Raw inspection of the PGP signature packets reveals the key ID:

- switck commit `f7711c5522` (2024-03-30): raw PGP packet contains `A2DCD558C2BE5D7C`. This is Gray's primary key.
- doc-hex commit `61ffc74af1` (2022-03-11): raw PGP packet contains `F0E6CC6AFC16CF7B`. This is Gray's subkey.

Both key IDs belong to the same GPG key registered to doc-hex. switck does not have their own GPG key. switck is signing commits with Peter Gray's key.

### The collaboration timeline

| Date | Event | Evidence |
|---|---|---|
| 2020-08-07 | switck creates GitHub account | [GitHub API: users/switck](https://api.github.com/users/switck) |
| 2020-10-15 | switck creates libngu repo, forks Coldcard/firmware, forks micropython | [GitHub API: repos/switck/libngu](https://api.github.com/repos/switck/libngu) |
| 2021-01-08 | Gray commits appear in switck's firmware fork (release signing, bug fixes) | [GitHub API: repos/switck/firmware/commits](https://api.github.com/repos/switck/firmware/commits) — commits by "Peter D. Gray" |
| 2021-02-10 | Coinkite forks switck's libngu. Gray makes first commit to libngu same day. | [GitHub API: repos/coinkite/libngu](https://api.github.com/repos/coinkite/libngu) (created 2021-02-10), [GitHub API: libngu commits by doc-hex](https://api.github.com/repos/switck/libngu/commits?author=doc-hex) |
| 2021-02-10 to 02-26 | Gray makes multiple commits to libngu (AES clone, env var tweaks, bip39 bugfix) | [GitHub API: libngu commits by doc-hex](https://api.github.com/repos/switck/libngu/commits?author=doc-hex) |

Gray had 19 total commits to libngu. He knew the library he was integrating.

### The `peter-conalgo` identity

The parent commit's `.gitmodules` referenced `github.com/peter-conalgo/trezor-crypto.git` as the `external/crypto` submodule. The GitHub account `peter-conalgo` was created April 22, 2021. The account name is "peter," no other identity. Gray's email is `peter@conalgo.com`. The commit removed this submodule (Gray's personal trezor-crypto fork) and replaced it with switck's libngu.

Sources: [GitHub API: users/peter-conalgo](https://api.github.com/users/peter-conalgo), [parent commit .gitmodules](https://raw.githubusercontent.com/Coldcard/firmware/f456a88/.gitmodules)

---

## The fateful commit: `b18723dd`

**Repository:** `github.com/Coldcard/firmware`
**SHA:** `b18723dd`
**Author:** Peter D. Gray (`peter@conalgo.com`)
**Date:** March 1, 2021, 14:03:03 UTC
**Message:** "First pass w/ libNgU"
**Parent:** `f456a88` (single parent: direct push, not a merge commit)
**Files changed:** 120
**Lines:** +2,766 / -2,722
**Pull request:** None
**Code review:** None
**CI:** None (no `.github` directory in repo)
**GPG signature:** Unsigned, despite Gray having a valid key (created 2018, valid through May 2023)

Sources: [GitHub API: commits/b18723dd](https://api.github.com/repos/Coldcard/firmware/commits/b18723dd), [GitHub commit page](https://github.com/Coldcard/firmware/commit/b18723dd), [GitHub API: contents/.github](https://api.github.com/repos/Coldcard/firmware/contents/.github) (Not Found)

### What Gray changed

| File | Change | Significance |
|---|---|---|
| `shared/random.py` | Changed `from ckcc import rng` to `import ngu`; set `bytes = ngu.random.bytes`. Comment still says "crypto-quality rng." | Call path that resolved to Yasmarang instead of the hardware TRNG |
| `shared/seed.py` | Changed `make_new_wallet()` from `rng_bytes(seed)` to `random.bytes(32)`. Changed `import tcc` to `import ngu` throughout. Changed `tcc.sha256(seed)` to `ngu.hash.sha256s(seed)`. | Seed generation function. Old path reached STM32 hardware TRNG. New path reached Yasmarang. |
| `shared/drv_entro.py` | Changed `import stash, tcc, hmac, chains` to `import stash, ngu, chains` | BIP-85 entropy derivation path migrated |
| `COPYING` | Deleted (674 lines, GPLv3) | Removed GPLv3 license |
| `COPYING-CC` | Added (MIT + Commons Clause) | Replaced GPLv3 with source-available license restricting commercial use |
| `.gitmodules` | Removed `external/crypto` (`peter-conalgo/trezor-crypto`), removed `external/modcryptocurrency`, added `external/libngu` (`switck/libngu`) | Removed Gray's personal trezor-crypto fork, added switck's libngu |

Sources: [GitHub API file diffs from commit b18723dd](https://api.github.com/repos/Coldcard/firmware/commits/b18723dd)

### The specific seed generation change

Before (firmware v3.2.2):
```python
seed = bytearray(32)
rng_bytes(seed) # reaches ckcc.rng_bytes -> STM32 hardware TRNG
```

After (commit b18723dd, shipped in v4.0.0):
```python
seed = random.bytes(32) # reaches ngu.random.bytes -> libngu -> rng_get() -> Yasmarang
```

Source: [Block Engineering analysis](https://engineering.block.xyz/blog/predictable-rng-fallback-and-32-bit-reseed-in-coldcard-firmware), section 5

### How the bug worked

The bug required two pieces: a faulty preprocessor check in libngu (switck's code) and Gray's seed generation change that routed through it (Gray's code).

**libngu's faulty check** (switck's code):
```c
#ifndef MICROPY_HW_ENABLE_RNG
#error "get a HW TRNG plz"
#endif
```
`#ifndef` tests whether the macro exists, not whether it is enabled. Coldcard's board config defines `MICROPY_HW_ENABLE_RNG` as `0`. The macro exists. Its value is zero. The check passes. The build links Yasmarang.

**Coldcard's board config** (Gray's code):
```c
#define MICROPY_HW_ENABLE_RNG (0)
```
Coinkite disabled MicroPython's built-in RNG because they provide their own wrapper. But Gray's seed generation change called `ngu.random.bytes` instead of `ckcc.rng_bytes`, routing through the broken libngu path.

Yasmarang was seeded from the MCU's 96-bit unique device identifier (factory metadata, not a secret), the SysTick counter (~80,000 possible values on Mk2/Mk3), and RTC registers (correlated timing values). None are cryptographic entropy sources. Collected once. Never reseeded.

Effective entropy: ~40 bits on Mk2/Mk3 (design target: 128 bits). A 40-bit keyspace is searchable on commodity hardware.

Sources: [Block Engineering analysis](https://engineering.block.xyz/blog/predictable-rng-fallback-and-32-bit-reseed-in-coldcard-firmware), sections 1-4

---

## The reseed commit: PR #18

Thirteen months after introducing the vulnerability, Gray authored a mitigation.

**Repository:** `github.com/switck/libngu`
**PR:** #18
**Title:** "Add reseed function to ngu.random module"
**Author:** doc-hex (Peter D. Gray)
**Submitted from:** `coinkite/libngu` fork
**Opened:** March 11, 2022
**Merged by:** switck on March 15, 2022

Source: [GitHub API: repos/switck/libngu/pulls/18](https://api.github.com/repos/switck/libngu/pulls/18)

### What the reseed did

```python
a = callgate.read_rng(1) # 32 bytes from SE1
b = callgate.read_rng(2) # 8 bytes from SE2
n = ngu.hash.sha256d(a + b)
n, = ustruct.unpack('I', n[0:4]) # keeps only 4 bytes
ngu.random.reseed(n) # replaces one 32-bit state word
```

The reseed hashes 40 bytes of secure-element output with SHA256d, then truncates to 4 bytes. It replaces one 32-bit Yasmarang state word. Maximum 2^32 distinct reseed values.

### Why the reseed was inadequate

| Property | Value |
|---|---|
| Secure element output | 40 bytes |
| Bytes retained after SHA256d | 4 (ustruct unpack 'I') |
| Maximum distinct reseed values | 2^32 |
| Effective entropy after reseed (Mk4/Q/Mk5) | ~72 bits |
| Design target | 128 bits |
| Gap | 56 bits below target |

The reseed function itself is trivial: `yasmarang_pad = mp_obj_get_int_truncated(arg)`. It does not initialize a cryptographic DRBG. It does not reset other state words. It does not provide periodic reseeding or prediction resistance.

The secure element firmware that provides the reseed entropy is closed source. `shared/callgate.py` is a thin wrapper around `ckcc.gate()` calls. The 72-bit figure rests on trust in a closed system that cannot be independently audited from outside the chip.

Source: [Block Engineering analysis](https://engineering.block.xyz/blog/predictable-rng-fallback-and-32-bit-reseed-in-coldcard-firmware), section 6

### The same key signed both commits

Gray's commits to libngu, including the reseed PR, are signed with his subkey `F0E6CC6AFC16CF7B`, verified by raw PGP packet inspection. switck's commits are signed with Gray's primary key `A2DCD558C2BE5D7C`. The same GPG key is used across both identities.

The fateful firmware commit `b18723dd` was the one commit Gray did not sign.

---

## The test failures

### What the test suite looked like at the time of the commit

| Issue | Evidence | Source |
|---|---|---|
| Test RNG deliberately seeded | `conftest.py` line 13: `random.seed(42)` | [GitHub: testing/conftest.py](https://github.com/Coldcard/firmware/blob/b18723dd/testing/conftest.py) |
| Only assertion on seed generation | `shared/seed.py`: `assert len(set(seed)) > 4` with comment `# TRNG failure` | GitHub API file diff |
| Entropy test tests derivation, not generation | `testing/test_drv_entro.py` tests BIP-85 derivation from a hardcoded XPRV | [GitHub: testing/test_drv_entro.py](https://github.com/Coldcard/firmware/blob/b18723dd/testing/test_drv_entro.py) |
| No end-to-end path test | No test generates a seed with known entropy input and verifies output | Full test directory inspection (18 test files) |
| No CI/CD | No `.github` directory | [GitHub API: contents/.github](https://api.github.com/repos/Coldcard/firmware/contents/.github) (Not Found) |

The test suite assumed the RNG worked. It never verified it. A seed with 40 bits of real entropy still expands into well-distributed, unique-looking addresses. No statistical test run against the output can distinguish "unpredictable" from "deterministic but unexamined."

The hardware TRNG code existed in every affected binary. It was reviewed. It was intact. It was never called from the seed generation path. Block Engineering's analysis: "reviews did not verify end-to-end symbol resolution and call reachability." Presence was mistaken for function.

Sources: [Block Engineering analysis](https://engineering.block.xyz/blog/predictable-rng-fallback-and-32-bit-reseed-in-coldcard-firmware), [808bits analysis](https://808bits.com/articles/coldcard-entropy-failure-lessons/)

---

## Timeline of Gray's involvement

| Date | Action | Evidence |
|---|---|---|
| 2018-07-17 | Gray creates GPG key `A2DCD558C2BE5D7C` | [GitHub API: users/doc-hex/gpg_keys](https://api.github.com/users/doc-hex/gpg_keys) |
| 2021-01-08 | Gray commits appear in switck's firmware fork | [GitHub API: repos/switck/firmware/commits](https://api.github.com/repos/switck/firmware/commits) |
| 2021-02-10 | Coinkite forks switck's libngu. Gray makes first commit to libngu. | [GitHub API: repos/coinkite/libngu](https://api.github.com/repos/coinkite/libngu), [GitHub API: libngu commits by doc-hex](https://api.github.com/repos/switck/libngu/commits?author=doc-hex) |
| 2021-02-10 to 02-26 | Gray makes multiple commits to libngu | [GitHub API: libngu commits by doc-hex](https://api.github.com/repos/switck/libngu/commits?author=doc-hex) |
| **2021-03-01** | **Gray pushes `b18723dd` to Coldcard/firmware master. No PR, no review, no CI, no GPG signature. Changes seed generation to route through libngu (Yasmarang). Deletes GPLv3, replaces with MIT + Commons Clause.** | [GitHub API: commits/b18723dd](https://api.github.com/repos/Coldcard/firmware/commits/b18723dd) |
| 2021-03-02 to 03-09 | Gray continues committing to libngu | [GitHub API: libngu commits by doc-hex](https://api.github.com/repos/switck/libngu/commits?author=doc-hex) |
| 2021-03-17 | Firmware v4.0.0 ships containing the vulnerability | [Block Engineering analysis](https://engineering.block.xyz/blog/predictable-rng-fallback-and-32-bit-reseed-in-coldcard-firmware), section 5 |
| 2022-01-12 | Gray opens PR #17 to libngu (hardware accelerated SHA256) from `coinkite/libngu` | [GitHub API: repos/switck/libngu/pulls/17](https://api.github.com/repos/switck/libngu/pulls/17) |
| **2022-03-11** | **Gray opens PR #18 to libngu: 32-bit reseed function** | [GitHub API: repos/switck/libngu/pulls/18](https://api.github.com/repos/switck/libngu/pulls/18) |
| 2022-03-15 | switck merges PR #18 | [GitHub API: repos/switck/libngu/pulls/18](https://api.github.com/repos/switck/libngu/pulls/18) |
| 2023-05-28 | Gray's GPG key expires | [GitHub API: users/doc-hex/gpg_keys](https://api.github.com/users/doc-hex/gpg_keys) |
| **2026-07-30** | **Attacker drains ~1,367 BTC ($88.6M) from 4,500+ addresses** | [808bits](https://808bits.com/articles/coldcard-entropy-failure-lessons/) |

---

## Blame allocation: Peter D. Gray

1. **Authored the vulnerability.** Commit `b18723dd` changed seed generation from the hardware TRNG path to libngu, routing through Yasmarang. Verified by GitHub API commit metadata.

2. **Shipped it with no process.** Direct push to master. No pull request. No code review. No CI. No GPG signature despite having a valid key. A 120-file, 5,488-line change to a system protecting billions of dollars, pushed with the message "First pass w/ libNgU." Verified by GitHub commit page (single parent, no PR, no review elements, verification: unsigned).

3. **Knew the library.** 19 commits to libngu starting 19 days before the integration. Coinkite maintained their own fork. He was not importing an unknown dependency. He was integrating a collaborator's code that he had been actively modifying.

4. **Introduced the license change in the same commit.** Deleted GPLv3, replaced with MIT + Commons Clause. The FSF considers this "source-available," not open source. The restriction on commercial use could have limited independent security auditors and tools. Verified by GitHub API file diffs.

5. **Authored the inadequate mitigation.** PR #18 (March 2022) added a 32-bit reseed that left Mk4/Q/Mk5 at ~72 bits, 56 bits below the 128-bit target. The reseed truncated 40 bytes of secure-element output to 4 bytes. The person who introduced the vulnerability also wrote the fix that left users still below the security threshold. Verified by GitHub API PR metadata.

6. **The one commit that needed signing was the one that was not signed.** Gray signed his libngu commits. switck signed their commits using Gray's key. But the firmware commit that integrated the vulnerable library, changed the license, and shipped to production was unsigned.

---

## Sources

- Block Engineering root-cause analysis: https://engineering.block.xyz/blog/predictable-rng-fallback-and-32-bit-reseed-in-coldcard-firmware
- 808bits operational analysis: https://808bits.com/articles/coldcard-entropy-failure-lessons/
- GitHub API: commit b18723dd: https://api.github.com/repos/Coldcard/firmware/commits/b18723dd
- GitHub commit page: https://github.com/Coldcard/firmware/commit/b18723dd
- GitHub API: doc-hex profile: https://api.github.com/users/doc-hex
- GitHub API: doc-hex GPG keys: https://api.github.com/users/doc-hex/gpg_keys
- GitHub API: switck profile: https://api.github.com/users/switck
- GitHub API: switck GPG keys (empty): https://api.github.com/users/switck/gpg_keys
- GitHub API: switck SSH keys (empty): https://api.github.com/users/switck/keys
- GitHub API: libngu repo: https://api.github.com/repos/switck/libngu
- GitHub API: libngu commits by doc-hex: https://api.github.com/repos/switck/libngu/commits?author=doc-hex
- GitHub API: libngu PR #17: https://api.github.com/repos/switck/libngu/pulls/17
- GitHub API: libngu PR #18: https://api.github.com/repos/switck/libngu/pulls/18
- GitHub API: coinkite/libngu fork: https://api.github.com/repos/coinkite/libngu
- GitHub API: switck/firmware fork: https://api.github.com/repos/switck/firmware
- GitHub API: switck/firmware commits: https://api.github.com/repos/switck/firmware/commits
- GitHub API: peter-conalgo profile: https://api.github.com/users/peter-conalgo
- GitHub API: Coldcard/.github (Not Found): https://api.github.com/repos/Coldcard/firmware/contents/.github
- GitHub: conftest.py: https://github.com/Coldcard/firmware/blob/b18723dd/testing/conftest.py
- GitHub: test_drv_entro.py: https://github.com/Coldcard/firmware/blob/b18723dd/testing/test_drv_entro.py
- GitHub: COPYING-CC: https://github.com/Coldcard/firmware/blob/master/COPYING-CC
- Parent commit .gitmodules: https://raw.githubusercontent.com/Coldcard/firmware/f456a88/.gitmodules
- GPG signature verification: switck commit `f7711c5522` contains key `A2DCD558C2BE5D7C` in raw PGP packet; doc-hex commit `61ffc74af1` contains key `F0E6CC6AFC16CF7B` in raw PGP packet

Starting to look like it. #nevent1q…gupf

2026-08-04T19:18:47Z

In reply to nevent1q…77pf
_________________________

Starting to look like it.

quoting
nevent1q…gupf
Oh shit… from Kimi K3. Smoking gun. Looks like doc-hex was also responsible for the code that added entropy on newer devices, but STILL fell below a reasonable threshold. This is super sketchy.

—————-
# Peter D. Gray and the Coldcard Entropy Incident

## Executive summary

Peter D. Gray, Coinkite engineer (GitHub: `doc-hex`, email: `peter@conalgo.com`), authored the commit that introduced the Coldcard entropy vulnerability and later authored the inadequate mitigation. On March 1, 2021, Gray pushed commit `b18723dd` directly to Coldcard's firmware master branch: a 120-file, 5,488-line change that replaced the hardware TRNG seed generation path with a call through the `libngu` library, which silently resolved to a non-cryptographic software PRNG called Yasmarang. The commit had no pull request, no code review, no CI pipeline, and no GPG signature despite Gray possessing a valid signing key. The same commit deleted the GPLv3 license and replaced it with MIT plus the Commons Clause.

Gray was not a passive consumer of libngu. He was an active contributor with 19 commits to the library starting February 10, 2021, 19 days before the integration commit. The library's primary author, `switck`, had no independent GPG key and signed their own commits using Gray's GPG key (`A2DCD558C2BE5D7C`), verified by raw PGP signature packet inspection. The two were collaborators: Gray was pushing to switck's firmware fork by January 2021, and Coinkite maintained their own fork of switck's library.

Thirteen months after introducing the vulnerability, Gray authored PR #18 to libngu (March 11, 2022): a 32-bit reseed function that brought newer devices (Mk4, Q, Mk5) from ~40 bits of effective entropy to ~72 bits. The design target was 128 bits. The person who introduced the vulnerability also wrote the fix that left users still below the security threshold.

The bug survived five years until July 30, 2026, when an attacker drained approximately 1,367 BTC ($88.6 million) from 4,500+ addresses. The attacker never touched a single device.

---

## Gray's relationship with libngu and switck

### The GPG key

Gray registered a GPG key on his GitHub account:

| Property | Value | Source |
|---|---|---|
| Primary key ID | `A2DCD558C2BE5D7C` | [GitHub API: users/doc-hex/gpg_keys](https://api.github.com/users/doc-hex/gpg_keys) |
| Subkey ID | `F0E6CC6AFC16CF7B` | [GitHub API: users/doc-hex/gpg_keys](https://api.github.com/users/doc-hex/gpg_keys) |
| Created | July 17, 2018 | GitHub API |
| Expired | May 28, 2023 | GitHub API |

switck has no GPG key registered on GitHub ([API returns empty](https://api.github.com/users/switck/gpg_keys)), no SSH keys ([API returns empty](https://api.github.com/users/switck/keys)), and uses only GitHub's noreply email. Location listed as "Cyberspace."

Despite switck having no registered key, switck's commits to libngu are GPG-signed. GitHub marks them `verified=False, reason=unknown_key` because the signing key is not registered to switck's account. Raw inspection of the PGP signature packets reveals the key ID:

- switck commit `f7711c5522` (2024-03-30): raw PGP packet contains `A2DCD558C2BE5D7C`. This is Gray's primary key.
- doc-hex commit `61ffc74af1` (2022-03-11): raw PGP packet contains `F0E6CC6AFC16CF7B`. This is Gray's subkey.

Both key IDs belong to the same GPG key registered to doc-hex. switck does not have their own GPG key. switck is signing commits with Peter Gray's key.

### The collaboration timeline

| Date | Event | Evidence |
|---|---|---|
| 2020-08-07 | switck creates GitHub account | [GitHub API: users/switck](https://api.github.com/users/switck) |
| 2020-10-15 | switck creates libngu repo, forks Coldcard/firmware, forks micropython | [GitHub API: repos/switck/libngu](https://api.github.com/repos/switck/libngu) |
| 2021-01-08 | Gray commits appear in switck's firmware fork (release signing, bug fixes) | [GitHub API: repos/switck/firmware/commits](https://api.github.com/repos/switck/firmware/commits) — commits by "Peter D. Gray" |
| 2021-02-10 | Coinkite forks switck's libngu. Gray makes first commit to libngu same day. | [GitHub API: repos/coinkite/libngu](https://api.github.com/repos/coinkite/libngu) (created 2021-02-10), [GitHub API: libngu commits by doc-hex](https://api.github.com/repos/switck/libngu/commits?author=doc-hex) |
| 2021-02-10 to 02-26 | Gray makes multiple commits to libngu (AES clone, env var tweaks, bip39 bugfix) | [GitHub API: libngu commits by doc-hex](https://api.github.com/repos/switck/libngu/commits?author=doc-hex) |

Gray had 19 total commits to libngu. He knew the library he was integrating.

### The `peter-conalgo` identity

The parent commit's `.gitmodules` referenced `github.com/peter-conalgo/trezor-crypto.git` as the `external/crypto` submodule. The GitHub account `peter-conalgo` was created April 22, 2021. The account name is "peter," no other identity. Gray's email is `peter@conalgo.com`. The commit removed this submodule (Gray's personal trezor-crypto fork) and replaced it with switck's libngu.

Sources: [GitHub API: users/peter-conalgo](https://api.github.com/users/peter-conalgo), [parent commit .gitmodules](https://raw.githubusercontent.com/Coldcard/firmware/f456a88/.gitmodules)

---

## The fateful commit: `b18723dd`

**Repository:** `github.com/Coldcard/firmware`
**SHA:** `b18723dd`
**Author:** Peter D. Gray (`peter@conalgo.com`)
**Date:** March 1, 2021, 14:03:03 UTC
**Message:** "First pass w/ libNgU"
**Parent:** `f456a88` (single parent: direct push, not a merge commit)
**Files changed:** 120
**Lines:** +2,766 / -2,722
**Pull request:** None
**Code review:** None
**CI:** None (no `.github` directory in repo)
**GPG signature:** Unsigned, despite Gray having a valid key (created 2018, valid through May 2023)

Sources: [GitHub API: commits/b18723dd](https://api.github.com/repos/Coldcard/firmware/commits/b18723dd), [GitHub commit page](https://github.com/Coldcard/firmware/commit/b18723dd), [GitHub API: contents/.github](https://api.github.com/repos/Coldcard/firmware/contents/.github) (Not Found)

### What Gray changed

| File | Change | Significance |
|---|---|---|
| `shared/random.py` | Changed `from ckcc import rng` to `import ngu`; set `bytes = ngu.random.bytes`. Comment still says "crypto-quality rng." | Call path that resolved to Yasmarang instead of the hardware TRNG |
| `shared/seed.py` | Changed `make_new_wallet()` from `rng_bytes(seed)` to `random.bytes(32)`. Changed `import tcc` to `import ngu` throughout. Changed `tcc.sha256(seed)` to `ngu.hash.sha256s(seed)`. | Seed generation function. Old path reached STM32 hardware TRNG. New path reached Yasmarang. |
| `shared/drv_entro.py` | Changed `import stash, tcc, hmac, chains` to `import stash, ngu, chains` | BIP-85 entropy derivation path migrated |
| `COPYING` | Deleted (674 lines, GPLv3) | Removed GPLv3 license |
| `COPYING-CC` | Added (MIT + Commons Clause) | Replaced GPLv3 with source-available license restricting commercial use |
| `.gitmodules` | Removed `external/crypto` (`peter-conalgo/trezor-crypto`), removed `external/modcryptocurrency`, added `external/libngu` (`switck/libngu`) | Removed Gray's personal trezor-crypto fork, added switck's libngu |

Sources: [GitHub API file diffs from commit b18723dd](https://api.github.com/repos/Coldcard/firmware/commits/b18723dd)

### The specific seed generation change

Before (firmware v3.2.2):
```python
seed = bytearray(32)
rng_bytes(seed) # reaches ckcc.rng_bytes -> STM32 hardware TRNG
```

After (commit b18723dd, shipped in v4.0.0):
```python
seed = random.bytes(32) # reaches ngu.random.bytes -> libngu -> rng_get() -> Yasmarang
```

Source: [Block Engineering analysis](https://engineering.block.xyz/blog/predictable-rng-fallback-and-32-bit-reseed-in-coldcard-firmware), section 5

### How the bug worked

The bug required two pieces: a faulty preprocessor check in libngu (switck's code) and Gray's seed generation change that routed through it (Gray's code).

**libngu's faulty check** (switck's code):
```c
#ifndef MICROPY_HW_ENABLE_RNG
#error "get a HW TRNG plz"
#endif
```
`#ifndef` tests whether the macro exists, not whether it is enabled. Coldcard's board config defines `MICROPY_HW_ENABLE_RNG` as `0`. The macro exists. Its value is zero. The check passes. The build links Yasmarang.

**Coldcard's board config** (Gray's code):
```c
#define MICROPY_HW_ENABLE_RNG (0)
```
Coinkite disabled MicroPython's built-in RNG because they provide their own wrapper. But Gray's seed generation change called `ngu.random.bytes` instead of `ckcc.rng_bytes`, routing through the broken libngu path.

Yasmarang was seeded from the MCU's 96-bit unique device identifier (factory metadata, not a secret), the SysTick counter (~80,000 possible values on Mk2/Mk3), and RTC registers (correlated timing values). None are cryptographic entropy sources. Collected once. Never reseeded.

Effective entropy: ~40 bits on Mk2/Mk3 (design target: 128 bits). A 40-bit keyspace is searchable on commodity hardware.

Sources: [Block Engineering analysis](https://engineering.block.xyz/blog/predictable-rng-fallback-and-32-bit-reseed-in-coldcard-firmware), sections 1-4

---

## The reseed commit: PR #18

Thirteen months after introducing the vulnerability, Gray authored a mitigation.

**Repository:** `github.com/switck/libngu`
**PR:** #18
**Title:** "Add reseed function to ngu.random module"
**Author:** doc-hex (Peter D. Gray)
**Submitted from:** `coinkite/libngu` fork
**Opened:** March 11, 2022
**Merged by:** switck on March 15, 2022

Source: [GitHub API: repos/switck/libngu/pulls/18](https://api.github.com/repos/switck/libngu/pulls/18)

### What the reseed did

```python
a = callgate.read_rng(1) # 32 bytes from SE1
b = callgate.read_rng(2) # 8 bytes from SE2
n = ngu.hash.sha256d(a + b)
n, = ustruct.unpack('I', n[0:4]) # keeps only 4 bytes
ngu.random.reseed(n) # replaces one 32-bit state word
```

The reseed hashes 40 bytes of secure-element output with SHA256d, then truncates to 4 bytes. It replaces one 32-bit Yasmarang state word. Maximum 2^32 distinct reseed values.

### Why the reseed was inadequate

| Property | Value |
|---|---|
| Secure element output | 40 bytes |
| Bytes retained after SHA256d | 4 (ustruct unpack 'I') |
| Maximum distinct reseed values | 2^32 |
| Effective entropy after reseed (Mk4/Q/Mk5) | ~72 bits |
| Design target | 128 bits |
| Gap | 56 bits below target |

The reseed function itself is trivial: `yasmarang_pad = mp_obj_get_int_truncated(arg)`. It does not initialize a cryptographic DRBG. It does not reset other state words. It does not provide periodic reseeding or prediction resistance.

The secure element firmware that provides the reseed entropy is closed source. `shared/callgate.py` is a thin wrapper around `ckcc.gate()` calls. The 72-bit figure rests on trust in a closed system that cannot be independently audited from outside the chip.

Source: [Block Engineering analysis](https://engineering.block.xyz/blog/predictable-rng-fallback-and-32-bit-reseed-in-coldcard-firmware), section 6

### The same key signed both commits

Gray's commits to libngu, including the reseed PR, are signed with his subkey `F0E6CC6AFC16CF7B`, verified by raw PGP packet inspection. switck's commits are signed with Gray's primary key `A2DCD558C2BE5D7C`. The same GPG key is used across both identities.

The fateful firmware commit `b18723dd` was the one commit Gray did not sign.

---

## The test failures

### What the test suite looked like at the time of the commit

| Issue | Evidence | Source |
|---|---|---|
| Test RNG deliberately seeded | `conftest.py` line 13: `random.seed(42)` | [GitHub: testing/conftest.py](https://github.com/Coldcard/firmware/blob/b18723dd/testing/conftest.py) |
| Only assertion on seed generation | `shared/seed.py`: `assert len(set(seed)) > 4` with comment `# TRNG failure` | GitHub API file diff |
| Entropy test tests derivation, not generation | `testing/test_drv_entro.py` tests BIP-85 derivation from a hardcoded XPRV | [GitHub: testing/test_drv_entro.py](https://github.com/Coldcard/firmware/blob/b18723dd/testing/test_drv_entro.py) |
| No end-to-end path test | No test generates a seed with known entropy input and verifies output | Full test directory inspection (18 test files) |
| No CI/CD | No `.github` directory | [GitHub API: contents/.github](https://api.github.com/repos/Coldcard/firmware/contents/.github) (Not Found) |

The test suite assumed the RNG worked. It never verified it. A seed with 40 bits of real entropy still expands into well-distributed, unique-looking addresses. No statistical test run against the output can distinguish "unpredictable" from "deterministic but unexamined."

The hardware TRNG code existed in every affected binary. It was reviewed. It was intact. It was never called from the seed generation path. Block Engineering's analysis: "reviews did not verify end-to-end symbol resolution and call reachability." Presence was mistaken for function.

Sources: [Block Engineering analysis](https://engineering.block.xyz/blog/predictable-rng-fallback-and-32-bit-reseed-in-coldcard-firmware), [808bits analysis](https://808bits.com/articles/coldcard-entropy-failure-lessons/)

---

## Timeline of Gray's involvement

| Date | Action | Evidence |
|---|---|---|
| 2018-07-17 | Gray creates GPG key `A2DCD558C2BE5D7C` | [GitHub API: users/doc-hex/gpg_keys](https://api.github.com/users/doc-hex/gpg_keys) |
| 2021-01-08 | Gray commits appear in switck's firmware fork | [GitHub API: repos/switck/firmware/commits](https://api.github.com/repos/switck/firmware/commits) |
| 2021-02-10 | Coinkite forks switck's libngu. Gray makes first commit to libngu. | [GitHub API: repos/coinkite/libngu](https://api.github.com/repos/coinkite/libngu), [GitHub API: libngu commits by doc-hex](https://api.github.com/repos/switck/libngu/commits?author=doc-hex) |
| 2021-02-10 to 02-26 | Gray makes multiple commits to libngu | [GitHub API: libngu commits by doc-hex](https://api.github.com/repos/switck/libngu/commits?author=doc-hex) |
| **2021-03-01** | **Gray pushes `b18723dd` to Coldcard/firmware master. No PR, no review, no CI, no GPG signature. Changes seed generation to route through libngu (Yasmarang). Deletes GPLv3, replaces with MIT + Commons Clause.** | [GitHub API: commits/b18723dd](https://api.github.com/repos/Coldcard/firmware/commits/b18723dd) |
| 2021-03-02 to 03-09 | Gray continues committing to libngu | [GitHub API: libngu commits by doc-hex](https://api.github.com/repos/switck/libngu/commits?author=doc-hex) |
| 2021-03-17 | Firmware v4.0.0 ships containing the vulnerability | [Block Engineering analysis](https://engineering.block.xyz/blog/predictable-rng-fallback-and-32-bit-reseed-in-coldcard-firmware), section 5 |
| 2022-01-12 | Gray opens PR #17 to libngu (hardware accelerated SHA256) from `coinkite/libngu` | [GitHub API: repos/switck/libngu/pulls/17](https://api.github.com/repos/switck/libngu/pulls/17) |
| **2022-03-11** | **Gray opens PR #18 to libngu: 32-bit reseed function** | [GitHub API: repos/switck/libngu/pulls/18](https://api.github.com/repos/switck/libngu/pulls/18) |
| 2022-03-15 | switck merges PR #18 | [GitHub API: repos/switck/libngu/pulls/18](https://api.github.com/repos/switck/libngu/pulls/18) |
| 2023-05-28 | Gray's GPG key expires | [GitHub API: users/doc-hex/gpg_keys](https://api.github.com/users/doc-hex/gpg_keys) |
| **2026-07-30** | **Attacker drains ~1,367 BTC ($88.6M) from 4,500+ addresses** | [808bits](https://808bits.com/articles/coldcard-entropy-failure-lessons/) |

---

## Blame allocation: Peter D. Gray

1. **Authored the vulnerability.** Commit `b18723dd` changed seed generation from the hardware TRNG path to libngu, routing through Yasmarang. Verified by GitHub API commit metadata.

2. **Shipped it with no process.** Direct push to master. No pull request. No code review. No CI. No GPG signature despite having a valid key. A 120-file, 5,488-line change to a system protecting billions of dollars, pushed with the message "First pass w/ libNgU." Verified by GitHub commit page (single parent, no PR, no review elements, verification: unsigned).

3. **Knew the library.** 19 commits to libngu starting 19 days before the integration. Coinkite maintained their own fork. He was not importing an unknown dependency. He was integrating a collaborator's code that he had been actively modifying.

4. **Introduced the license change in the same commit.** Deleted GPLv3, replaced with MIT + Commons Clause. The FSF considers this "source-available," not open source. The restriction on commercial use could have limited independent security auditors and tools. Verified by GitHub API file diffs.

5. **Authored the inadequate mitigation.** PR #18 (March 2022) added a 32-bit reseed that left Mk4/Q/Mk5 at ~72 bits, 56 bits below the 128-bit target. The reseed truncated 40 bytes of secure-element output to 4 bytes. The person who introduced the vulnerability also wrote the fix that left users still below the security threshold. Verified by GitHub API PR metadata.

6. **The one commit that needed signing was the one that was not signed.** Gray signed his libngu commits. switck signed their commits using Gray's key. But the firmware commit that integrated the vulnerable library, changed the license, and shipped to production was unsigned.

---

## Sources

- Block Engineering root-cause analysis: https://engineering.block.xyz/blog/predictable-rng-fallback-and-32-bit-reseed-in-coldcard-firmware
- 808bits operational analysis: https://808bits.com/articles/coldcard-entropy-failure-lessons/
- GitHub API: commit b18723dd: https://api.github.com/repos/Coldcard/firmware/commits/b18723dd
- GitHub commit page: https://github.com/Coldcard/firmware/commit/b18723dd
- GitHub API: doc-hex profile: https://api.github.com/users/doc-hex
- GitHub API: doc-hex GPG keys: https://api.github.com/users/doc-hex/gpg_keys
- GitHub API: switck profile: https://api.github.com/users/switck
- GitHub API: switck GPG keys (empty): https://api.github.com/users/switck/gpg_keys
- GitHub API: switck SSH keys (empty): https://api.github.com/users/switck/keys
- GitHub API: libngu repo: https://api.github.com/repos/switck/libngu
- GitHub API: libngu commits by doc-hex: https://api.github.com/repos/switck/libngu/commits?author=doc-hex
- GitHub API: libngu PR #17: https://api.github.com/repos/switck/libngu/pulls/17
- GitHub API: libngu PR #18: https://api.github.com/repos/switck/libngu/pulls/18
- GitHub API: coinkite/libngu fork: https://api.github.com/repos/coinkite/libngu
- GitHub API: switck/firmware fork: https://api.github.com/repos/switck/firmware
- GitHub API: switck/firmware commits: https://api.github.com/repos/switck/firmware/commits
- GitHub API: peter-conalgo profile: https://api.github.com/users/peter-conalgo
- GitHub API: Coldcard/.github (Not Found): https://api.github.com/repos/Coldcard/firmware/contents/.github
- GitHub: conftest.py: https://github.com/Coldcard/firmware/blob/b18723dd/testing/conftest.py
- GitHub: test_drv_entro.py: https://github.com/Coldcard/firmware/blob/b18723dd/testing/test_drv_entro.py
- GitHub: COPYING-CC: https://github.com/Coldcard/firmware/blob/master/COPYING-CC
- Parent commit .gitmodules: https://raw.githubusercontent.com/Coldcard/firmware/f456a88/.gitmodules
- GPG signature verification: switck commit `f7711c5522` contains key `A2DCD558C2BE5D7C` in raw PGP packet; doc-hex commit `61ffc74af1` contains key `F0E6CC6AFC16CF7B` in raw PGP packet

For sure. I don’t know if people aren’t talking about the ...

2026-08-04T18:52:55Z

In reply to nevent1q…5uqy
_________________________

For sure. I don’t know if people aren’t talking about the path forward because these options aren’t possible or if we are just too caught up in the current state of apparently blindly trusting vendors!

Thoughts here if you want to read. I am not an engineer so I ...

2026-08-04T18:47:31Z

In reply to nevent1q…tlsh
_________________________

Thoughts here if you want to read. I am not an engineer so I don’t know how feasible some of these proposals really are.

quoting
nevent1q…xkuc

A cultural failure: execution-path trust over evaluation, and social reputation over development quality.

On July 30, 2026, someone started emptying Bitcoin wallets that had been dormant for years. No phishing, no malware, no compromised exchange. A five-year-old firmware bug had made the seed phrases guessable, and the attacker derived the private keys offline and swept the first wave of funds before anyone knew there was a problem.

This is not another write-up about the mechanics of the hack. The bug itself is almost boring: one check that tested whether a setting existed instead of whether it was turned on. What should raise eyebrows is that it lived for five years in open, widely-read code, inside the wallet the community trusted most, and nobody caught it. It went unnoticed because self-custody culture rewards the wrong things. It assumes a code path runs because the code is present, and it grades vendors on reputation instead of evidence. Those two habits, execution-path trust over verification and reputation over development practice, are the real vulnerability, and they will keep producing thefts like this one until the community trades trust for proof. What follows is less about Coldcard than about the standard that allowed it, and the one that has to replace it. The article closes with an example draft checklist that turns that standard into concrete questions you can put to any hardware wallet vendor.

Social media has reached for the easy lesson: self-custody is too hard, go back to letting a custodian hold the keys. That the average person recoils from self-custody in the short term is probably unavoidable. If it becomes a long-term trend, that will be because the Bitcoin ecosystem failed to correct its flawed culture around security.

Exchanges did not die after Mt. Gox and self-custody will not die after this. The exchange industry has evolved since Mt. Gox with multi-signature custody, proof-of-reserve practice, and regulatory structure that outlasted the operator who failed. Whether massive self-custody failures produce that kind of durable change is the open question. One-off audits are currently underway across every hardware wallet vendor, but the real lever is how we move forward when we talk about security in self-custody.

The bug, briefly

Coldcard's board config defined the macro MICROPY_HW_ENABLE_RNG and set it to 0, because Coinkite supplies its own hardware RNG. A library the firmware migrated to in 2021 checked #ifndef MICROPY_HW_ENABLE_RNG, which asks whether the macro exists, not whether it is switched on. The macro existed. The build linked MicroPython's software fallback PRNG, a toy generator meant for chips with no hardware RNG at all. The real hardware RNG code stayed in every affected binary, reviewed and intact. Seed generation simply never called it.

Coinkite puts effective entropy on Mk2 and Mk3 devices running firmware v4.0.1 through v4.1.9 at roughly 40 bits against a 128-bit design target. Forty bits is a weekend on commodity hardware. Block Engineering's independent analysis is worse: depending on what an attacker already knows about the device UID and boot timing, the practical search space collapses toward 2^16, and the reseed on later models is capped at 32 bits because only four digest bytes ever reach it. Coinkite's figure for Mk4, Q, and Mk5 is about 72 bits, still under the standard and inside the budget of a funded attacker.

Entropy generation is the critical step in self-custody that has no replacement. The seed is the root of every key the wallet will ever derive, so a perfect PIN, textbook multisig, and a signing screen that shows exactly what you are approving all rest on top of it, and none of them can save a seed an attacker can guess. That is why this one step is worth staring at while the rest of the device goes unmentioned.

That is the entire technical story, and it is the least interesting part of the incident. The bug is ordinary. What matters is that it shipped, passed review, survived a test suite, and sat in public source for five years underneath the device the community told everyone to buy.

Where the process broke

The development practices at Coinkite failed to catch this. The commit that introduced the bug, b18723dd on March 1, 2021, changed 120 files and 5,488 lines, swapped out the cryptographic primitives under seed generation and signing, and went straight to master with the message "First pass w/ libNgU." The public history shows a single-parent commit with no merge, no pull request, and no CI run. A change to seed generation reaching users with no formal, published review process is not a one-off slip; it is a process with limited gates and no transparency.

Testing the output for entropy is nearly impossible, and that is the trap. The suite set random.seed(42) for reproducibility, and the only runtime check asserted a handful of distinct byte values, which any deterministic generator passes. No statistical test on a finished seed can separate unpredictable from reproducible: a 40-bit seed still expands into unique, normal-looking addresses. Entropy is a property of the process, not the bytes. What is tractable is testing the path, which nobody did: confirm the hardware RNG is actually reached, and that known inputs produce known outputs. Block Engineering found the failure there in hours. The hardware RNG exported different function names than the library expected, so the call bound to MicroPython's software generator instead, and the correct code sat present and unreachable in every binary. It is the unverified backup: file there, checksum fine, empty the day you restore from it.

A closed secure element adds a variable you cannot account for. The reseed on Mk4, Q, and Mk5 comes from a chip whose firmware nobody outside Coinkite can audit, so the 72-bit figure rests on trust rather than measurement. Reproducible builds prove the shipped binary matches the public source, which matters, but they cannot tell you the source is correct, and they cannot let you feed known entropy into the secure element and check what comes back. Every closed component in the entropy path is one more thing taken on faith.

Most importantly, the "grading" of Coinkite as a reliable provider was done on reputation. Coldcard was the default recommendation for years, sold on marketing, feature lists, and word of mouth, and that recommendation was never attached to anything a buyer could inspect. Nobody traced the call path because everybody assumed somebody already had. That is the habit that has to change. A recommendation should turn on the strength of the development team, whether the code and build can actually be audited, the quality of the tests, and how much trust the design removes from any single part. Reputation without clear evidence is nothing but trust.

What vendors should do to improve validation

None of these are hard asks. Most are a weekend of engineering time, and the first three would have increased the odds of catching the bug.

Require a pull request, a named reviewer, and a green CI run for any change touching cryptographic code. No maintainer exemption, no direct pushes to the main branch, no "first pass" commits that migrate a crypto library. Coinkite cleared none of it for this change. Make sure discussions are publicly visible if code is visible.

Add known-answer entropy tests to CI. Feed a known entropy source into the device, generate a seed, and verify the output is a pure function of the input. Then disable the device's own entropy and confirm the output changes. A working hardware RNG makes seeds depend on hardware entropy; a broken one makes them deterministic given a known input.

Verify the call graph on the built binary, not the source. Confirm at the linker level that the RNG symbol resolves to the hardware path. Reading the code cannot tell you this, which is exactly how five years went by.

Emit generation-time evidence. When a seed is created, the device should record which physical source each byte came from (the hardware RNG register, the secure element, the user's dice) and confirm each was live, never the entropy values themselves, which are the seed. The record is about provenance, not quality: whitening makes even a broken generator's output look random, so a statistical check passes on the exact fallback that caused this, and what cannot be faked is that the hardware path was actually read. Keep it as a signed, exportable/viewable attestation, and leave out any field that also feeds the seed, since a boot timestamp here would have leaked the timing the attack relied on. Sign it across the trust boundary: each component attests the other's contribution, so one buggy component cannot forge both the seed and its own alibi. A birth certificate like that would let a user identify the exact code blocks responsible for their seed generation, instead of inferring it from a firmware version and their own memory.

Re-run AI-assisted audits on old code with current tooling on a fixed schedule. Code that was clean under 2021 review methods is not clean now.

What the community has to demand

The audit wave now underway is the right instinct running on the wrong standard. Ledger has said its certified TRNG is unaffected. Trezor has said it does not share Coldcard's code. Keystone, Foundation, and BitBox have issued similar statements. Every one of those is a claim, and Coldcard would have made the identical claim on any day of the last five years.

The question each vendor needs to answer is narrow and checkable: can you trace the entropy path from source to seed, end to end, on the actual shipped binary, and show that the hardware RNG is reachable from make_new_wallet or its equivalent? "We have a TRNG and it is in the code" is the answer that failed.

Open-source vendors have an advantage in answering this question, and should use it. Producing that trace means publishing the source path, the symbol resolution on the built binary, and the known-answer test vectors, none of which exposes a proprietary secure-element design. The closed part can stay closed; the entropy path can still be shown. A vendor that answers "trust our certification" when it could publish the trace is choosing opacity it does not need, and that choice should count against it.

Three levels of assurance need separate names, because collapsing them is how this happened. - Source availability means you can read it. - Reproducible builds mean you can confirm the binary matches what you read. - End-to-end path verification means you can confirm the secure path actually executes.

Coldcard had the first two. Almost every discussion of hardware wallet security treats the first two as sufficient, which is the problem we need to fix now.

Two structural changes would make the validation process normal rather than heroic: - One is a published audit framework with standard test vectors, so a vendor can be measured against a checklist that already exists instead of a checklist they wrote. - The other is cross-vendor review or bug bounty program, funded jointly, on the argument that a design failure at any vendor damages every vendor's customers.

This is at least the second time a bug like this has produced weak seeds at scale. In 2023, Milk Sad (CVE-2023-39910) revealed that Libbitcoin Explorer's bx seed used a Mersenne Twister seeded from 32-bit time(), exposing 120,000 keys. Same root cause, same cultural failure: open source, publicly documented, nobody auditing the entropy path. The response was to fix Libbitcoin, warn users, and move on. That response worked once and cannot work twice. Every wallet that generates keys needs its entropy path traced on every release, and the traces need to be published.

Holders also have two levers to pull to mitigate risk in key generation: multi-vendor multisig and bring your own entropy (dice, coins, etc.). Both mechanisms reduce the reliance of wallet security on any single vendor's implementation. In Coinkite's case, multisig and dice-roll users are thought to be unaffected by this exploit. Critics will say that dice rolling can be unreliable. The reality is that the current state of industry means users either roll their own, or trust a vendor. The only way to actually improve this dynamic is to make it easier for users to verify the validity of entropy from a hardware wallet. Even with these options as part of the equation a robust future of self-custody heavily relies on the community getting the culture around vendor/code evaluation correct.

The pressing challenge of AI

Everything above points one direction: transparency is the advantage. A vendor that shows its work, in the code and in the build, needs less trust from the buyer, and needing less trust is the entire point of self-custody. But open code cuts both ways. Anyone can read it, which means anyone can also hand it to a frontier model.

Any code that has ever been public is now scannable by an attacker with a current model, across the full commit history, faster than any human review team can work. The five-year dormancy window that let this bug survive is closing, and it closes for every project at once. A clean audit in 2024 says nothing about 2026, because the tool doing the reading keeps getting better. Auditing becomes maintenance, not a milestone.

Hiding the source is the wrong reaction. Closed code delays attacker discovery, and delays defender discovery by more, because you find your own bugs only when the funds are already gone. The economics point the same way: AI review at scale runs into real token bills, and an open project can spread that cost across a community while a closed vendor pays alone and cuts corners in private. What fits the moment is a shared audit framework, one that lets the community hunt vulnerabilities early and often: full re-audits each time a more capable model ships, and AI-assisted review on every pull request, with human oversight and discussion before anything merges.

Moving Forward

It is tempting to lay this on Coinkite alone, or on the people who recommended the device for years. The blame is wider than that. Bitcoin worked. Self-custody worked. What failed sat around them: a critical bug in plain sight in public code, under a device holding a large share of the community's savings, and no habit anywhere in the ecosystem was going to catch it.

That culture is being rebuilt now and our discussions will shape it. Over the next few months the audits underway will continue in two possible directions: traced entropy paths, published test vectors, and symbol resolution checked against real binaries, or another round of reassuring press releases from vendors. The Coldcard incident proved that the Bitcoin community had largely been trusting and not verifying, despite the common mantra to do the opposite.

This is not the time to recoil from our stated values. It is the time to shift from trust to verification. One preprocessor check tested the wrong thing for five years and nobody looked, because nobody had to; reputation stood in for proof. The wallets that deserve trust after this are the ones that never ask for it, the ones that hand you the proof and let you run it yourself.

Appendix: Example Hardware Evaluation Framework

Everything above reduces to one question a buyer or reviewer can put to any vendor: can you show, not assert, that the secure path runs? The checklist below turns that into concrete asks. A vendor's answers sort them into the three assurance levels, and a "no" in the entropy-path section should count for more than a polished answer everywhere else.

Assurance level - Is the firmware source available and complete, including the seed-generation path? - Are builds reproducible, so you can rebuild and match the shipped binary byte for byte? - Can they show end-to-end path verification, not just that the code exists?

The entropy path - Can they trace the path from source to seed on the actual shipped binary, and show the hardware RNG is reachable from the seed-generation function? - Do they verify at the linker level that the RNG symbol resolves to the hardware path rather than a software fallback? - Do they publish known-answer vectors from a test build that pins every entropy source (hardware RNG, secure element, user-supplied dice) to a fixed value, and show that changing each source changes the seed? - Have they audited every preprocessor guard in the entropy path for the existence-versus-value distinction (#ifndef X versus #if X != 0)?

Development process - Are a pull request, a named reviewer, and a green CI run required for any change touching cryptographic code, with no direct-to-master exemptions? - Are there commits that swapped cryptographic primitives without review or detailed discussion around the change?

Testing - Do the tests cover seed-generation entropy, or only downstream behavior? - Do they test the process (path reachability, known-answer vectors) rather than run statistics on output bytes, which a broken generator passes?

Closed components - Which parts are closed (secure element, bootloader), and do any sit in the entropy path? - For each closed component in that path, what exactly is taken on trust, and can they bound it, such as the real bit contribution of a reseed? - Where you cannot inject a known value, can they at least show the component is load-bearing (force a reseed, confirm the output depends on it) and name what stays unverifiable?

Generation-time evidence - Does the device record or show provenance, which physical source the entropy came from during seed generation, without ever persisting the entropy values? - Is the record a signed, exportable attestation that leaves out any field that also feeds the seed? - Is it signed across a trust boundary, each component attesting the other's contribution?

Track record - After their last disclosure, did they publish a root cause and traces, or reassurances? - Do they re-audit old code as more capable models ship? - Does the license permit independent commercial auditing, or does it deter the people who would build tooling against it?

Even worse when you find out switck and doc-hex were also ...

2026-08-04T18:40:28Z

In reply to nevent1q…g6c4
_________________________

Even worse when you find out switck and doc-hex were also responsible for the commits that raised the entropy on the mk4,5, but still left them way under the expected 128 bit threshold.

quoting
nevent1q…sqj3
Oh shit… from Kimi K3. Smoking gun. Looks like doc-hex was also responsible for the code that added entropy on newer devices, but STILL fell below a reasonable threshold. This is super sketchy.

—————-
# Peter D. Gray and the Coldcard Entropy Incident

## Executive summary

Peter D. Gray, Coinkite engineer (GitHub: `doc-hex`, email: `peter@conalgo.com`), authored the commit that introduced the Coldcard entropy vulnerability and later authored the inadequate mitigation. On March 1, 2021, Gray pushed commit `b18723dd` directly to Coldcard's firmware master branch: a 120-file, 5,488-line change that replaced the hardware TRNG seed generation path with a call through the `libngu` library, which silently resolved to a non-cryptographic software PRNG called Yasmarang. The commit had no pull request, no code review, no CI pipeline, and no GPG signature despite Gray possessing a valid signing key. The same commit deleted the GPLv3 license and replaced it with MIT plus the Commons Clause.

Gray was not a passive consumer of libngu. He was an active contributor with 19 commits to the library starting February 10, 2021, 19 days before the integration commit. The library's primary author, `switck`, had no independent GPG key and signed their own commits using Gray's GPG key (`A2DCD558C2BE5D7C`), verified by raw PGP signature packet inspection. The two were collaborators: Gray was pushing to switck's firmware fork by January 2021, and Coinkite maintained their own fork of switck's library.

Thirteen months after introducing the vulnerability, Gray authored PR #18 to libngu (March 11, 2022): a 32-bit reseed function that brought newer devices (Mk4, Q, Mk5) from ~40 bits of effective entropy to ~72 bits. The design target was 128 bits. The person who introduced the vulnerability also wrote the fix that left users still below the security threshold.

The bug survived five years until July 30, 2026, when an attacker drained approximately 1,367 BTC ($88.6 million) from 4,500+ addresses. The attacker never touched a single device.

---

## Gray's relationship with libngu and switck

### The GPG key

Gray registered a GPG key on his GitHub account:

| Property | Value | Source |
|---|---|---|
| Primary key ID | `A2DCD558C2BE5D7C` | [GitHub API: users/doc-hex/gpg_keys](https://api.github.com/users/doc-hex/gpg_keys) |
| Subkey ID | `F0E6CC6AFC16CF7B` | [GitHub API: users/doc-hex/gpg_keys](https://api.github.com/users/doc-hex/gpg_keys) |
| Created | July 17, 2018 | GitHub API |
| Expired | May 28, 2023 | GitHub API |

switck has no GPG key registered on GitHub ([API returns empty](https://api.github.com/users/switck/gpg_keys)), no SSH keys ([API returns empty](https://api.github.com/users/switck/keys)), and uses only GitHub's noreply email. Location listed as "Cyberspace."

Despite switck having no registered key, switck's commits to libngu are GPG-signed. GitHub marks them `verified=False, reason=unknown_key` because the signing key is not registered to switck's account. Raw inspection of the PGP signature packets reveals the key ID:

- switck commit `f7711c5522` (2024-03-30): raw PGP packet contains `A2DCD558C2BE5D7C`. This is Gray's primary key.
- doc-hex commit `61ffc74af1` (2022-03-11): raw PGP packet contains `F0E6CC6AFC16CF7B`. This is Gray's subkey.

Both key IDs belong to the same GPG key registered to doc-hex. switck does not have their own GPG key. switck is signing commits with Peter Gray's key.

### The collaboration timeline

| Date | Event | Evidence |
|---|---|---|
| 2020-08-07 | switck creates GitHub account | [GitHub API: users/switck](https://api.github.com/users/switck) |
| 2020-10-15 | switck creates libngu repo, forks Coldcard/firmware, forks micropython | [GitHub API: repos/switck/libngu](https://api.github.com/repos/switck/libngu) |
| 2021-01-08 | Gray commits appear in switck's firmware fork (release signing, bug fixes) | [GitHub API: repos/switck/firmware/commits](https://api.github.com/repos/switck/firmware/commits) — commits by "Peter D. Gray" |
| 2021-02-10 | Coinkite forks switck's libngu. Gray makes first commit to libngu same day. | [GitHub API: repos/coinkite/libngu](https://api.github.com/repos/coinkite/libngu) (created 2021-02-10), [GitHub API: libngu commits by doc-hex](https://api.github.com/repos/switck/libngu/commits?author=doc-hex) |
| 2021-02-10 to 02-26 | Gray makes multiple commits to libngu (AES clone, env var tweaks, bip39 bugfix) | [GitHub API: libngu commits by doc-hex](https://api.github.com/repos/switck/libngu/commits?author=doc-hex) |

Gray had 19 total commits to libngu. He knew the library he was integrating.

### The `peter-conalgo` identity

The parent commit's `.gitmodules` referenced `github.com/peter-conalgo/trezor-crypto.git` as the `external/crypto` submodule. The GitHub account `peter-conalgo` was created April 22, 2021. The account name is "peter," no other identity. Gray's email is `peter@conalgo.com`. The commit removed this submodule (Gray's personal trezor-crypto fork) and replaced it with switck's libngu.

Sources: [GitHub API: users/peter-conalgo](https://api.github.com/users/peter-conalgo), [parent commit .gitmodules](https://raw.githubusercontent.com/Coldcard/firmware/f456a88/.gitmodules)

---

## The fateful commit: `b18723dd`

**Repository:** `github.com/Coldcard/firmware`
**SHA:** `b18723dd`
**Author:** Peter D. Gray (`peter@conalgo.com`)
**Date:** March 1, 2021, 14:03:03 UTC
**Message:** "First pass w/ libNgU"
**Parent:** `f456a88` (single parent: direct push, not a merge commit)
**Files changed:** 120
**Lines:** +2,766 / -2,722
**Pull request:** None
**Code review:** None
**CI:** None (no `.github` directory in repo)
**GPG signature:** Unsigned, despite Gray having a valid key (created 2018, valid through May 2023)

Sources: [GitHub API: commits/b18723dd](https://api.github.com/repos/Coldcard/firmware/commits/b18723dd), [GitHub commit page](https://github.com/Coldcard/firmware/commit/b18723dd), [GitHub API: contents/.github](https://api.github.com/repos/Coldcard/firmware/contents/.github) (Not Found)

### What Gray changed

| File | Change | Significance |
|---|---|---|
| `shared/random.py` | Changed `from ckcc import rng` to `import ngu`; set `bytes = ngu.random.bytes`. Comment still says "crypto-quality rng." | Call path that resolved to Yasmarang instead of the hardware TRNG |
| `shared/seed.py` | Changed `make_new_wallet()` from `rng_bytes(seed)` to `random.bytes(32)`. Changed `import tcc` to `import ngu` throughout. Changed `tcc.sha256(seed)` to `ngu.hash.sha256s(seed)`. | Seed generation function. Old path reached STM32 hardware TRNG. New path reached Yasmarang. |
| `shared/drv_entro.py` | Changed `import stash, tcc, hmac, chains` to `import stash, ngu, chains` | BIP-85 entropy derivation path migrated |
| `COPYING` | Deleted (674 lines, GPLv3) | Removed GPLv3 license |
| `COPYING-CC` | Added (MIT + Commons Clause) | Replaced GPLv3 with source-available license restricting commercial use |
| `.gitmodules` | Removed `external/crypto` (`peter-conalgo/trezor-crypto`), removed `external/modcryptocurrency`, added `external/libngu` (`switck/libngu`) | Removed Gray's personal trezor-crypto fork, added switck's libngu |

Sources: [GitHub API file diffs from commit b18723dd](https://api.github.com/repos/Coldcard/firmware/commits/b18723dd)

### The specific seed generation change

Before (firmware v3.2.2):
```python
seed = bytearray(32)
rng_bytes(seed) # reaches ckcc.rng_bytes -> STM32 hardware TRNG
```

After (commit b18723dd, shipped in v4.0.0):
```python
seed = random.bytes(32) # reaches ngu.random.bytes -> libngu -> rng_get() -> Yasmarang
```

Source: [Block Engineering analysis](https://engineering.block.xyz/blog/predictable-rng-fallback-and-32-bit-reseed-in-coldcard-firmware), section 5

### How the bug worked

The bug required two pieces: a faulty preprocessor check in libngu (switck's code) and Gray's seed generation change that routed through it (Gray's code).

**libngu's faulty check** (switck's code):
```c
#ifndef MICROPY_HW_ENABLE_RNG
#error "get a HW TRNG plz"
#endif
```
`#ifndef` tests whether the macro exists, not whether it is enabled. Coldcard's board config defines `MICROPY_HW_ENABLE_RNG` as `0`. The macro exists. Its value is zero. The check passes. The build links Yasmarang.

**Coldcard's board config** (Gray's code):
```c
#define MICROPY_HW_ENABLE_RNG (0)
```
Coinkite disabled MicroPython's built-in RNG because they provide their own wrapper. But Gray's seed generation change called `ngu.random.bytes` instead of `ckcc.rng_bytes`, routing through the broken libngu path.

Yasmarang was seeded from the MCU's 96-bit unique device identifier (factory metadata, not a secret), the SysTick counter (~80,000 possible values on Mk2/Mk3), and RTC registers (correlated timing values). None are cryptographic entropy sources. Collected once. Never reseeded.

Effective entropy: ~40 bits on Mk2/Mk3 (design target: 128 bits). A 40-bit keyspace is searchable on commodity hardware.

Sources: [Block Engineering analysis](https://engineering.block.xyz/blog/predictable-rng-fallback-and-32-bit-reseed-in-coldcard-firmware), sections 1-4

---

## The reseed commit: PR #18

Thirteen months after introducing the vulnerability, Gray authored a mitigation.

**Repository:** `github.com/switck/libngu`
**PR:** #18
**Title:** "Add reseed function to ngu.random module"
**Author:** doc-hex (Peter D. Gray)
**Submitted from:** `coinkite/libngu` fork
**Opened:** March 11, 2022
**Merged by:** switck on March 15, 2022

Source: [GitHub API: repos/switck/libngu/pulls/18](https://api.github.com/repos/switck/libngu/pulls/18)

### What the reseed did

```python
a = callgate.read_rng(1) # 32 bytes from SE1
b = callgate.read_rng(2) # 8 bytes from SE2
n = ngu.hash.sha256d(a + b)
n, = ustruct.unpack('I', n[0:4]) # keeps only 4 bytes
ngu.random.reseed(n) # replaces one 32-bit state word
```

The reseed hashes 40 bytes of secure-element output with SHA256d, then truncates to 4 bytes. It replaces one 32-bit Yasmarang state word. Maximum 2^32 distinct reseed values.

### Why the reseed was inadequate

| Property | Value |
|---|---|
| Secure element output | 40 bytes |
| Bytes retained after SHA256d | 4 (ustruct unpack 'I') |
| Maximum distinct reseed values | 2^32 |
| Effective entropy after reseed (Mk4/Q/Mk5) | ~72 bits |
| Design target | 128 bits |
| Gap | 56 bits below target |

The reseed function itself is trivial: `yasmarang_pad = mp_obj_get_int_truncated(arg)`. It does not initialize a cryptographic DRBG. It does not reset other state words. It does not provide periodic reseeding or prediction resistance.

The secure element firmware that provides the reseed entropy is closed source. `shared/callgate.py` is a thin wrapper around `ckcc.gate()` calls. The 72-bit figure rests on trust in a closed system that cannot be independently audited from outside the chip.

Source: [Block Engineering analysis](https://engineering.block.xyz/blog/predictable-rng-fallback-and-32-bit-reseed-in-coldcard-firmware), section 6

### The same key signed both commits

Gray's commits to libngu, including the reseed PR, are signed with his subkey `F0E6CC6AFC16CF7B`, verified by raw PGP packet inspection. switck's commits are signed with Gray's primary key `A2DCD558C2BE5D7C`. The same GPG key is used across both identities.

The fateful firmware commit `b18723dd` was the one commit Gray did not sign.

---

## The test failures

### What the test suite looked like at the time of the commit

| Issue | Evidence | Source |
|---|---|---|
| Test RNG deliberately seeded | `conftest.py` line 13: `random.seed(42)` | [GitHub: testing/conftest.py](https://github.com/Coldcard/firmware/blob/b18723dd/testing/conftest.py) |
| Only assertion on seed generation | `shared/seed.py`: `assert len(set(seed)) > 4` with comment `# TRNG failure` | GitHub API file diff |
| Entropy test tests derivation, not generation | `testing/test_drv_entro.py` tests BIP-85 derivation from a hardcoded XPRV | [GitHub: testing/test_drv_entro.py](https://github.com/Coldcard/firmware/blob/b18723dd/testing/test_drv_entro.py) |
| No end-to-end path test | No test generates a seed with known entropy input and verifies output | Full test directory inspection (18 test files) |
| No CI/CD | No `.github` directory | [GitHub API: contents/.github](https://api.github.com/repos/Coldcard/firmware/contents/.github) (Not Found) |

The test suite assumed the RNG worked. It never verified it. A seed with 40 bits of real entropy still expands into well-distributed, unique-looking addresses. No statistical test run against the output can distinguish "unpredictable" from "deterministic but unexamined."

The hardware TRNG code existed in every affected binary. It was reviewed. It was intact. It was never called from the seed generation path. Block Engineering's analysis: "reviews did not verify end-to-end symbol resolution and call reachability." Presence was mistaken for function.

Sources: [Block Engineering analysis](https://engineering.block.xyz/blog/predictable-rng-fallback-and-32-bit-reseed-in-coldcard-firmware), [808bits analysis](https://808bits.com/articles/coldcard-entropy-failure-lessons/)

---

## Timeline of Gray's involvement

| Date | Action | Evidence |
|---|---|---|
| 2018-07-17 | Gray creates GPG key `A2DCD558C2BE5D7C` | [GitHub API: users/doc-hex/gpg_keys](https://api.github.com/users/doc-hex/gpg_keys) |
| 2021-01-08 | Gray commits appear in switck's firmware fork | [GitHub API: repos/switck/firmware/commits](https://api.github.com/repos/switck/firmware/commits) |
| 2021-02-10 | Coinkite forks switck's libngu. Gray makes first commit to libngu. | [GitHub API: repos/coinkite/libngu](https://api.github.com/repos/coinkite/libngu), [GitHub API: libngu commits by doc-hex](https://api.github.com/repos/switck/libngu/commits?author=doc-hex) |
| 2021-02-10 to 02-26 | Gray makes multiple commits to libngu | [GitHub API: libngu commits by doc-hex](https://api.github.com/repos/switck/libngu/commits?author=doc-hex) |
| **2021-03-01** | **Gray pushes `b18723dd` to Coldcard/firmware master. No PR, no review, no CI, no GPG signature. Changes seed generation to route through libngu (Yasmarang). Deletes GPLv3, replaces with MIT + Commons Clause.** | [GitHub API: commits/b18723dd](https://api.github.com/repos/Coldcard/firmware/commits/b18723dd) |
| 2021-03-02 to 03-09 | Gray continues committing to libngu | [GitHub API: libngu commits by doc-hex](https://api.github.com/repos/switck/libngu/commits?author=doc-hex) |
| 2021-03-17 | Firmware v4.0.0 ships containing the vulnerability | [Block Engineering analysis](https://engineering.block.xyz/blog/predictable-rng-fallback-and-32-bit-reseed-in-coldcard-firmware), section 5 |
| 2022-01-12 | Gray opens PR #17 to libngu (hardware accelerated SHA256) from `coinkite/libngu` | [GitHub API: repos/switck/libngu/pulls/17](https://api.github.com/repos/switck/libngu/pulls/17) |
| **2022-03-11** | **Gray opens PR #18 to libngu: 32-bit reseed function** | [GitHub API: repos/switck/libngu/pulls/18](https://api.github.com/repos/switck/libngu/pulls/18) |
| 2022-03-15 | switck merges PR #18 | [GitHub API: repos/switck/libngu/pulls/18](https://api.github.com/repos/switck/libngu/pulls/18) |
| 2023-05-28 | Gray's GPG key expires | [GitHub API: users/doc-hex/gpg_keys](https://api.github.com/users/doc-hex/gpg_keys) |
| **2026-07-30** | **Attacker drains ~1,367 BTC ($88.6M) from 4,500+ addresses** | [808bits](https://808bits.com/articles/coldcard-entropy-failure-lessons/) |

---

## Blame allocation: Peter D. Gray

1. **Authored the vulnerability.** Commit `b18723dd` changed seed generation from the hardware TRNG path to libngu, routing through Yasmarang. Verified by GitHub API commit metadata.

2. **Shipped it with no process.** Direct push to master. No pull request. No code review. No CI. No GPG signature despite having a valid key. A 120-file, 5,488-line change to a system protecting billions of dollars, pushed with the message "First pass w/ libNgU." Verified by GitHub commit page (single parent, no PR, no review elements, verification: unsigned).

3. **Knew the library.** 19 commits to libngu starting 19 days before the integration. Coinkite maintained their own fork. He was not importing an unknown dependency. He was integrating a collaborator's code that he had been actively modifying.

4. **Introduced the license change in the same commit.** Deleted GPLv3, replaced with MIT + Commons Clause. The FSF considers this "source-available," not open source. The restriction on commercial use could have limited independent security auditors and tools. Verified by GitHub API file diffs.

5. **Authored the inadequate mitigation.** PR #18 (March 2022) added a 32-bit reseed that left Mk4/Q/Mk5 at ~72 bits, 56 bits below the 128-bit target. The reseed truncated 40 bytes of secure-element output to 4 bytes. The person who introduced the vulnerability also wrote the fix that left users still below the security threshold. Verified by GitHub API PR metadata.

6. **The one commit that needed signing was the one that was not signed.** Gray signed his libngu commits. switck signed their commits using Gray's key. But the firmware commit that integrated the vulnerable library, changed the license, and shipped to production was unsigned.

---

## Sources

- Block Engineering root-cause analysis: https://engineering.block.xyz/blog/predictable-rng-fallback-and-32-bit-reseed-in-coldcard-firmware
- 808bits operational analysis: https://808bits.com/articles/coldcard-entropy-failure-lessons/
- GitHub API: commit b18723dd: https://api.github.com/repos/Coldcard/firmware/commits/b18723dd
- GitHub commit page: https://github.com/Coldcard/firmware/commit/b18723dd
- GitHub API: doc-hex profile: https://api.github.com/users/doc-hex
- GitHub API: doc-hex GPG keys: https://api.github.com/users/doc-hex/gpg_keys
- GitHub API: switck profile: https://api.github.com/users/switck
- GitHub API: switck GPG keys (empty): https://api.github.com/users/switck/gpg_keys
- GitHub API: switck SSH keys (empty): https://api.github.com/users/switck/keys
- GitHub API: libngu repo: https://api.github.com/repos/switck/libngu
- GitHub API: libngu commits by doc-hex: https://api.github.com/repos/switck/libngu/commits?author=doc-hex
- GitHub API: libngu PR #17: https://api.github.com/repos/switck/libngu/pulls/17
- GitHub API: libngu PR #18: https://api.github.com/repos/switck/libngu/pulls/18
- GitHub API: coinkite/libngu fork: https://api.github.com/repos/coinkite/libngu
- GitHub API: switck/firmware fork: https://api.github.com/repos/switck/firmware
- GitHub API: switck/firmware commits: https://api.github.com/repos/switck/firmware/commits
- GitHub API: peter-conalgo profile: https://api.github.com/users/peter-conalgo
- GitHub API: Coldcard/.github (Not Found): https://api.github.com/repos/Coldcard/firmware/contents/.github
- GitHub: conftest.py: https://github.com/Coldcard/firmware/blob/b18723dd/testing/conftest.py
- GitHub: test_drv_entro.py: https://github.com/Coldcard/firmware/blob/b18723dd/testing/test_drv_entro.py
- GitHub: COPYING-CC: https://github.com/Coldcard/firmware/blob/master/COPYING-CC
- Parent commit .gitmodules: https://raw.githubusercontent.com/Coldcard/firmware/f456a88/.gitmodules
- GPG signature verification: switck commit `f7711c5522` contains key `A2DCD558C2BE5D7C` in raw PGP packet; doc-hex commit `61ffc74af1` contains key `F0E6CC6AFC16CF7B` in raw PGP packet

👀 #nevent1q…em39

2026-08-04T18:31:58Z

👀

quoting
nevent1q…em39
Oh shit… from Kimi K3. Smoking gun. Looks like doc-hex was also responsible for the code that added entropy on newer devices, but STILL fell below a reasonable threshold. This is super sketchy.

—————-
# Peter D. Gray and the Coldcard Entropy Incident

## Executive summary

Peter D. Gray, Coinkite engineer (GitHub: `doc-hex`, email: `peter@conalgo.com`), authored the commit that introduced the Coldcard entropy vulnerability and later authored the inadequate mitigation. On March 1, 2021, Gray pushed commit `b18723dd` directly to Coldcard's firmware master branch: a 120-file, 5,488-line change that replaced the hardware TRNG seed generation path with a call through the `libngu` library, which silently resolved to a non-cryptographic software PRNG called Yasmarang. The commit had no pull request, no code review, no CI pipeline, and no GPG signature despite Gray possessing a valid signing key. The same commit deleted the GPLv3 license and replaced it with MIT plus the Commons Clause.

Gray was not a passive consumer of libngu. He was an active contributor with 19 commits to the library starting February 10, 2021, 19 days before the integration commit. The library's primary author, `switck`, had no independent GPG key and signed their own commits using Gray's GPG key (`A2DCD558C2BE5D7C`), verified by raw PGP signature packet inspection. The two were collaborators: Gray was pushing to switck's firmware fork by January 2021, and Coinkite maintained their own fork of switck's library.

Thirteen months after introducing the vulnerability, Gray authored PR #18 to libngu (March 11, 2022): a 32-bit reseed function that brought newer devices (Mk4, Q, Mk5) from ~40 bits of effective entropy to ~72 bits. The design target was 128 bits. The person who introduced the vulnerability also wrote the fix that left users still below the security threshold.

The bug survived five years until July 30, 2026, when an attacker drained approximately 1,367 BTC ($88.6 million) from 4,500+ addresses. The attacker never touched a single device.

---

## Gray's relationship with libngu and switck

### The GPG key

Gray registered a GPG key on his GitHub account:

| Property | Value | Source |
|---|---|---|
| Primary key ID | `A2DCD558C2BE5D7C` | [GitHub API: users/doc-hex/gpg_keys](https://api.github.com/users/doc-hex/gpg_keys) |
| Subkey ID | `F0E6CC6AFC16CF7B` | [GitHub API: users/doc-hex/gpg_keys](https://api.github.com/users/doc-hex/gpg_keys) |
| Created | July 17, 2018 | GitHub API |
| Expired | May 28, 2023 | GitHub API |

switck has no GPG key registered on GitHub ([API returns empty](https://api.github.com/users/switck/gpg_keys)), no SSH keys ([API returns empty](https://api.github.com/users/switck/keys)), and uses only GitHub's noreply email. Location listed as "Cyberspace."

Despite switck having no registered key, switck's commits to libngu are GPG-signed. GitHub marks them `verified=False, reason=unknown_key` because the signing key is not registered to switck's account. Raw inspection of the PGP signature packets reveals the key ID:

- switck commit `f7711c5522` (2024-03-30): raw PGP packet contains `A2DCD558C2BE5D7C`. This is Gray's primary key.
- doc-hex commit `61ffc74af1` (2022-03-11): raw PGP packet contains `F0E6CC6AFC16CF7B`. This is Gray's subkey.

Both key IDs belong to the same GPG key registered to doc-hex. switck does not have their own GPG key. switck is signing commits with Peter Gray's key.

### The collaboration timeline

| Date | Event | Evidence |
|---|---|---|
| 2020-08-07 | switck creates GitHub account | [GitHub API: users/switck](https://api.github.com/users/switck) |
| 2020-10-15 | switck creates libngu repo, forks Coldcard/firmware, forks micropython | [GitHub API: repos/switck/libngu](https://api.github.com/repos/switck/libngu) |
| 2021-01-08 | Gray commits appear in switck's firmware fork (release signing, bug fixes) | [GitHub API: repos/switck/firmware/commits](https://api.github.com/repos/switck/firmware/commits) — commits by "Peter D. Gray" |
| 2021-02-10 | Coinkite forks switck's libngu. Gray makes first commit to libngu same day. | [GitHub API: repos/coinkite/libngu](https://api.github.com/repos/coinkite/libngu) (created 2021-02-10), [GitHub API: libngu commits by doc-hex](https://api.github.com/repos/switck/libngu/commits?author=doc-hex) |
| 2021-02-10 to 02-26 | Gray makes multiple commits to libngu (AES clone, env var tweaks, bip39 bugfix) | [GitHub API: libngu commits by doc-hex](https://api.github.com/repos/switck/libngu/commits?author=doc-hex) |

Gray had 19 total commits to libngu. He knew the library he was integrating.

### The `peter-conalgo` identity

The parent commit's `.gitmodules` referenced `github.com/peter-conalgo/trezor-crypto.git` as the `external/crypto` submodule. The GitHub account `peter-conalgo` was created April 22, 2021. The account name is "peter," no other identity. Gray's email is `peter@conalgo.com`. The commit removed this submodule (Gray's personal trezor-crypto fork) and replaced it with switck's libngu.

Sources: [GitHub API: users/peter-conalgo](https://api.github.com/users/peter-conalgo), [parent commit .gitmodules](https://raw.githubusercontent.com/Coldcard/firmware/f456a88/.gitmodules)

---

## The fateful commit: `b18723dd`

**Repository:** `github.com/Coldcard/firmware`
**SHA:** `b18723dd`
**Author:** Peter D. Gray (`peter@conalgo.com`)
**Date:** March 1, 2021, 14:03:03 UTC
**Message:** "First pass w/ libNgU"
**Parent:** `f456a88` (single parent: direct push, not a merge commit)
**Files changed:** 120
**Lines:** +2,766 / -2,722
**Pull request:** None
**Code review:** None
**CI:** None (no `.github` directory in repo)
**GPG signature:** Unsigned, despite Gray having a valid key (created 2018, valid through May 2023)

Sources: [GitHub API: commits/b18723dd](https://api.github.com/repos/Coldcard/firmware/commits/b18723dd), [GitHub commit page](https://github.com/Coldcard/firmware/commit/b18723dd), [GitHub API: contents/.github](https://api.github.com/repos/Coldcard/firmware/contents/.github) (Not Found)

### What Gray changed

| File | Change | Significance |
|---|---|---|
| `shared/random.py` | Changed `from ckcc import rng` to `import ngu`; set `bytes = ngu.random.bytes`. Comment still says "crypto-quality rng." | Call path that resolved to Yasmarang instead of the hardware TRNG |
| `shared/seed.py` | Changed `make_new_wallet()` from `rng_bytes(seed)` to `random.bytes(32)`. Changed `import tcc` to `import ngu` throughout. Changed `tcc.sha256(seed)` to `ngu.hash.sha256s(seed)`. | Seed generation function. Old path reached STM32 hardware TRNG. New path reached Yasmarang. |
| `shared/drv_entro.py` | Changed `import stash, tcc, hmac, chains` to `import stash, ngu, chains` | BIP-85 entropy derivation path migrated |
| `COPYING` | Deleted (674 lines, GPLv3) | Removed GPLv3 license |
| `COPYING-CC` | Added (MIT + Commons Clause) | Replaced GPLv3 with source-available license restricting commercial use |
| `.gitmodules` | Removed `external/crypto` (`peter-conalgo/trezor-crypto`), removed `external/modcryptocurrency`, added `external/libngu` (`switck/libngu`) | Removed Gray's personal trezor-crypto fork, added switck's libngu |

Sources: [GitHub API file diffs from commit b18723dd](https://api.github.com/repos/Coldcard/firmware/commits/b18723dd)

### The specific seed generation change

Before (firmware v3.2.2):
```python
seed = bytearray(32)
rng_bytes(seed) # reaches ckcc.rng_bytes -> STM32 hardware TRNG
```

After (commit b18723dd, shipped in v4.0.0):
```python
seed = random.bytes(32) # reaches ngu.random.bytes -> libngu -> rng_get() -> Yasmarang
```

Source: [Block Engineering analysis](https://engineering.block.xyz/blog/predictable-rng-fallback-and-32-bit-reseed-in-coldcard-firmware), section 5

### How the bug worked

The bug required two pieces: a faulty preprocessor check in libngu (switck's code) and Gray's seed generation change that routed through it (Gray's code).

**libngu's faulty check** (switck's code):
```c
#ifndef MICROPY_HW_ENABLE_RNG
#error "get a HW TRNG plz"
#endif
```
`#ifndef` tests whether the macro exists, not whether it is enabled. Coldcard's board config defines `MICROPY_HW_ENABLE_RNG` as `0`. The macro exists. Its value is zero. The check passes. The build links Yasmarang.

**Coldcard's board config** (Gray's code):
```c
#define MICROPY_HW_ENABLE_RNG (0)
```
Coinkite disabled MicroPython's built-in RNG because they provide their own wrapper. But Gray's seed generation change called `ngu.random.bytes` instead of `ckcc.rng_bytes`, routing through the broken libngu path.

Yasmarang was seeded from the MCU's 96-bit unique device identifier (factory metadata, not a secret), the SysTick counter (~80,000 possible values on Mk2/Mk3), and RTC registers (correlated timing values). None are cryptographic entropy sources. Collected once. Never reseeded.

Effective entropy: ~40 bits on Mk2/Mk3 (design target: 128 bits). A 40-bit keyspace is searchable on commodity hardware.

Sources: [Block Engineering analysis](https://engineering.block.xyz/blog/predictable-rng-fallback-and-32-bit-reseed-in-coldcard-firmware), sections 1-4

---

## The reseed commit: PR #18

Thirteen months after introducing the vulnerability, Gray authored a mitigation.

**Repository:** `github.com/switck/libngu`
**PR:** #18
**Title:** "Add reseed function to ngu.random module"
**Author:** doc-hex (Peter D. Gray)
**Submitted from:** `coinkite/libngu` fork
**Opened:** March 11, 2022
**Merged by:** switck on March 15, 2022

Source: [GitHub API: repos/switck/libngu/pulls/18](https://api.github.com/repos/switck/libngu/pulls/18)

### What the reseed did

```python
a = callgate.read_rng(1) # 32 bytes from SE1
b = callgate.read_rng(2) # 8 bytes from SE2
n = ngu.hash.sha256d(a + b)
n, = ustruct.unpack('I', n[0:4]) # keeps only 4 bytes
ngu.random.reseed(n) # replaces one 32-bit state word
```

The reseed hashes 40 bytes of secure-element output with SHA256d, then truncates to 4 bytes. It replaces one 32-bit Yasmarang state word. Maximum 2^32 distinct reseed values.

### Why the reseed was inadequate

| Property | Value |
|---|---|
| Secure element output | 40 bytes |
| Bytes retained after SHA256d | 4 (ustruct unpack 'I') |
| Maximum distinct reseed values | 2^32 |
| Effective entropy after reseed (Mk4/Q/Mk5) | ~72 bits |
| Design target | 128 bits |
| Gap | 56 bits below target |

The reseed function itself is trivial: `yasmarang_pad = mp_obj_get_int_truncated(arg)`. It does not initialize a cryptographic DRBG. It does not reset other state words. It does not provide periodic reseeding or prediction resistance.

The secure element firmware that provides the reseed entropy is closed source. `shared/callgate.py` is a thin wrapper around `ckcc.gate()` calls. The 72-bit figure rests on trust in a closed system that cannot be independently audited from outside the chip.

Source: [Block Engineering analysis](https://engineering.block.xyz/blog/predictable-rng-fallback-and-32-bit-reseed-in-coldcard-firmware), section 6

### The same key signed both commits

Gray's commits to libngu, including the reseed PR, are signed with his subkey `F0E6CC6AFC16CF7B`, verified by raw PGP packet inspection. switck's commits are signed with Gray's primary key `A2DCD558C2BE5D7C`. The same GPG key is used across both identities.

The fateful firmware commit `b18723dd` was the one commit Gray did not sign.

---

## The test failures

### What the test suite looked like at the time of the commit

| Issue | Evidence | Source |
|---|---|---|
| Test RNG deliberately seeded | `conftest.py` line 13: `random.seed(42)` | [GitHub: testing/conftest.py](https://github.com/Coldcard/firmware/blob/b18723dd/testing/conftest.py) |
| Only assertion on seed generation | `shared/seed.py`: `assert len(set(seed)) > 4` with comment `# TRNG failure` | GitHub API file diff |
| Entropy test tests derivation, not generation | `testing/test_drv_entro.py` tests BIP-85 derivation from a hardcoded XPRV | [GitHub: testing/test_drv_entro.py](https://github.com/Coldcard/firmware/blob/b18723dd/testing/test_drv_entro.py) |
| No end-to-end path test | No test generates a seed with known entropy input and verifies output | Full test directory inspection (18 test files) |
| No CI/CD | No `.github` directory | [GitHub API: contents/.github](https://api.github.com/repos/Coldcard/firmware/contents/.github) (Not Found) |

The test suite assumed the RNG worked. It never verified it. A seed with 40 bits of real entropy still expands into well-distributed, unique-looking addresses. No statistical test run against the output can distinguish "unpredictable" from "deterministic but unexamined."

The hardware TRNG code existed in every affected binary. It was reviewed. It was intact. It was never called from the seed generation path. Block Engineering's analysis: "reviews did not verify end-to-end symbol resolution and call reachability." Presence was mistaken for function.

Sources: [Block Engineering analysis](https://engineering.block.xyz/blog/predictable-rng-fallback-and-32-bit-reseed-in-coldcard-firmware), [808bits analysis](https://808bits.com/articles/coldcard-entropy-failure-lessons/)

---

## Timeline of Gray's involvement

| Date | Action | Evidence |
|---|---|---|
| 2018-07-17 | Gray creates GPG key `A2DCD558C2BE5D7C` | [GitHub API: users/doc-hex/gpg_keys](https://api.github.com/users/doc-hex/gpg_keys) |
| 2021-01-08 | Gray commits appear in switck's firmware fork | [GitHub API: repos/switck/firmware/commits](https://api.github.com/repos/switck/firmware/commits) |
| 2021-02-10 | Coinkite forks switck's libngu. Gray makes first commit to libngu. | [GitHub API: repos/coinkite/libngu](https://api.github.com/repos/coinkite/libngu), [GitHub API: libngu commits by doc-hex](https://api.github.com/repos/switck/libngu/commits?author=doc-hex) |
| 2021-02-10 to 02-26 | Gray makes multiple commits to libngu | [GitHub API: libngu commits by doc-hex](https://api.github.com/repos/switck/libngu/commits?author=doc-hex) |
| **2021-03-01** | **Gray pushes `b18723dd` to Coldcard/firmware master. No PR, no review, no CI, no GPG signature. Changes seed generation to route through libngu (Yasmarang). Deletes GPLv3, replaces with MIT + Commons Clause.** | [GitHub API: commits/b18723dd](https://api.github.com/repos/Coldcard/firmware/commits/b18723dd) |
| 2021-03-02 to 03-09 | Gray continues committing to libngu | [GitHub API: libngu commits by doc-hex](https://api.github.com/repos/switck/libngu/commits?author=doc-hex) |
| 2021-03-17 | Firmware v4.0.0 ships containing the vulnerability | [Block Engineering analysis](https://engineering.block.xyz/blog/predictable-rng-fallback-and-32-bit-reseed-in-coldcard-firmware), section 5 |
| 2022-01-12 | Gray opens PR #17 to libngu (hardware accelerated SHA256) from `coinkite/libngu` | [GitHub API: repos/switck/libngu/pulls/17](https://api.github.com/repos/switck/libngu/pulls/17) |
| **2022-03-11** | **Gray opens PR #18 to libngu: 32-bit reseed function** | [GitHub API: repos/switck/libngu/pulls/18](https://api.github.com/repos/switck/libngu/pulls/18) |
| 2022-03-15 | switck merges PR #18 | [GitHub API: repos/switck/libngu/pulls/18](https://api.github.com/repos/switck/libngu/pulls/18) |
| 2023-05-28 | Gray's GPG key expires | [GitHub API: users/doc-hex/gpg_keys](https://api.github.com/users/doc-hex/gpg_keys) |
| **2026-07-30** | **Attacker drains ~1,367 BTC ($88.6M) from 4,500+ addresses** | [808bits](https://808bits.com/articles/coldcard-entropy-failure-lessons/) |

---

## Blame allocation: Peter D. Gray

1. **Authored the vulnerability.** Commit `b18723dd` changed seed generation from the hardware TRNG path to libngu, routing through Yasmarang. Verified by GitHub API commit metadata.

2. **Shipped it with no process.** Direct push to master. No pull request. No code review. No CI. No GPG signature despite having a valid key. A 120-file, 5,488-line change to a system protecting billions of dollars, pushed with the message "First pass w/ libNgU." Verified by GitHub commit page (single parent, no PR, no review elements, verification: unsigned).

3. **Knew the library.** 19 commits to libngu starting 19 days before the integration. Coinkite maintained their own fork. He was not importing an unknown dependency. He was integrating a collaborator's code that he had been actively modifying.

4. **Introduced the license change in the same commit.** Deleted GPLv3, replaced with MIT + Commons Clause. The FSF considers this "source-available," not open source. The restriction on commercial use could have limited independent security auditors and tools. Verified by GitHub API file diffs.

5. **Authored the inadequate mitigation.** PR #18 (March 2022) added a 32-bit reseed that left Mk4/Q/Mk5 at ~72 bits, 56 bits below the 128-bit target. The reseed truncated 40 bytes of secure-element output to 4 bytes. The person who introduced the vulnerability also wrote the fix that left users still below the security threshold. Verified by GitHub API PR metadata.

6. **The one commit that needed signing was the one that was not signed.** Gray signed his libngu commits. switck signed their commits using Gray's key. But the firmware commit that integrated the vulnerable library, changed the license, and shipped to production was unsigned.

---

## Sources

- Block Engineering root-cause analysis: https://engineering.block.xyz/blog/predictable-rng-fallback-and-32-bit-reseed-in-coldcard-firmware
- 808bits operational analysis: https://808bits.com/articles/coldcard-entropy-failure-lessons/
- GitHub API: commit b18723dd: https://api.github.com/repos/Coldcard/firmware/commits/b18723dd
- GitHub commit page: https://github.com/Coldcard/firmware/commit/b18723dd
- GitHub API: doc-hex profile: https://api.github.com/users/doc-hex
- GitHub API: doc-hex GPG keys: https://api.github.com/users/doc-hex/gpg_keys
- GitHub API: switck profile: https://api.github.com/users/switck
- GitHub API: switck GPG keys (empty): https://api.github.com/users/switck/gpg_keys
- GitHub API: switck SSH keys (empty): https://api.github.com/users/switck/keys
- GitHub API: libngu repo: https://api.github.com/repos/switck/libngu
- GitHub API: libngu commits by doc-hex: https://api.github.com/repos/switck/libngu/commits?author=doc-hex
- GitHub API: libngu PR #17: https://api.github.com/repos/switck/libngu/pulls/17
- GitHub API: libngu PR #18: https://api.github.com/repos/switck/libngu/pulls/18
- GitHub API: coinkite/libngu fork: https://api.github.com/repos/coinkite/libngu
- GitHub API: switck/firmware fork: https://api.github.com/repos/switck/firmware
- GitHub API: switck/firmware commits: https://api.github.com/repos/switck/firmware/commits
- GitHub API: peter-conalgo profile: https://api.github.com/users/peter-conalgo
- GitHub API: Coldcard/.github (Not Found): https://api.github.com/repos/Coldcard/firmware/contents/.github
- GitHub: conftest.py: https://github.com/Coldcard/firmware/blob/b18723dd/testing/conftest.py
- GitHub: test_drv_entro.py: https://github.com/Coldcard/firmware/blob/b18723dd/testing/test_drv_entro.py
- GitHub: COPYING-CC: https://github.com/Coldcard/firmware/blob/master/COPYING-CC
- Parent commit .gitmodules: https://raw.githubusercontent.com/Coldcard/firmware/f456a88/.gitmodules
- GPG signature verification: switck commit `f7711c5522` contains key `A2DCD558C2BE5D7C` in raw PGP packet; doc-hex commit `61ffc74af1` contains key `F0E6CC6AFC16CF7B` in raw PGP packet

Oh shit… from Kimi K3. Smoking gun. Looks like doc-hex was also ...

2026-08-04T18:31:03Z

In reply to nevent1q…nc9d
_________________________

Oh shit… from Kimi K3. Smoking gun. Looks like doc-hex was also responsible for the code that added entropy on newer devices, but STILL fell below a reasonable threshold. This is super sketchy.

—————-
# Peter D. Gray and the Coldcard Entropy Incident

## Executive summary

Peter D. Gray, Coinkite engineer (GitHub: `doc-hex`, email: `peter@conalgo.com`), authored the commit that introduced the Coldcard entropy vulnerability and later authored the inadequate mitigation. On March 1, 2021, Gray pushed commit `b18723dd` directly to Coldcard's firmware master branch: a 120-file, 5,488-line change that replaced the hardware TRNG seed generation path with a call through the `libngu` library, which silently resolved to a non-cryptographic software PRNG called Yasmarang. The commit had no pull request, no code review, no CI pipeline, and no GPG signature despite Gray possessing a valid signing key. The same commit deleted the GPLv3 license and replaced it with MIT plus the Commons Clause.

Gray was not a passive consumer of libngu. He was an active contributor with 19 commits to the library starting February 10, 2021, 19 days before the integration commit. The library's primary author, `switck`, had no independent GPG key and signed their own commits using Gray's GPG key (`A2DCD558C2BE5D7C`), verified by raw PGP signature packet inspection. The two were collaborators: Gray was pushing to switck's firmware fork by January 2021, and Coinkite maintained their own fork of switck's library.

Thirteen months after introducing the vulnerability, Gray authored PR #18 to libngu (March 11, 2022): a 32-bit reseed function that brought newer devices (Mk4, Q, Mk5) from ~40 bits of effective entropy to ~72 bits. The design target was 128 bits. The person who introduced the vulnerability also wrote the fix that left users still below the security threshold.

The bug survived five years until July 30, 2026, when an attacker drained approximately 1,367 BTC ($88.6 million) from 4,500+ addresses. The attacker never touched a single device.

---

## Gray's relationship with libngu and switck

### The GPG key

Gray registered a GPG key on his GitHub account:

| Property | Value | Source |
|---|---|---|
| Primary key ID | `A2DCD558C2BE5D7C` | [GitHub API: users/doc-hex/gpg_keys](https://api.github.com/users/doc-hex/gpg_keys) |
| Subkey ID | `F0E6CC6AFC16CF7B` | [GitHub API: users/doc-hex/gpg_keys](https://api.github.com/users/doc-hex/gpg_keys) |
| Created | July 17, 2018 | GitHub API |
| Expired | May 28, 2023 | GitHub API |

switck has no GPG key registered on GitHub ([API returns empty](https://api.github.com/users/switck/gpg_keys)), no SSH keys ([API returns empty](https://api.github.com/users/switck/keys)), and uses only GitHub's noreply email. Location listed as "Cyberspace."

Despite switck having no registered key, switck's commits to libngu are GPG-signed. GitHub marks them `verified=False, reason=unknown_key` because the signing key is not registered to switck's account. Raw inspection of the PGP signature packets reveals the key ID:

- switck commit `f7711c5522` (2024-03-30): raw PGP packet contains `A2DCD558C2BE5D7C`. This is Gray's primary key.
- doc-hex commit `61ffc74af1` (2022-03-11): raw PGP packet contains `F0E6CC6AFC16CF7B`. This is Gray's subkey.

Both key IDs belong to the same GPG key registered to doc-hex. switck does not have their own GPG key. switck is signing commits with Peter Gray's key.

### The collaboration timeline

| Date | Event | Evidence |
|---|---|---|
| 2020-08-07 | switck creates GitHub account | [GitHub API: users/switck](https://api.github.com/users/switck) |
| 2020-10-15 | switck creates libngu repo, forks Coldcard/firmware, forks micropython | [GitHub API: repos/switck/libngu](https://api.github.com/repos/switck/libngu) |
| 2021-01-08 | Gray commits appear in switck's firmware fork (release signing, bug fixes) | [GitHub API: repos/switck/firmware/commits](https://api.github.com/repos/switck/firmware/commits) — commits by "Peter D. Gray" |
| 2021-02-10 | Coinkite forks switck's libngu. Gray makes first commit to libngu same day. | [GitHub API: repos/coinkite/libngu](https://api.github.com/repos/coinkite/libngu) (created 2021-02-10), [GitHub API: libngu commits by doc-hex](https://api.github.com/repos/switck/libngu/commits?author=doc-hex) |
| 2021-02-10 to 02-26 | Gray makes multiple commits to libngu (AES clone, env var tweaks, bip39 bugfix) | [GitHub API: libngu commits by doc-hex](https://api.github.com/repos/switck/libngu/commits?author=doc-hex) |

Gray had 19 total commits to libngu. He knew the library he was integrating.

### The `peter-conalgo` identity

The parent commit's `.gitmodules` referenced `github.com/peter-conalgo/trezor-crypto.git` as the `external/crypto` submodule. The GitHub account `peter-conalgo` was created April 22, 2021. The account name is "peter," no other identity. Gray's email is `peter@conalgo.com`. The commit removed this submodule (Gray's personal trezor-crypto fork) and replaced it with switck's libngu.

Sources: [GitHub API: users/peter-conalgo](https://api.github.com/users/peter-conalgo), [parent commit .gitmodules](https://raw.githubusercontent.com/Coldcard/firmware/f456a88/.gitmodules)

---

## The fateful commit: `b18723dd`

**Repository:** `github.com/Coldcard/firmware`
**SHA:** `b18723dd`
**Author:** Peter D. Gray (`peter@conalgo.com`)
**Date:** March 1, 2021, 14:03:03 UTC
**Message:** "First pass w/ libNgU"
**Parent:** `f456a88` (single parent: direct push, not a merge commit)
**Files changed:** 120
**Lines:** +2,766 / -2,722
**Pull request:** None
**Code review:** None
**CI:** None (no `.github` directory in repo)
**GPG signature:** Unsigned, despite Gray having a valid key (created 2018, valid through May 2023)

Sources: [GitHub API: commits/b18723dd](https://api.github.com/repos/Coldcard/firmware/commits/b18723dd), [GitHub commit page](https://github.com/Coldcard/firmware/commit/b18723dd), [GitHub API: contents/.github](https://api.github.com/repos/Coldcard/firmware/contents/.github) (Not Found)

### What Gray changed

| File | Change | Significance |
|---|---|---|
| `shared/random.py` | Changed `from ckcc import rng` to `import ngu`; set `bytes = ngu.random.bytes`. Comment still says "crypto-quality rng." | Call path that resolved to Yasmarang instead of the hardware TRNG |
| `shared/seed.py` | Changed `make_new_wallet()` from `rng_bytes(seed)` to `random.bytes(32)`. Changed `import tcc` to `import ngu` throughout. Changed `tcc.sha256(seed)` to `ngu.hash.sha256s(seed)`. | Seed generation function. Old path reached STM32 hardware TRNG. New path reached Yasmarang. |
| `shared/drv_entro.py` | Changed `import stash, tcc, hmac, chains` to `import stash, ngu, chains` | BIP-85 entropy derivation path migrated |
| `COPYING` | Deleted (674 lines, GPLv3) | Removed GPLv3 license |
| `COPYING-CC` | Added (MIT + Commons Clause) | Replaced GPLv3 with source-available license restricting commercial use |
| `.gitmodules` | Removed `external/crypto` (`peter-conalgo/trezor-crypto`), removed `external/modcryptocurrency`, added `external/libngu` (`switck/libngu`) | Removed Gray's personal trezor-crypto fork, added switck's libngu |

Sources: [GitHub API file diffs from commit b18723dd](https://api.github.com/repos/Coldcard/firmware/commits/b18723dd)

### The specific seed generation change

Before (firmware v3.2.2):
```python
seed = bytearray(32)
rng_bytes(seed) # reaches ckcc.rng_bytes -> STM32 hardware TRNG
```

After (commit b18723dd, shipped in v4.0.0):
```python
seed = random.bytes(32) # reaches ngu.random.bytes -> libngu -> rng_get() -> Yasmarang
```

Source: [Block Engineering analysis](https://engineering.block.xyz/blog/predictable-rng-fallback-and-32-bit-reseed-in-coldcard-firmware), section 5

### How the bug worked

The bug required two pieces: a faulty preprocessor check in libngu (switck's code) and Gray's seed generation change that routed through it (Gray's code).

**libngu's faulty check** (switck's code):
```c
#ifndef MICROPY_HW_ENABLE_RNG
#error "get a HW TRNG plz"
#endif
```
`#ifndef` tests whether the macro exists, not whether it is enabled. Coldcard's board config defines `MICROPY_HW_ENABLE_RNG` as `0`. The macro exists. Its value is zero. The check passes. The build links Yasmarang.

**Coldcard's board config** (Gray's code):
```c
#define MICROPY_HW_ENABLE_RNG (0)
```
Coinkite disabled MicroPython's built-in RNG because they provide their own wrapper. But Gray's seed generation change called `ngu.random.bytes` instead of `ckcc.rng_bytes`, routing through the broken libngu path.

Yasmarang was seeded from the MCU's 96-bit unique device identifier (factory metadata, not a secret), the SysTick counter (~80,000 possible values on Mk2/Mk3), and RTC registers (correlated timing values). None are cryptographic entropy sources. Collected once. Never reseeded.

Effective entropy: ~40 bits on Mk2/Mk3 (design target: 128 bits). A 40-bit keyspace is searchable on commodity hardware.

Sources: [Block Engineering analysis](https://engineering.block.xyz/blog/predictable-rng-fallback-and-32-bit-reseed-in-coldcard-firmware), sections 1-4

---

## The reseed commit: PR #18

Thirteen months after introducing the vulnerability, Gray authored a mitigation.

**Repository:** `github.com/switck/libngu`
**PR:** #18
**Title:** "Add reseed function to ngu.random module"
**Author:** doc-hex (Peter D. Gray)
**Submitted from:** `coinkite/libngu` fork
**Opened:** March 11, 2022
**Merged by:** switck on March 15, 2022

Source: [GitHub API: repos/switck/libngu/pulls/18](https://api.github.com/repos/switck/libngu/pulls/18)

### What the reseed did

```python
a = callgate.read_rng(1) # 32 bytes from SE1
b = callgate.read_rng(2) # 8 bytes from SE2
n = ngu.hash.sha256d(a + b)
n, = ustruct.unpack('I', n[0:4]) # keeps only 4 bytes
ngu.random.reseed(n) # replaces one 32-bit state word
```

The reseed hashes 40 bytes of secure-element output with SHA256d, then truncates to 4 bytes. It replaces one 32-bit Yasmarang state word. Maximum 2^32 distinct reseed values.

### Why the reseed was inadequate

| Property | Value |
|---|---|
| Secure element output | 40 bytes |
| Bytes retained after SHA256d | 4 (ustruct unpack 'I') |
| Maximum distinct reseed values | 2^32 |
| Effective entropy after reseed (Mk4/Q/Mk5) | ~72 bits |
| Design target | 128 bits |
| Gap | 56 bits below target |

The reseed function itself is trivial: `yasmarang_pad = mp_obj_get_int_truncated(arg)`. It does not initialize a cryptographic DRBG. It does not reset other state words. It does not provide periodic reseeding or prediction resistance.

The secure element firmware that provides the reseed entropy is closed source. `shared/callgate.py` is a thin wrapper around `ckcc.gate()` calls. The 72-bit figure rests on trust in a closed system that cannot be independently audited from outside the chip.

Source: [Block Engineering analysis](https://engineering.block.xyz/blog/predictable-rng-fallback-and-32-bit-reseed-in-coldcard-firmware), section 6

### The same key signed both commits

Gray's commits to libngu, including the reseed PR, are signed with his subkey `F0E6CC6AFC16CF7B`, verified by raw PGP packet inspection. switck's commits are signed with Gray's primary key `A2DCD558C2BE5D7C`. The same GPG key is used across both identities.

The fateful firmware commit `b18723dd` was the one commit Gray did not sign.

---

## The test failures

### What the test suite looked like at the time of the commit

| Issue | Evidence | Source |
|---|---|---|
| Test RNG deliberately seeded | `conftest.py` line 13: `random.seed(42)` | [GitHub: testing/conftest.py](https://github.com/Coldcard/firmware/blob/b18723dd/testing/conftest.py) |
| Only assertion on seed generation | `shared/seed.py`: `assert len(set(seed)) > 4` with comment `# TRNG failure` | GitHub API file diff |
| Entropy test tests derivation, not generation | `testing/test_drv_entro.py` tests BIP-85 derivation from a hardcoded XPRV | [GitHub: testing/test_drv_entro.py](https://github.com/Coldcard/firmware/blob/b18723dd/testing/test_drv_entro.py) |
| No end-to-end path test | No test generates a seed with known entropy input and verifies output | Full test directory inspection (18 test files) |
| No CI/CD | No `.github` directory | [GitHub API: contents/.github](https://api.github.com/repos/Coldcard/firmware/contents/.github) (Not Found) |

The test suite assumed the RNG worked. It never verified it. A seed with 40 bits of real entropy still expands into well-distributed, unique-looking addresses. No statistical test run against the output can distinguish "unpredictable" from "deterministic but unexamined."

The hardware TRNG code existed in every affected binary. It was reviewed. It was intact. It was never called from the seed generation path. Block Engineering's analysis: "reviews did not verify end-to-end symbol resolution and call reachability." Presence was mistaken for function.

Sources: [Block Engineering analysis](https://engineering.block.xyz/blog/predictable-rng-fallback-and-32-bit-reseed-in-coldcard-firmware), [808bits analysis](https://808bits.com/articles/coldcard-entropy-failure-lessons/)

---

## Timeline of Gray's involvement

| Date | Action | Evidence |
|---|---|---|
| 2018-07-17 | Gray creates GPG key `A2DCD558C2BE5D7C` | [GitHub API: users/doc-hex/gpg_keys](https://api.github.com/users/doc-hex/gpg_keys) |
| 2021-01-08 | Gray commits appear in switck's firmware fork | [GitHub API: repos/switck/firmware/commits](https://api.github.com/repos/switck/firmware/commits) |
| 2021-02-10 | Coinkite forks switck's libngu. Gray makes first commit to libngu. | [GitHub API: repos/coinkite/libngu](https://api.github.com/repos/coinkite/libngu), [GitHub API: libngu commits by doc-hex](https://api.github.com/repos/switck/libngu/commits?author=doc-hex) |
| 2021-02-10 to 02-26 | Gray makes multiple commits to libngu | [GitHub API: libngu commits by doc-hex](https://api.github.com/repos/switck/libngu/commits?author=doc-hex) |
| **2021-03-01** | **Gray pushes `b18723dd` to Coldcard/firmware master. No PR, no review, no CI, no GPG signature. Changes seed generation to route through libngu (Yasmarang). Deletes GPLv3, replaces with MIT + Commons Clause.** | [GitHub API: commits/b18723dd](https://api.github.com/repos/Coldcard/firmware/commits/b18723dd) |
| 2021-03-02 to 03-09 | Gray continues committing to libngu | [GitHub API: libngu commits by doc-hex](https://api.github.com/repos/switck/libngu/commits?author=doc-hex) |
| 2021-03-17 | Firmware v4.0.0 ships containing the vulnerability | [Block Engineering analysis](https://engineering.block.xyz/blog/predictable-rng-fallback-and-32-bit-reseed-in-coldcard-firmware), section 5 |
| 2022-01-12 | Gray opens PR #17 to libngu (hardware accelerated SHA256) from `coinkite/libngu` | [GitHub API: repos/switck/libngu/pulls/17](https://api.github.com/repos/switck/libngu/pulls/17) |
| **2022-03-11** | **Gray opens PR #18 to libngu: 32-bit reseed function** | [GitHub API: repos/switck/libngu/pulls/18](https://api.github.com/repos/switck/libngu/pulls/18) |
| 2022-03-15 | switck merges PR #18 | [GitHub API: repos/switck/libngu/pulls/18](https://api.github.com/repos/switck/libngu/pulls/18) |
| 2023-05-28 | Gray's GPG key expires | [GitHub API: users/doc-hex/gpg_keys](https://api.github.com/users/doc-hex/gpg_keys) |
| **2026-07-30** | **Attacker drains ~1,367 BTC ($88.6M) from 4,500+ addresses** | [808bits](https://808bits.com/articles/coldcard-entropy-failure-lessons/) |

---

## Blame allocation: Peter D. Gray

1. **Authored the vulnerability.** Commit `b18723dd` changed seed generation from the hardware TRNG path to libngu, routing through Yasmarang. Verified by GitHub API commit metadata.

2. **Shipped it with no process.** Direct push to master. No pull request. No code review. No CI. No GPG signature despite having a valid key. A 120-file, 5,488-line change to a system protecting billions of dollars, pushed with the message "First pass w/ libNgU." Verified by GitHub commit page (single parent, no PR, no review elements, verification: unsigned).

3. **Knew the library.** 19 commits to libngu starting 19 days before the integration. Coinkite maintained their own fork. He was not importing an unknown dependency. He was integrating a collaborator's code that he had been actively modifying.

4. **Introduced the license change in the same commit.** Deleted GPLv3, replaced with MIT + Commons Clause. The FSF considers this "source-available," not open source. The restriction on commercial use could have limited independent security auditors and tools. Verified by GitHub API file diffs.

5. **Authored the inadequate mitigation.** PR #18 (March 2022) added a 32-bit reseed that left Mk4/Q/Mk5 at ~72 bits, 56 bits below the 128-bit target. The reseed truncated 40 bytes of secure-element output to 4 bytes. The person who introduced the vulnerability also wrote the fix that left users still below the security threshold. Verified by GitHub API PR metadata.

6. **The one commit that needed signing was the one that was not signed.** Gray signed his libngu commits. switck signed their commits using Gray's key. But the firmware commit that integrated the vulnerable library, changed the license, and shipped to production was unsigned.

---

## Sources

- Block Engineering root-cause analysis: https://engineering.block.xyz/blog/predictable-rng-fallback-and-32-bit-reseed-in-coldcard-firmware
- 808bits operational analysis: https://808bits.com/articles/coldcard-entropy-failure-lessons/
- GitHub API: commit b18723dd: https://api.github.com/repos/Coldcard/firmware/commits/b18723dd
- GitHub commit page: https://github.com/Coldcard/firmware/commit/b18723dd
- GitHub API: doc-hex profile: https://api.github.com/users/doc-hex
- GitHub API: doc-hex GPG keys: https://api.github.com/users/doc-hex/gpg_keys
- GitHub API: switck profile: https://api.github.com/users/switck
- GitHub API: switck GPG keys (empty): https://api.github.com/users/switck/gpg_keys
- GitHub API: switck SSH keys (empty): https://api.github.com/users/switck/keys
- GitHub API: libngu repo: https://api.github.com/repos/switck/libngu
- GitHub API: libngu commits by doc-hex: https://api.github.com/repos/switck/libngu/commits?author=doc-hex
- GitHub API: libngu PR #17: https://api.github.com/repos/switck/libngu/pulls/17
- GitHub API: libngu PR #18: https://api.github.com/repos/switck/libngu/pulls/18
- GitHub API: coinkite/libngu fork: https://api.github.com/repos/coinkite/libngu
- GitHub API: switck/firmware fork: https://api.github.com/repos/switck/firmware
- GitHub API: switck/firmware commits: https://api.github.com/repos/switck/firmware/commits
- GitHub API: peter-conalgo profile: https://api.github.com/users/peter-conalgo
- GitHub API: Coldcard/.github (Not Found): https://api.github.com/repos/Coldcard/firmware/contents/.github
- GitHub: conftest.py: https://github.com/Coldcard/firmware/blob/b18723dd/testing/conftest.py
- GitHub: test_drv_entro.py: https://github.com/Coldcard/firmware/blob/b18723dd/testing/test_drv_entro.py
- GitHub: COPYING-CC: https://github.com/Coldcard/firmware/blob/master/COPYING-CC
- Parent commit .gitmodules: https://raw.githubusercontent.com/Coldcard/firmware/f456a88/.gitmodules
- GPG signature verification: switck commit `f7711c5522` contains key `A2DCD558C2BE5D7C` in raw PGP packet; doc-hex commit `61ffc74af1` contains key `F0E6CC6AFC16CF7B` in raw PGP packet

@npub1h8n…rpev @npub1vwy…zugd you may find this interesting ...

2026-08-04T17:58:24Z

In reply to nevent1q…nmzd
_________________________

TheGuySwann (npub1h8n…rpev) Nunyabidness (npub1vwy…zugd) you may find this interesting as folks who are helping drive the conversation around sovereignty - would be curious your feedback/thoughts

Makes sense. I just posted an article with some ideas - ...

2026-08-04T17:17:58Z

In reply to nevent1q…metu
_________________________

Makes sense. I just posted an article with some ideas - brainstorming with Kimi - on the topic. Seems like there are standards we should be pushing for like tracing the execution path through binaries and even showing / attesting to the entropy sources executed during seed generation. All mechanisms that should be thoroughly tested in the codebase.

Obviously this only works for vendors with the code available, but it seems like it would be a significant improvement in traceability and increase the ability of end-users to validate the security claims.

I wrote a brief review about the cultural shift that HAS to ...

2026-08-04T15:26:02Z

I wrote a brief review about the cultural shift that HAS to happen within the bitcoin space to ensure self-custody is successful. The biggest community failure leading up to the ColdCard incident was an inability to recognize the problem - masked by advertising and social reputation. It is quite literally the opposite of “don’t trust, verify” and it is something we should be able to fix as long as we shift our expectations.

quoting
note1qyq…xeqk

A cultural failure: execution-path trust over evaluation, and social reputation over development quality.

On July 30, 2026, someone started emptying Bitcoin wallets that had been dormant for years. No phishing, no malware, no compromised exchange. A five-year-old firmware bug had made the seed phrases guessable, and the attacker derived the private keys offline and swept the first wave of funds before anyone knew there was a problem.

This is not another write-up about the mechanics of the hack. The bug itself is almost boring: one check that tested whether a setting existed instead of whether it was turned on. What should raise eyebrows is that it lived for five years in open, widely-read code, inside the wallet the community trusted most, and nobody caught it. It went unnoticed because self-custody culture rewards the wrong things. It assumes a code path runs because the code is present, and it grades vendors on reputation instead of evidence. Those two habits, execution-path trust over verification and reputation over development practice, are the real vulnerability, and they will keep producing thefts like this one until the community trades trust for proof. What follows is less about Coldcard than about the standard that allowed it, and the one that has to replace it. The article closes with an example draft checklist that turns that standard into concrete questions you can put to any hardware wallet vendor.

Social media has reached for the easy lesson: self-custody is too hard, go back to letting a custodian hold the keys. That the average person recoils from self-custody in the short term is probably unavoidable. If it becomes a long-term trend, that will be because the Bitcoin ecosystem failed to correct its flawed culture around security.

Exchanges did not die after Mt. Gox and self-custody will not die after this. The exchange industry has evolved since Mt. Gox with multi-signature custody, proof-of-reserve practice, and regulatory structure that outlasted the operator who failed. Whether massive self-custody failures produce that kind of durable change is the open question. One-off audits are currently underway across every hardware wallet vendor, but the real lever is how we move forward when we talk about security in self-custody.

The bug, briefly

Coldcard's board config defined the macro MICROPY_HW_ENABLE_RNG and set it to 0, because Coinkite supplies its own hardware RNG. A library the firmware migrated to in 2021 checked #ifndef MICROPY_HW_ENABLE_RNG, which asks whether the macro exists, not whether it is switched on. The macro existed. The build linked MicroPython's software fallback PRNG, a toy generator meant for chips with no hardware RNG at all. The real hardware RNG code stayed in every affected binary, reviewed and intact. Seed generation simply never called it.

Coinkite puts effective entropy on Mk2 and Mk3 devices running firmware v4.0.1 through v4.1.9 at roughly 40 bits against a 128-bit design target. Forty bits is a weekend on commodity hardware. Block Engineering's independent analysis is worse: depending on what an attacker already knows about the device UID and boot timing, the practical search space collapses toward 2^16, and the reseed on later models is capped at 32 bits because only four digest bytes ever reach it. Coinkite's figure for Mk4, Q, and Mk5 is about 72 bits, still under the standard and inside the budget of a funded attacker.

Entropy generation is the critical step in self-custody that has no replacement. The seed is the root of every key the wallet will ever derive, so a perfect PIN, textbook multisig, and a signing screen that shows exactly what you are approving all rest on top of it, and none of them can save a seed an attacker can guess. That is why this one step is worth staring at while the rest of the device goes unmentioned.

That is the entire technical story, and it is the least interesting part of the incident. The bug is ordinary. What matters is that it shipped, passed review, survived a test suite, and sat in public source for five years underneath the device the community told everyone to buy.

Where the process broke

The development practices at Coinkite failed to catch this. The commit that introduced the bug, b18723dd on March 1, 2021, changed 120 files and 5,488 lines, swapped out the cryptographic primitives under seed generation and signing, and went straight to master with the message "First pass w/ libNgU." The public history shows a single-parent commit with no merge, no pull request, and no CI run. A change to seed generation reaching users with no formal, published review process is not a one-off slip; it is a process with limited gates and no transparency.

Testing the output for entropy is nearly impossible, and that is the trap. The suite set random.seed(42) for reproducibility, and the only runtime check asserted a handful of distinct byte values, which any deterministic generator passes. No statistical test on a finished seed can separate unpredictable from reproducible: a 40-bit seed still expands into unique, normal-looking addresses. Entropy is a property of the process, not the bytes. What is tractable is testing the path, which nobody did: confirm the hardware RNG is actually reached, and that known inputs produce known outputs. Block Engineering found the failure there in hours. The hardware RNG exported different function names than the library expected, so the call bound to MicroPython's software generator instead, and the correct code sat present and unreachable in every binary. It is the unverified backup: file there, checksum fine, empty the day you restore from it.

A closed secure element adds a variable you cannot account for. The reseed on Mk4, Q, and Mk5 comes from a chip whose firmware nobody outside Coinkite can audit, so the 72-bit figure rests on trust rather than measurement. Reproducible builds prove the shipped binary matches the public source, which matters, but they cannot tell you the source is correct, and they cannot let you feed known entropy into the secure element and check what comes back. Every closed component in the entropy path is one more thing taken on faith.

Most importantly, the "grading" of Coinkite as a reliable provider was done on reputation. Coldcard was the default recommendation for years, sold on marketing, feature lists, and word of mouth, and that recommendation was never attached to anything a buyer could inspect. Nobody traced the call path because everybody assumed somebody already had. That is the habit that has to change. A recommendation should turn on the strength of the development team, whether the code and build can actually be audited, the quality of the tests, and how much trust the design removes from any single part. Reputation without clear evidence is nothing but trust.

What vendors should do to improve validation

None of these are hard asks. Most are a weekend of engineering time, and the first three would have increased the odds of catching the bug.

Require a pull request, a named reviewer, and a green CI run for any change touching cryptographic code. No maintainer exemption, no direct pushes to the main branch, no "first pass" commits that migrate a crypto library. Coinkite cleared none of it for this change. Make sure discussions are publicly visible if code is visible.

Add known-answer entropy tests to CI. Feed a known entropy source into the device, generate a seed, and verify the output is a pure function of the input. Then disable the device's own entropy and confirm the output changes. A working hardware RNG makes seeds depend on hardware entropy; a broken one makes them deterministic given a known input.

Verify the call graph on the built binary, not the source. Confirm at the linker level that the RNG symbol resolves to the hardware path. Reading the code cannot tell you this, which is exactly how five years went by.

Emit generation-time evidence. When a seed is created, the device should record which physical source each byte came from (the hardware RNG register, the secure element, the user's dice) and confirm each was live, never the entropy values themselves, which are the seed. The record is about provenance, not quality: whitening makes even a broken generator's output look random, so a statistical check passes on the exact fallback that caused this, and what cannot be faked is that the hardware path was actually read. Keep it as a signed, exportable/viewable attestation, and leave out any field that also feeds the seed, since a boot timestamp here would have leaked the timing the attack relied on. Sign it across the trust boundary: each component attests the other's contribution, so one buggy component cannot forge both the seed and its own alibi. A birth certificate like that would let a user identify the exact code blocks responsible for their seed generation, instead of inferring it from a firmware version and their own memory.

Re-run AI-assisted audits on old code with current tooling on a fixed schedule. Code that was clean under 2021 review methods is not clean now.

What the community has to demand

The audit wave now underway is the right instinct running on the wrong standard. Ledger has said its certified TRNG is unaffected. Trezor has said it does not share Coldcard's code. Keystone, Foundation, and BitBox have issued similar statements. Every one of those is a claim, and Coldcard would have made the identical claim on any day of the last five years.

The question each vendor needs to answer is narrow and checkable: can you trace the entropy path from source to seed, end to end, on the actual shipped binary, and show that the hardware RNG is reachable from make_new_wallet or its equivalent? "We have a TRNG and it is in the code" is the answer that failed.

Open-source vendors have an advantage in answering this question, and should use it. Producing that trace means publishing the source path, the symbol resolution on the built binary, and the known-answer test vectors, none of which exposes a proprietary secure-element design. The closed part can stay closed; the entropy path can still be shown. A vendor that answers "trust our certification" when it could publish the trace is choosing opacity it does not need, and that choice should count against it.

Three levels of assurance need separate names, because collapsing them is how this happened. - Source availability means you can read it. - Reproducible builds mean you can confirm the binary matches what you read. - End-to-end path verification means you can confirm the secure path actually executes.

Coldcard had the first two. Almost every discussion of hardware wallet security treats the first two as sufficient, which is the problem we need to fix now.

Two structural changes would make the validation process normal rather than heroic: - One is a published audit framework with standard test vectors, so a vendor can be measured against a checklist that already exists instead of a checklist they wrote. - The other is cross-vendor review or bug bounty program, funded jointly, on the argument that a design failure at any vendor damages every vendor's customers.

This is at least the second time a bug like this has produced weak seeds at scale. In 2023, Milk Sad (CVE-2023-39910) revealed that Libbitcoin Explorer's bx seed used a Mersenne Twister seeded from 32-bit time(), exposing 120,000 keys. Same root cause, same cultural failure: open source, publicly documented, nobody auditing the entropy path. The response was to fix Libbitcoin, warn users, and move on. That response worked once and cannot work twice. Every wallet that generates keys needs its entropy path traced on every release, and the traces need to be published.

Holders also have two levers to pull to mitigate risk in key generation: multi-vendor multisig and bring your own entropy (dice, coins, etc.). Both mechanisms reduce the reliance of wallet security on any single vendor's implementation. In Coinkite's case, multisig and dice-roll users are thought to be unaffected by this exploit. Critics will say that dice rolling can be unreliable. The reality is that the current state of industry means users either roll their own, or trust a vendor. The only way to actually improve this dynamic is to make it easier for users to verify the validity of entropy from a hardware wallet. Even with these options as part of the equation a robust future of self-custody heavily relies on the community getting the culture around vendor/code evaluation correct.

The pressing challenge of AI

Everything above points one direction: transparency is the advantage. A vendor that shows its work, in the code and in the build, needs less trust from the buyer, and needing less trust is the entire point of self-custody. But open code cuts both ways. Anyone can read it, which means anyone can also hand it to a frontier model.

Any code that has ever been public is now scannable by an attacker with a current model, across the full commit history, faster than any human review team can work. The five-year dormancy window that let this bug survive is closing, and it closes for every project at once. A clean audit in 2024 says nothing about 2026, because the tool doing the reading keeps getting better. Auditing becomes maintenance, not a milestone.

Hiding the source is the wrong reaction. Closed code delays attacker discovery, and delays defender discovery by more, because you find your own bugs only when the funds are already gone. The economics point the same way: AI review at scale runs into real token bills, and an open project can spread that cost across a community while a closed vendor pays alone and cuts corners in private. What fits the moment is a shared audit framework, one that lets the community hunt vulnerabilities early and often: full re-audits each time a more capable model ships, and AI-assisted review on every pull request, with human oversight and discussion before anything merges.

Moving Forward

It is tempting to lay this on Coinkite alone, or on the people who recommended the device for years. The blame is wider than that. Bitcoin worked. Self-custody worked. What failed sat around them: a critical bug in plain sight in public code, under a device holding a large share of the community's savings, and no habit anywhere in the ecosystem was going to catch it.

That culture is being rebuilt now and our discussions will shape it. Over the next few months the audits underway will continue in two possible directions: traced entropy paths, published test vectors, and symbol resolution checked against real binaries, or another round of reassuring press releases from vendors. The Coldcard incident proved that the Bitcoin community had largely been trusting and not verifying, despite the common mantra to do the opposite.

This is not the time to recoil from our stated values. It is the time to shift from trust to verification. One preprocessor check tested the wrong thing for five years and nobody looked, because nobody had to; reputation stood in for proof. The wallets that deserve trust after this are the ones that never ask for it, the ones that hand you the proof and let you run it yourself.

Appendix: Example Hardware Evaluation Framework

Everything above reduces to one question a buyer or reviewer can put to any vendor: can you show, not assert, that the secure path runs? The checklist below turns that into concrete asks. A vendor's answers sort them into the three assurance levels, and a "no" in the entropy-path section should count for more than a polished answer everywhere else.

Assurance level - Is the firmware source available and complete, including the seed-generation path? - Are builds reproducible, so you can rebuild and match the shipped binary byte for byte? - Can they show end-to-end path verification, not just that the code exists?

The entropy path - Can they trace the path from source to seed on the actual shipped binary, and show the hardware RNG is reachable from the seed-generation function? - Do they verify at the linker level that the RNG symbol resolves to the hardware path rather than a software fallback? - Do they publish known-answer vectors from a test build that pins every entropy source (hardware RNG, secure element, user-supplied dice) to a fixed value, and show that changing each source changes the seed? - Have they audited every preprocessor guard in the entropy path for the existence-versus-value distinction (#ifndef X versus #if X != 0)?

Development process - Are a pull request, a named reviewer, and a green CI run required for any change touching cryptographic code, with no direct-to-master exemptions? - Are there commits that swapped cryptographic primitives without review or detailed discussion around the change?

Testing - Do the tests cover seed-generation entropy, or only downstream behavior? - Do they test the process (path reachability, known-answer vectors) rather than run statistics on output bytes, which a broken generator passes?

Closed components - Which parts are closed (secure element, bootloader), and do any sit in the entropy path? - For each closed component in that path, what exactly is taken on trust, and can they bound it, such as the real bit contribution of a reseed? - Where you cannot inject a known value, can they at least show the component is load-bearing (force a reseed, confirm the output depends on it) and name what stays unverifiable?

Generation-time evidence - Does the device record or show provenance, which physical source the entropy came from during seed generation, without ever persisting the entropy values? - Is the record a signed, exportable attestation that leaves out any field that also feeds the seed? - Is it signed across a trust boundary, each component attesting the other's contribution?

Track record - After their last disclosure, did they publish a root cause and traces, or reassurances? - Do they re-audit old code as more capable models ship? - Does the license permit independent commercial auditing, or does it deter the people who would build tooling against it?

So did anyone in that thread actually do a code review along with ...

2026-08-04T12:57:26Z

In reply to nevent1q…7jsn
_________________________

So did anyone in that thread actually do a code review along with the claims? Or was the bug just that easy to miss that it wasn’t found even given such a specific question? I’ve got some ideas I’m working on to share about a path forward and so I’m genuinely very curious about how this snuck by for 5 years

Open questions to the bitcoin community: - why did we not trust ...

2026-08-03T13:27:57Z

Open questions to the bitcoin community:
- why did we not trust the banks, but we trusted hardware providers like coinkite? Was this purely an education gap about seeds or was it a double standard?
- how did we not catch a software error in a critical piece of code that was “source-available”? Are there bounty programs for vulnerabilities like this? If not, why not?
- why don’t more hardware wallets directly support dice rolls? I know seedsigner does, but is that it now that the coldcard is toast? Are these paths thoroughly tested for reliability?

Generally agree, but camera entropy is not a good idea to use for ...

2026-08-03T13:13:25Z

In reply to nevent1q…27ta
_________________________

Generally agree, but camera entropy is not a good idea to use for real funds. I believe seedsigner says this themselves.

For example, the seed signer software doesn’t have any threshold for entropy so a plain black image would potentially generate a low entropy seed.

Thanks for sharing this!

2026-08-02T18:53:44Z

In reply to nevent1q…qc3t
_________________________

Thanks for sharing this!

Multisig + health checks FTW!

2026-07-31T18:03:45Z

In reply to nevent1q…p700
_________________________

Multisig + health checks FTW!

This. This wasn’t a cold card problem… this was a putting ...

2026-07-31T15:26:56Z

In reply to nevent1q…gl4c
_________________________

This. This wasn’t a cold card problem… this was a putting your trust in the vendor software problem. I would argue leaning heavily on something like bitkey actually makes this worse.

Yes it solves other problems, but this same exploit can, and will, happen to other vendors. Actually… didn’t it already happen to jade? Roll dice, use multiple vendors.

For sure. Definitely a trade off between doing everything on your ...

2026-07-31T15:03:47Z

In reply to nevent1q…u3sa
_________________________

For sure. Definitely a trade off between doing everything on your own, but there are some spots (like rolling dice) where you can easily reduce risk without increasing your risk of making a mistake. Only way you can do that is to understand the potential risks and where you are putting trust in a vendor

Seems like a good time to remind folks of the great multisig ...

2026-07-31T14:51:09Z

Seems like a good time to remind folks of the great multisig guide from seedsigner. Even if you don’t have a seedsigner there are some great bitcoin security tidbits in here like the section on “Creating Secure Private Keys in a Trust-Minimized Way”.

The ColdCard exploit is a great reminder of the importance of minizing vendor risk. The same exploit could have been found in SeedSigner or any other vendor. If you aren’t making an effort to take vendor risk out of each part of the process then you should re-evaluate your strategy.

https://seedsigner.com/seedsigner-independent-custody-guide/

👍 I’ve been a happy customer, but can’t speak much beyond ...

2026-07-31T14:41:07Z

In reply to nevent1q…9lfr
_________________________

👍 I’ve been a happy customer, but can’t speak much beyond what I know as an end user

😂

2026-07-31T14:22:25Z

In reply to nevent1q…27g9
_________________________

😂

Any issues with nunchuck? Any reason they weren’t mentioned or ...

2026-07-31T14:17:51Z

In reply to nevent1q…hs6d
_________________________

Any issues with nunchuck? Any reason they weren’t mentioned or just can’t mention them all?

Geographically spread out multisig with dice rolls is the way to ...

2026-07-31T14:12:56Z

In reply to nevent1q…7t3e
_________________________

Geographically spread out multisig with dice rolls is the way to go. My next investment is a second stateless signer to reduce vendor risk

Very interesting, very buggy

2026-07-29T12:52:03Z

In reply to nevent1q…d0wg
_________________________

Very interesting, very buggy

So now that we’re all running agents… who has hindsight wired ...

2026-07-28T13:10:49Z

So now that we’re all running agents… who has hindsight wired in for memory? If you don’t you’re missing out.

Congrats!

2026-07-28T02:33:01Z

In reply to nevent1q…wc2s
_________________________

Congrats!

Makes sense!

2026-07-28T02:23:20Z

In reply to nevent1q…6mxd
_________________________

Makes sense!

Also apologies with hammering your repo with issues/PRs - bridge ...

2026-07-26T20:49:46Z

In reply to nevent1q…h7wp
_________________________

Also apologies with hammering your repo with issues/PRs - bridge is working great though! A great stopgap since the openai compatible harnesses are currently broken in buzz. Thanks for building this!

I got this bridge working today and it seems fantastic. Biggest ...

2026-07-26T18:39:03Z

In reply to nevent1q…gwdz
_________________________

I got this bridge working today and it seems fantastic. Biggest hurdle for me right now is easily adding the agent into my self-hosted relay. The buzz desktop app does not let me add a member by pub key and the CLI doesn’t expose the invite claim mechanism to Hermes. When I first got this working the relay admin was totally open, which is obviously not the right solution. I opened an issue on the buzz repo here: https://github.com/block/buzz/issues/3014

It does look like the code generally follows the established nips ...

2026-07-25T18:18:25Z

In reply to nevent1q…6wnp
_________________________

It does look like the code generally follows the established nips used by ngit. Everything is just hard coded to a single relay right now. Guessing that will change as it stabilizes

As far as I can tell the current implementation is 1 relay per ...

2026-07-25T18:16:32Z

In reply to nevent1q…qa3v
_________________________

As far as I can tell the current implementation is 1 relay per community. The name of the community actually has to match the name of the host in the code. It’s very clear much of Buzz is an early implementation so hopefully this will change. Some of the ngit functionality would also make a lot more sense with more relay flexibility.

I know we are all caught up in the agent hype, but did anyone ...

2026-07-25T18:00:00Z

I know we are all caught up in the agent hype, but did anyone recognize that this is blocks attempt to fully. Replace the GitHub interface? Not sure how I feel about it yet - wish it was integrated with existing git over nostr solutions that are more decentralized.

Hopefully some discussion to come.

This will be helpful… the harness management is a little all ...

2026-07-25T17:56:50Z

In reply to nevent1q…gwdz
_________________________

This will be helpful… the harness management is a little all over the place right now with buzz.

Buzz desktop is super buggy but I will try to keep this up to ...

2026-07-25T17:55:32Z

In reply to nevent1q…rnh4
_________________________

Buzz desktop is super buggy but I will try to keep this up to date.

https://github.com/armstrys/buzz-relay-thin.git

Me too! I hope the “One community, one relay” design is short ...

2026-07-25T17:37:45Z

In reply to nevent1q…sq6y
_________________________

Me too! I hope the “One community, one relay” design is short term though. Seems restrictive.

Yeah that’s where I am at. Was able to get in running on ...

2026-07-25T16:50:01Z

In reply to nevent1q…kdpn
_________________________

Yeah that’s where I am at. Was able to get in running on Ubuntu, but even now the latest desktop app seems to be completely rejecting it

Surprised no one had made this yet… Let’s test out buzz! ...

2026-07-25T15:33:22Z

Surprised no one had made this yet… Let’s test out buzz!

nostr.communities.buzz.xyz

Don’t blame you :)

2026-07-25T15:20:26Z

In reply to nevent1q…wwpk
_________________________

Don’t blame you :)

I should get myself a physical cookbook… I do find myself doing ...

2026-07-25T14:33:32Z

In reply to nevent1q…vfg8
_________________________

I should get myself a physical cookbook… I do find myself doing a lot of NYT recipes! Kenji Lopez-Alt is typically my go to any time I’m looking for a new recipe though. He nails the food science and methods testing.

This was the first time I’d tried mayo on turkey, but it makes sense and it worked pretty well!

Did you have much trouble getting the relay running?

2026-07-25T14:24:22Z

In reply to nevent1q…hh8m
_________________________

Did you have much trouble getting the relay running?

Reminds me of one of my favorite turkey recipes. The herbed mayo ...

2026-07-25T14:20:30Z

In reply to nevent1q…8fj7
_________________________

Reminds me of one of my favorite turkey recipes. The herbed mayo is killer for leftover sandwiches.

https://cooking.nytimes.com/recipes/1023623-mayo-roasted-thanksgiving-turkey-with-gravy

Rolling your own is always fun but it may be worth keeping any ...

2026-07-25T14:12:54Z

In reply to nevent1q…4pss
_________________________

Rolling your own is always fun but it may be worth keeping any eye on Buzz now that it exists. Certainly will fill the gap for coworking though it may miss on many other needs

GitHub readme isn’t bad. This video also gives a pretty ...

2026-07-25T14:10:22Z

In reply to nevent1q…uqk4
_________________________

GitHub readme isn’t bad. This video also gives a pretty full-featured view. https://youtu.be/g8dQBSKIGyc?is=bb_W9SCLufBPqQOC

Lots of folks saying Fable is a planner and Opus is a workhorse. ...

2026-07-25T14:08:36Z

In reply to nevent1q…ra6l
_________________________

Lots of folks saying Fable is a planner and Opus is a workhorse. There’s gotta be some key difference I would think…

I found it hard to get a buzz relay started so I set up a repo to ...

2026-07-25T07:27:15Z

I found it hard to get a buzz relay started so I set up a repo to do it quickly and easily. Quick path to self-hosting buzz instead of going hosted.

https://github.com/armstrys/buzz-relay-thin

It’s possible you can use an existing nostr relay actually. I ...

2026-07-24T21:16:21Z

In reply to nevent1q…m4g3
_________________________

It’s possible you can use an existing nostr relay actually. I didn’t have one running already.

It does look like my issue with the agents was being caused by an open issue for self hosted relays on Mac.

https://github.com/block/buzz/issues/2641

Wild that DAMN. was almost a decade ago.

2026-07-24T16:37:26Z

In reply to nevent1q…dyt4
_________________________

Wild that DAMN. was almost a decade ago.

FWIW, Claude did help me get the local relay running in docker by ...

2026-07-24T16:35:44Z

In reply to nevent1q…2shs
_________________________

FWIW, Claude did help me get the local relay running in docker by cloning the buzz repo. Having issues getting the Claude code harness to respond, but overall it is working! Does seem very cool. Would be great if you could bootstrap a relay from the UI

Okay thanks. I’ll dig a bit deeper. Testing on a work laptop so ...

2026-07-24T14:42:53Z

In reply to nevent1q…3qhm
_________________________

Okay thanks. I’ll dig a bit deeper. Testing on a work laptop so sensitive to outgoing connections. Primary onboarding doesn’t seem to have an option but maybe I just need to get under the hood

Was super excited about buzz because it read like the relay was ...

2026-07-24T14:31:29Z

Was super excited about buzz because it read like the relay was self hosted by default but during set up it is asking for sign in to a hosted relay. Any way around this?

I am just running a local searxng instance in docker and it works ...

2026-07-21T14:23:52Z

In reply to nevent1q…ljv2
_________________________

I am just running a local searxng instance in docker and it works great. Some agents support natively, some I need to make a simple web search skill that teaches it how to query.

You control the search endpoints and the infra. Agent can help you set it up.

npx skills add https://github.com/JuliusBrussee/caveman --skill ...

2026-07-14T13:10:00Z

In reply to nevent1q…ytdp
_________________________

npx skills add https://github.com/JuliusBrussee/caveman --skill caveman

Have you tried the caveman skill?

2026-07-14T13:07:06Z

In reply to nevent1q…l87q
_________________________

Have you tried the caveman skill?

We also learned a shit ton about what shouldn’t be done on ...

2026-07-13T01:24:18Z

In reply to nevent1q…jgnx
_________________________

We also learned a shit ton about what shouldn’t be done on blockchain. They now get to fight a different battle with clearer context

No it doesn’t it partners with a payment processor like visa to ...

2026-07-10T14:13:02Z

In reply to nevent1q…ee83
_________________________

No it doesn’t it partners with a payment processor like visa to do that. Look at your debit cards.

Still unsure if helpful or if stupid. Agent skill that allows ...

2026-07-10T02:24:03Z

Still unsure if helpful or if stupid. Agent skill that allows docker deployments directly from a GitHub repo. Agent writes code. Human sets up infra. Automation deploys services.

https://github.com/linksawakening/docker-git-deploy#how-it-works

1. **Install the skill.** The human asks the agent to install this skill.
2. **State the goal.** The human asks the agent to deploy services X, Y, Z to a server.
3. **Scope it.** The agent asks about the current server, explains the minimum requirements for install, and explains the git access involved — the **agent needs write** access to create and push the deployment repo, while the **server only needs read-only** access to pull it. Any Git host works (GitHub, GitLab, Bitbucket, self-hosted).
4. **Create the deployment repo.** The agent generates a pure-config repo from the starter (compose files, service definitions, `.env.example`) and pushes it to the git remote.
5. **Bootstrap the server.** The agent hands the human a one-line install command to run as root on the server; it clones the repo and installs the systemd timer. The agent also explains **which secrets and environment values each service needs** (derived from the repo's `.env.example`) and **how to create the `.env`** on the host — e.g. `cp .env.example .env` and then fill in real values. The deploy is skipped until `.env` exists, and secrets never live in the repo. The agent helps troubleshoot but never needs access to the server itself.
6. **Ongoing adjustments and new services.** From then on, the human asks the agent to add a service or change config, and the agent commits it to the repo and merges to `main` — from any location, with no server access. The server polls `origin/main` on its timer and applies the change automatically, reconciling with `docker compose up -d --wait` and rolling back if a new version fails to become healthy. The human's **only** manual step is updating `.env` on the server — and only when the agent says a new or changed service needs a new secret.

quoting
note157k…cyzx
New idea in testing:

Agent skill that helps you set up a home lab docker deployment that periodically pulls its config from a git repo.

Agent sets up framework and service configuration you review and production server pulls with no direct agent access.

Want to add or configure new services? Make requests and edits on your local device and they deploy server side with minimal editing on server.

Server stays lean and deployments are all version controlled.

Will share code after more testing in action.

Precisely! Just saying I think it’s the same with nostr (to an ...

2026-07-09T13:31:18Z

In reply to nevent1q…9dlc
_________________________

Precisely! Just saying I think it’s the same with nostr (to an extent)

My guess is that they will burn hot and fade away. The only ...

2026-07-09T05:30:50Z

In reply to nevent1q…pd4e
_________________________

My guess is that they will burn hot and fade away. The only question is where nostr sits when they burn out and leave some social scars.

Glad we have folks like you contributing to the cause with the right intentions!

I think the good news is that the foundation is right. Nostr is ...

2026-07-09T05:04:08Z

In reply to nevent1q…wgph
_________________________

I think the good news is that the foundation is right. Nostr is so modular and based on simple cryptographic primitives with such little consensus that the most decentralized and free version should always exist.

At this point it seems inevitable that true decentralization and freedom comes at a cost that most folks won’t accept. My biggest hope is that we can at least make the decentralized and free options popular enough that the bigger, convenient platforms are effectively forced to be interoperable. The fun part is figuring out what levers we have to do that… maximizing numbers is a big part, but not the whole story - if the content is better or more diverse then other networks will be forced to adopt.

The mathematically optimal solution is probably something like ...

2026-07-09T04:54:12Z

In reply to nevent1q…0a5u
_________________________

The mathematically optimal solution is probably something like quadratic voting, but how do you actually implement that in a political system in practice. Interesting book about it called radical markets (trigger warning for anyone who spent time arguing with the ETH bros on the topic)

I’ll definitely be rooting for Morocco and Norway over others! ...

2026-07-09T04:43:10Z

In reply to nevent1q…ywas
_________________________

I’ll definitely be rooting for Morocco and Norway over others! I think Morocco would feel the most refreshing even though Norway is a less common winner. Would like to see Morocco make it all the way after a decade of success

Funny how many people use decentralized open source tools and ...

2026-07-09T04:40:52Z

In reply to nevent1q…57ax
_________________________

Funny how many people use decentralized open source tools and don’t realize that the developers have no product to sell. It’s open source….

Terrible take.

Literally same metal failure most crypto bros made/make when ...

2026-07-09T04:37:35Z

In reply to nevent1q…ddr0
_________________________

Literally same metal failure most crypto bros made/make when falling for VC-backed tokens over bitcoin. The whole point is that it’s simple, it’s cheap, and you don’t need crazy server farms to keep it running. When you fall into the trap of thinking faster/prettier is better without examining the cost you have lost the plot.

New idea in testing: Agent skill that helps you set up a home lab ...

2026-07-09T03:44:09Z

New idea in testing:

Agent skill that helps you set up a home lab docker deployment that periodically pulls its config from a git repo.

Agent sets up framework and service configuration you review and production server pulls with no direct agent access.

Want to add or configure new services? Make requests and edits on your local device and they deploy server side with minimal editing on server.

Server stays lean and deployments are all version controlled.

Will share code after more testing in action.

1 T-shirt is in fact 1 T-shirt.

2026-07-07T13:02:28Z

In reply to nevent1q…t366
_________________________

1 T-shirt is in fact 1 T-shirt.

Fair. Like a true ‘Merican 🇺🇸

2026-07-07T03:58:45Z

In reply to nevent1q…3fn3
_________________________

Fair. Like a true ‘Merican 🇺🇸

😂 let’s all at least root for being able to say something ...

2026-07-07T03:55:51Z

In reply to nevent1q…sce4
_________________________

😂 let’s all at least root for being able to say something new like “Africa won”

Need pics of the finished product!

2026-07-06T03:17:50Z

In reply to nevent1q…93lx
_________________________

Need pics of the finished product!

The open source tool set for running local agents has really ...

2026-07-05T19:49:22Z

The open source tool set for running local agents has really improved. Setting up Hermes with access to tools like Hindsight has been a game changer. Also a great feedback loop in that the improved agent quality makes managing self-hosted tools easier and then makes the quality of the agent interaction stronger. Getting more fun by the day!

I mean I only saw from 80 on but Cape Verde kept that game close ...

2026-07-04T03:47:15Z

In reply to nevent1q…y0cl
_________________________

I mean I only saw from 80 on but Cape Verde kept that game close and well played from then until 120. Almost put in an equalizer a couple of times. Hard to beat the excitement of the ending from games like Croatia/Portugal, but I think it delivered pretty consistently high quality soccer

This might have been the best game of the World Cup so far. ...

2026-07-04T00:51:04Z

In reply to nevent1q…pa0g
_________________________

This might have been the best game of the World Cup so far. Incredible from Cape Verde!

I’ve used both and Hermes definitely felt much more stable

2026-06-29T16:49:58Z

In reply to nevent1q…m2sr
_________________________

I’ve used both and Hermes definitely felt much more stable

🫡

2026-06-28T23:37:08Z

In reply to nevent1q…pe9g
_________________________

🫡