Conditions that changed the published assessments

Roll counts and output size

The published per-roll figure is about 2.585 bits for a fair six-sided die. The CKTRIPWIRE methodology page states that figure, and a Reddit explainer written after the incident multiplies it out: 50 rolls give 129.25 bits and 99 rolls give 255.915, so on that arithmetic 50 rolls fill the 128-bit entropy field of a 12-word mnemonic and 99 rolls come just short of a 24-word mnemonic's 256. What an unfair die costs is argued over in that same material and is not settled here: the explainer works a deliberately bad die through Shannon's formula, gets 2.575 bits a roll and about one bit lost over 99 rolls; a BitcoinTalk thread relays a claimed 1971 study of 219 commercial dice as bounding the loss at about one bit on a 24-word seed; and a Reddit poster describing years of casino work says retail casino dice are not guaranteed balanced, and that a casino machine-tests each die before it is allowed on a table. This archive has not tested any die. R2

The vendor's dice exception

The Coinkite Mk3 advisory, under the heading "If You Added Dice When Creating the Seed" and in the capture held from 1 August 2026 marked as updated at 9:35 a.m. EDT, says that on affected firmware COLDCARD "hashed the device-generated seed together with every dice roll entered through Add Dice Rolls", that 50 to 98 independent private rolls contributed at least 128 bits and 99 or more approximately 256 bits, and that where at least 50 fair and independent rolls were entered and "the rolls were not recorded or exposed", it does not consider the seed at risk from this RNG issue alone. Two limits are attached: the exception applies to the final seed words shown after the dice were added, and anyone uncertain which words they used, how many rolls they entered or whether the rolls were private is told to migrate. R4

The 50-roll and 99-roll figures in public guidance

The 50-roll figure reached the public before the vendor published it. Antoine Poinsot and Praveen Perera both gave that threshold on 31 July 2026, Perera while recommending migration after an independent recovery attempt. R5 The advisory's added-dice guidance, and the 50-roll threshold with it, is absent from the earliest held state, timestamped 01:56 UTC on 31 July and recovered from the Internet Archive, and present in every held state from 07:30 UTC onward. A dice-only section was already there at 01:56; what arrives later is the guidance for owners who added dice to a device-generated seed. V6 Those posts are retained as the earlier signal in time, not as the basis for the rule.

James O'Beirne recommended migration for coins spendable by one affected COLDCARD key, or by an affected-key quorum, when the device had been initialised with fewer than 99 dice rolls, adding that a strong passphrase could mitigate the risk while warning that most users cannot reliably judge passphrase strength. R7 That is stricter than the public 50-roll exception, and it does not distinguish pure-dice generation from dice mixed into a device-generated seed.

A live CKTRIPWIRE experiment adds observations, not a threshold. It funds decoy wallets carrying the same defect, some of them hardened with extra dice rolls or a passphrase, and records which are swept and how fast. At this archive's first capture, its control honeypot was reported swept after 1 hour 18 minutes while seven cases spanning stepped added-entropy bands were still live. By the state captured on 6 August 2026 the board reported 17 honeypots, 15 live and 2 swept. A sixth low-dice case, rated at 5 added bits, was funded on 6 August and moved from pending to live. Both swept entries carried no added entropy: the operator's own control, and a community-submitted wallet the board records as swept in 2 minutes. By the state captured on 8 August 2026 the board reported 19 honeypots, 14 live and 5 swept. Two low-dice honeypots, HP-2C6F and HP-10ED, had been swept. A newly funded low-dice honeypot, HP-696E, was live. By the state captured on 12 August 2026 at 03:08 UTC the board reported 19 honeypots, 12 live and 7 swept; HP-2C6F and HP-10ED remained swept, HP-696E remained live, and two new trivial sweeps, HP-88A9 and HP-D85A, were recorded. By the later state captured at 05:07 UTC on the same day the board reported 11 live and 8 swept, and the community-submitted three-word passphrase case was recorded as swept after about six days and seven hours. By the state captured at 12:55 UTC on 12 August 2026 the board reported 10 live and 9 swept, and the internal low-passphrase case HP-9C4F was recorded as swept after about seven days and sixteen hours. By the state captured on 13 August 2026 at 01:24 UTC the board reported 9 live and 10 swept, and a second internal low-passphrase case, HP-E786, was recorded as swept after about eight days and four hours. The community-submitted one-word and two-word passphrase cases were recorded as swept after about six days. R8 On 6 August the operator also revised the board's estimated GPU crack times sharply downward, 5 added bits moving from about 2 days to about 66 minutes and 13 bits from about 476 days to about 10 days, without any honeypot changing state. R9 The board attaches its own caution to the live rows: the attack began well before the honeypots existed, so a case that is still live should be read as not taken yet and nothing more. A control outcome and a set of unswept cases cannot establish a safe number of added bits or a general time-to-sweep distribution.

A held source argues the opposite conclusion from the chain rather than from honeypots. On 7 August 2026, in the BitcoinTalk compromise thread, kTimesG wrote that the attack was already over by 2 August, that about 2,050 compromised accounts were detected as having held a balance on 30 July, and that dice wallets "do exist, and are also gone". The post gives no roll counts for those wallets and no method for identifying them as dice-generated, and its account figure is that poster's own detection count, not a chain monitor's published total. It stands against the vendor's dice exception above and against the unswept dice cases on the CKTRIPWIRE board. This archive holds all three and does not resolve between them. R10

A second challenge reaches the record through a journalist rather than a forum. On 6 August 2026 Laura Shin relayed the security researcher Taylor Monahan's claim that the dice rolling being recommended to COLDCARD owners "is the same thing that got the earliest hack victims drained", and that the device warns the user but does not stop them. It is a claim about the workflow rather than about the arithmetic, and one held source is consistent with it: ChuckSRQ's catalogue of pre-July drain reports describes an owner swept after selecting the device's automated dice rolls, and another who later said they had entered a single roll. A single roll is about 2.6 bits. The relay itself carries no roll counts, no victim set and no identification method, and Monahan's own words are not held here. It stands beside the vendor's 50-roll carve-out, not on top of it. R11

Coinkite recommends a strong BIP39 passphrase as a temporary mitigation for an affected mnemonic. It does not alter the mnemonic or repair the generator; it changes the wallet produced by BIP39's key-stretching step.

A community summary moved the same way, five days later. On the Stacker News thread that carried the first drain report, Murch has maintained a running situation summary; the version posted on 5 August 2026 and held in this archive from the capture of 6 August narrows what he had written on 31 July. Where the earlier summary said that wallets pairing device entropy with a strong passphrase "should not be exposed", the later one says such wallets are "only as secure as the passphrase", and attaches a figure to weak: fewer than 25 random characters, or fewer than seven BIP39 words, with funds at risk where no external entropy of at least fifty dice throws was added. Both versions are held. R12

The held guidance still stops short of a single stated passphrase threshold, and where numbers appear they do not say how the words or characters were chosen. Praveen Perera recommended more than seven BIP39 words as a passphrase while still advising migration, but did not state how those words were selected. R13 (For scale, eight words drawn independently and uniformly from the 2,048-word BIP39 list would give 2^88 possible phrases; human selection does not inherit that ideal, and the time needed to test a candidate also depends on PBKDF2 throughput, wallet derivation work and whether the mnemonic has already been isolated.)

One live experiment tests this condition directly, and what it has produced so far is a set of non-events. On 5 August 2026 Cole (@ColeTU) funded five outputs from a single COLDCARD Mk3 seed generated on affected firmware: the seed phrase alone, the same seed with one-, two- and three-word passphrases, and the same seed on a different account number. The following day the poster reported that 14 hours on, only the seed-phrase-only wallet had been swept. The same five wallets appear on the CKTRIPWIRE board as community-submitted watch-only rows, where the unprotected one is recorded as swept in 2 minutes and the other four as still live in the state captured on 6 August 2026; a BitcoinTalk poster relaying the experiment reads that as showing the attackers search default accounts only. R14 A wallet that has not been swept records only that nobody has taken it yet. It puts no floor under a one-word passphrase, and published figures of that kind hold only for phrases selected uniformly.

The same BitcoinTalk thread, in the capture held from 9 August 2026, includes posts relaying reports that attackers were also trying passphrase-protected wallets. One post quotes a reported first confirmed loss of a Mk3 wallet with a two-word passphrase, and another summarises that attackers had moved from low-entropy seeds to brute-forcing low-entropy passphrases as well. R15 Those reports refer to short passphrases, and the CKTRIPWIRE board described above still records no internal passphrase-hardened case as swept in any state held here.

Affected keys do not automatically defeat a threshold wallet: an attacker must recover enough signing keys to satisfy a spending path, so the count that matters is affected keys on that path against its threshold. Below the threshold, those keys alone cannot sign. At or above it, the wallet may be spendable once enough individual keys are recovered. Other key compromises and alternate miniscript paths must be assessed separately. LLFOURN published an explicit correction to earlier guidance on 31 July: Mk4, Mk5 and Q setups in which affected COLDCARDs meet the signing threshold, without another mitigating factor such as dice rolls, need to move. R16 The assumptions behind its urgency are set out in the entropy maths.

Why public-key exposure changes the search

A native SegWit P2WSH output commits to the complete witness script. Before that script or an equivalent descriptor is known, a candidate key cannot normally be checked in isolation against the address: under an independence assumption an attacker must find the complete set of public keys needed to reproduce the script commitment, so candidate spaces multiply. A spend reveals the witness script and all child public keys used in it. A leaked affected signer's child public key or xpub can expose a target for testing that signer before any spend, without necessarily disclosing the complete script. Once the relevant affected key targets are known, those keys can be tested separately and the work needed for a threshold number adds rather than multiplies.

Zach's captured post includes a slide headed "An Unchained vault with 2 Coldcard-generated keys: Group A". The slide says that an attacker with two compromised private keys still needs all three public keys associated with an address, and that the wallet configuration file contains those keys. R17 That can describe a previously unspent P2WSH output when the attacker lacks the third public key and the construction data needed to reproduce its script commitment. It is not a general rule: an exposed descriptor, script or individual affected-key target changes the search, and only a threshold number of private keys is needed to sign once the target and script are known. The archive has not independently authenticated the slide's authorship, webinar context or the complete presentation.

Block's held report sets out conditional low-search scenarios for threshold arrangements; the candidate-space arithmetic those scenarios produce is worked through on the entropy page. R18 Coinkite's upper scenarios and LLFOURN's published model attach much larger values under different assumptions. Device model, timing knowledge, descriptor custody, derivation paths and possible correlation all affect the result, so no time-to-recovery follows from a threshold alone.

Descriptor and correlation assumptions

• Descriptor custody matters. Coordinators and backups commonly store what is needed to reconstruct a multisig wallet; whether an attacker can obtain it is an operational question, not an on-chain fact.
• Per-device independence is an assumption. The Mk4-class boot path derives a reseed value from each device's secure elements, but the source does not prove statistical independence across devices, and Mk2/Mk3 UID and timing inputs may be correlated for devices initialised under similar conditions.
• Miniscript exposure is path-specific. Recovering enough keys for a primary path may or may not satisfy timelocked or recovery paths. The policy, not the product label, determines the threshold.

Kevin Loaec and Rob Hamilton published the threshold and migration-risk positions summarised here. R19

Reported guidance and questions on particular multisig setups

ts_hodl published guidance on 2 August for multisigs whose keys are two COLDCARDs: at rest they are safe if the wallet configuration file is also secure, but in the mempool they are vulnerable to replace-by-fee sniping, so keys should be rotated by submitting the transaction directly to a miner via Slipstream rather than through public relay. R20 The at-rest half of that statement is the hidden-script condition described above, stated as one author's conclusion; the Slipstream half shares the mechanism, and the disclosed provenance, set out on the published migration guidance record.

Collaborative custody puts one key of a threshold in a provider's hands, and one captured post asks what this incident means for that key. A community post of 3 August noted Nunchuk's disclosure that the platform key in its 2-of-4 collaborative custody was generated with a COLDCARD Mk4 using a custom derivation path, and asked whether sweeps of such setups were beginning. R21 That is a question, not a confirmation of any loss: by the threshold logic above, one affected key in a 2-of-4 cannot sign on its own, and no drain of such a setup is recorded in the sources held here.

For a wallet whose security depends on an unpublished script, the first public spend removes that protection before confirmation. That does not mean the funds are lost; it opens a period in which public keys are available and any viable weak-key search can run against them. The submission routes and their limits are in the published migration guidance record.