COLDCARD RNG incident the public record, collected and explained
Informational only, and this site never asks for your seed words. details

Informational only. This is an open source collection of what others have published about the incident, together with an explanation of it. It is not financial, security or legal advice, and not a substitute for professional advice about your own situation. It is not affiliated with, endorsed by, or speaking for Coinkite. Material is attributed and quoted as published; where sources disagree their scenarios are kept separate with their assumptions rather than reconciled into one answer. Everything is meant to be checked against the linked evidence rather than taken on trust. Act on your own judgement about a particular situation. Editorial standards and corrections.

Do not disclose recovery material to a website, form, message or support account. This site never asks for it, and contributions containing recovery words or private keys are not accepted.

CKTRIPWIRE methodology

cktripwire-methodology

https://cktripwire.com/methodology

Organisation
CKTRIPWIRE
Evidence role
Primary technical research
Published
not established
Source changes
0
Detected differences
0
Unreviewed
0
Copies held
1

The method behind cktripwire-honeypot-monitor, linked from the scoreboard and registered separately so the experiment's stated design is held as a document rather than inferred from its results. It describes how the operator reproduces the RNG defect in software (ngu.random.bytes() resolving to the XOR of two Yasmarang PRNGs with no hardware entropy), how that reproduction was checked against real hardware, and how the experiment is designed: difficulty bands set by the entropy added on top of the attacker-known seed, a zero-entropy mainnet control, and deliberately coarse public reporting with no addresses, exact amounts or keys. It states that the operator retains the keys to every honeypot. The page directs readers to @jamesob for background and updates.

Kept at tier 3 rather than the chain-monitor lane: this is static prose, unlike the scoreboard's live state. The reproduction, the hardware validation and the entropy estimates are the operator's own and have not been independently reproduced by this archive.

Every check is recorded, including checks that found no text change. A detected edit is therefore bounded between two checks. The publisher's exact save time is not observable from this record. Last checked .

  1. Earliest copy held Current
    seen · Captured here 5,891 chars
    Extracted text as captured 
    CKTRIPWIRE
methodology
scoreboard
admin
This page explains what the Coldcard RNG bug is, how we reproduce
it in software, how we validated that reproduction against real hardware, and how the
experiment on the scoreboard is designed. Everything here is defensive
security research: the underlying bug is public, and every honeypot is fully recoverable
by us.
The bug
Coldcard hardware wallets (Coinkite Mk3/Mk4/Q) running firmware in the 4.x series
shipped with a build/linking defect: the call that is supposed to draw randomness from the
device's hardware true-random-number generator (TRNG) silently fell back to a
software pseudo-random generator instead. A compile-time guard meant to refuse to
build without a real TRNG used a defined-ness check rather than a value check, so it never
fired, and the software fallback was linked in on every affected build.
Concretely, ngu.random.bytes() resolves to the XOR of two
Yasmarang PRNGs, with no hardware entropy: one half (in libngu) is seeded from
compile-time constants that are identical on every device and never reseeded in 4.x; the
other half (the MicroPython STM32 port fallback) is seeded once at first use from a handful
of low-entropy boot registers. The result is a wallet seed drawn from a keyspace small
enough to brute-force. Because seeds, dice-derived seeds, XOR seeds, and nonces all flow
through this generator, the private keys of affected wallets can be reconstructed and the
coins swept. Attackers are actively doing exactly that.
What this project does
We generate decoy honeypot wallets that carry the identical weakness, fund them
with small amounts on Bitcoin mainnet, and watch which ones get swept and how quickly. Some
honeypots are deliberately hardened with extra genuine entropy — physical dice rolls,
or a BIP-39 passphrase — layered on top of the compromised seed. By observing where
sweeping stops as we add entropy, we map the frontier of what the attacker can
currently crack, and how much added protection actually defends a wallet.
Reproducing the bad entropy in software
No physical device is needed to generate a vulnerable seed — the whole path
is deterministic software. We reimplemented the exact firmware pipeline:
Per 32-bit word, rng_get() (the STM32-port Yasmarang fallback) XOR
my_yasmarang() (the libngu Yasmarang with fixed constants), little-endian
packed — byte-for-byte as the firmware's my_random_bytes().
The port half is seeded once at first call: pad = UID ^ SysTick,
n = RTC->TR, d = RTC->SSR. The libngu half is its
compile-time constant state.

    Excerpt only. The complete copy is held offline and backs quotations on this site. The original publication remains the canonical public source.

How to check this yourself

The excerpts and plain unified diffs above show the text this project held and how it changed. To verify a quotation, compare it against the page itself or against the Internet Archive's copies, which are independent of this project.

Complete captures are held offline rather than mirrored here, so this page shows diffs and excerpts. If a quotation is ever disputed, the full copy can be produced. Ask.