Attack-cost estimates

Block, Coinkite, LLFOURN and otaliptus describe the search space using different assumptions about what an attacker knows.

Where a source states a Mk3 figure and says nothing separately about Mk2, carrying that figure across to Mk2 would be a further derivation from their shared code path.

The MCU identifier term

one 32-bit word of the STM32L4 UID, and what its field layout does not establish

The affected MicroPython fallback reads one 32-bit word from the STM32L4's 96-bit unique-identifier area. It combines that word with the SysTick counter, and seeds two other state words from the real-time clock and its subsecond register.

Whether the first word's field layout narrows the practical range across shipped COLDCARD devices is unresolved in this record. This project holds no population sample of device UIDs as of a 14 August 2026 recheck, so LLFOURN's 2^20 assumption remains unchecked here. U2

Two sources published since narrow the term without supplying that sample. The CKTRIPWIRE methodology page describes an instrumented firmware build flashed to one sacrificial Mk3 and a boot battery that captured the device's actual seeding registers. The operator reports that it found the UID word packed with die coordinates rather than uniform across 32 bits, SysTick confined to a narrow early-boot range, and the Mk3 real-time-clock registers reading zero because that clock is disabled and has no backup battery. That is a single device described by the experiment's own operator: it speaks to the field's shape, not to its distribution across shipped devices. R3 Separately, on 7 August ineedanamegenerator put the whole Mk3 seeding word at about 23 bits rather than 32, by the reasoning set out in the table above. That is one poster's derivation from a stated wafer-size assumption, not a measurement, and it is narrower than the 2^32 ceiling Block gives for the same word. R4

The unresolved RTC term

whether the real-time clock contributes useful variation on Mk4-class devices

otaliptus isolates a second uncertainty that the headline bit counts can hide: whether the real-time clock contributes useful variation on Mk4-class devices. The post models roughly 24 additional bits if it does, and no such contribution in the pessimistic case, then broadens both results to reflect uncertainty in the other inputs. It does not report that Mk4 RTC behaviour is broken. The author says that question is unanswered, and this archive has no runtime measurements that resolve it. R5

Illustrative half-space times

The following table applies time = 2^(bits - 1) / rate. Calling half the space an average assumes that the target is uniformly positioned in the enumerated order and that the attacker has no better prioritisation. The device-state distributions have not been measured, so this is a sensitivity model, not an empirical average or a forecast of attacker capability. A day is 86,400 seconds and a year is 365.25 days in the displayed conversions.

Published rate and cost figures sit beside that model, none of them reproduced here. The Bitcoin Dev Project's explainer thread put a 2^40 Mk3 search at 20 to 45 minutes on rented specialised GPUs, for under a dollar of compute. R7 CKTRIPWIRE, which funds deliberately weak honeypot wallets and watches which ones are swept, published an estimated GPU crack time of about 88 minutes for its zero-added-entropy control band, then on 6 August revised its estimates sharply downward across every band, the control to about two minutes. R8 Between those two states, kTimesG posted in the BitcoinTalk compromise thread that the control's seed was one of 16,777,216 candidates and had been found in 4.2 seconds on an RTX 4090 rather than 88 minutes, that the site's estimate was about 352 times too high, and that the control's inputs could not arise on a real device, so its outcome says nothing about how real compromised seeds were computed. Neither the 4.2-second run nor the 352-fold factor is reconciled here against the site's figures, and CKTRIPWIRE's published method states that its reproduction was checked word-for-word against a real Mk3. R9 LLFOURN separately reported that attackers appeared to be acquiring additional compute capacity for this kind of offline candidate search; that activity is not verified here. R10

In the same exchange Greg Maxwell asked participants not to publish reductions of the COLDCARD search space while vulnerable funds remained unswept, and kTimesG replied that the point was only that the honeypot did not reflect real conditions. R11

Interactive source comparison

Published model explorer

Select one published candidate-space scenario and vary only the candidate-check rate. This does not accept wallet details, dice rolls or passphrase constructions.

Published scenario Choose a source-labelled model Block: stable-RTC scenario Block: effective UID and timer word unknown Coinkite: Mk3 estimate LLFOURN: Mk3 model Block: loose enumeration ceiling Block: successful-reseed boundary LLFOURN: revised follow-up range Coinkite: Mk4-class estimate LLFOURN: initial model Block: loose enumeration ceiling otaliptus: RTC problematic otaliptus: RTC contributes Illustrative checks per second 4,000 2 million 16 million 1 billion

Choose a model to compare its published boundary.

The rate is a sensitivity input, not a benchmark. A complete candidate check includes enough derivation work to compare against the available wallet data. The selected sources use different attacker-knowledge assumptions, so their outputs are not measurements of one shared population.

What the held record established by model

On 2 August, Rob Hamilton asked whether any compromise of a Mk4, Mk5 or Q wallet had been confirmed, noted that multiple earlier claims had been retracted, and asked how much collective effort was being applied to the larger Mk4-class search space. R12 As of a 15 August 2026 recheck, no captured source in this archive demonstrates a Mk4, Mk5 or Q wallet drained in this incident's July 2026 waves. That is a dated archive limit, not a finding that those models were safe, and the published candidate-space estimates above remain in disagreement. U13 One held source reports an earlier case outside those waves. ChuckSRQ's 4 August catalogue of pre-July drain reports lists a July 2023 theft of 3.73118785 BTC from an Mk4 whose owner described a device-generated seed, with the theft and amount cited to a transaction. The author calls it the best public candidate for the firmware defect while stating that its exact cause is not proven and its firmware version is unknown. R14

Reported collision arithmetic

A targeted search for one wallet is not the only consequence of a small candidate space. When many devices draw seeds from the same small set of possibilities, two of them can independently produce the same wallet, with neither owner ever attacked. Three posts held here put figures on that, and each figure carries its author's own assumptions.

• JStefanop1 reported a demonstration program under the 40-bit effective-state model: a duplicate wallet on average every roughly 1.3 million seed generations, and a collision found in 4.7 seconds on an M1 Max at roughly 268,000 evaluated states per second. R15
• skot9000 stated birthday arithmetic at 32 bits of effective entropy: about 77,000 generated seeds give a 50% chance that two of them are identical, and 200,000 give about 99%.
• mitchellaskew stated the same kind of arithmetic with a different threshold: about 93,000 seeds for a 50% chance of a duplicate wallet, contrasted with the 2^256 space of a properly generated 24-word seed.

The two 50% thresholds differ. Each is reproduced here as its author stated it; the difference reflects the authors' own modelling choices, and this archive has not recomputed either figure or verified the reported program run. R16