Multisig and miniscript · COLDCARD entropy incident

Affected keys do not automatically defeat a threshold wallet. An attacker must recover enough signing keys to satisfy a spending path. The relevant count is the number of affected keys on that path, compared with its threshold.

Threshold check If fewer affected keys exist than the threshold, recovering only those keys is insufficient to sign. If the number meets or exceeds the threshold, 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. That is an attributed migration recommendation, not a measured recovery time for every wallet. 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 that 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. That does not necessarily disclose the complete witness script. Spending still requires the exact script, an equivalent descriptor, or enough policy, ordering, derivation and key data to reproduce the output commitment. 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. 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.

Address reuse is not script publication Receiving more than once to a P2WSH address does not by itself reveal the witness script. A previous spend or disclosure of the complete descriptor or script removes the construction barrier. An exposed individual co-signer xpub can remove the target-hiding benefit for that signer without revealing the other keys or the complete script.

flowchart TB
  Q["Affected keys on spending path"] --> BELOW{"Fewer than threshold?"}
  BELOW -->|"yes"| INSUFF["Affected keys alone\ncannot satisfy path"]
  BELOW -->|"no"| TARGET{"Affected key targets exposed?"}
  TARGET -->|"yes"| SEP["Test exposed affected keys\nseparately"]
  TARGET -->|"no"| JOINT["Search keys as part of complete\nscript reconstruction"]
  SEP --> SCRIPT{"Complete script or construction\ndata also available?"}
  SCRIPT -->|"yes"| SPEND["Recovered threshold may satisfy path"]
  SCRIPT -->|"no"| BARRIER["Recovered keys alone do not\nreproduce output commitment"]
  JOINT --> MOVE["First spend reveals complete script\nplan migration route"]

This flow describes conventional P2WSH. Taproot and miniscript policies can expose different information on different spending paths.

Illustrative lower-scenario arithmetic

These examples use Block's conditional low-search scenarios, 2^32 candidates per Mk4-class key and 2^16.3 per Mk2/Mk3 key. They assume independent per-device candidate spaces and complete knowledge of the relevant derivation paths. Neither assumption has been measured across a population of wallets.

Illustrative search spaces under Block's conditional scenarios

Illustrative search spaces under Block's conditional scenarios
Arrangement	Target information	Full candidate-space expression	Interpretation
2-of-3, three Mk4-class keys	complete script hidden	`2^96`	Product of three `2^32` spaces to reproduce the complete three-key script, if the spaces are independent.
2-of-3, three Mk4-class keys	complete script and affected key targets known	`2 × 2^32 = 2^33`	Full upper bound for exhaustively searching two designated keys. Expected average work under uniform candidate positions is approximately `2^32`.
2-of-3, three Mk2/Mk3 keys	complete script hidden	`~2^48.9`	Product of three `2^16.3` spaces under the same independence assumption.
2-of-3, three Mk2/Mk3 keys	complete script and affected key targets known	`2 × 2^16.3 = 2^17.3`	Full upper bound for two designated key searches. Expected average work is approximately `2^16.3`.

Coinkite's upper scenarios and LLFOURN's published model produce much larger values. An exact time-to-recovery cannot be assigned to a wallet from its threshold alone. Device model, timing knowledge, descriptor custody, derivation paths and possible correlation all affect the result.

Descriptor and correlation assumptions

Descriptor custody matters. Coordinators and backups commonly store the information 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 normal Mk4-class boot path derives a reseed value from each device's secure elements, but the source code does not prove statistical independence across devices. Mk2/Mk3 UID and timing inputs may also be correlated for devices initialised under similar conditions.
Miniscript must be assessed by path. Recovery of enough keys for a primary multisig path may or may not satisfy timelocked or recovery paths. The policy, not the product label, determines the threshold.
Taproot key-path spends differ from script-path spends. A key-path spend does not publish the underlying script tree, while a script-path spend reveals the selected leaf and control block.

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

Migration implication

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 automatically lost. It creates a period in which public keys are available and any viable weak-key search can run against them. The practical options and their limitations are covered in migration planning.