Single signature means one key spends your coins. If that key is weak, the coins are gone.

Multisig requires M of N keys to sign. An attacker who breaks fewer than M keys cannot spend anything, which is why multisig survived this incident when the broken keys could not reach the threshold.

Multisig only helps if the affected keys are fewer than M. Three Coldcards in a 2-of-3 gives no protection here.

Not in any way that matters for break time. Each script type uses a different derivation path, so an attacker scanning all four costs about four times more than scanning one. That is 2 bits. Against a 40-bit gap it is nothing, and you should not treat an unusual script type as protection.

Where it does matter is what your wallet publishes once you spend:

• Legacy, nested and native segwit multisig reveal the entire redeem script when you spend, which means your M-of-N policy and every public key in the quorum become visible on-chain.
• Taproot key-path spends look identical to single signature. The policy stays private.
• Before any spend, all of them are just a hash and reveal nothing.

So a spent non-taproot multisig tells an attacker exactly how many more keys they need. It does not make the maths easier, it makes you easier to prioritise.

Enter each key separately. Mixing manufacturers is the whole point of multivendor multisig: one vendor's bug cannot take out the quorum.

• Seed created is when the recovery words were first generated, not when you bought the device. A 2019 device reseeded in 2023 is affected.
• Dice rolls bypass the flaw entirely. Coldcard hashes the rolls directly and never touches the failed generator. 50 or more fair rolls means this key is safe regardless of firmware.
• Passphrase is the BIP39 passphrase, sometimes called the 25th word. It is a separate secret from your recovery words.

Updating firmware fixes seed generation from that point forward. It cannot repair a seed that already exists, because the recovery words were already drawn from the broken generator.

The only complete fix is generating a fresh seed on patched firmware and moving the coins to it.

It does not change the break time. An attacker testing candidate seeds compares derived address hashes against the chain, and that works whether or not you have ever spent. Anyone telling you an unspent wallet is cryptographically safer from this bug is wrong.

What spending changes is privacy and how easily you are singled out:

• Spending links your addresses into one cluster, so cracking any single key exposes the whole balance rather than one output.
• A spend to or from a KYC exchange ties the wallet to your identity.
• Fee habits, change position and script type fingerprint your wallet software, which helps an attacker sort targets.
• Reusing an address publishes the public key and confirms the address is funded, turning you from a candidate into a confirmed target.
• For multisig on anything except taproot, spending publishes your whole M-of-N policy.

Practical migration hazard: if you have spent, change outputs may sit at deeper derivation indices. People move the obvious balance and leave change behind on the compromised seed. Sweep the whole wallet, not the visible UTXO.

An xpub (also seen as ypub or zpub) is your extended public key. A descriptor is the fuller recipe: the xpubs, the script type, the derivation paths, and for multisig the M-of-N policy. Neither can spend your coins. Both can generate every address you will ever use.

Why it matters for this incident. Cracking a weak seed produces a key with no name on it. The attacker still has to work out which wallet it belongs to. A published descriptor does that work for them: the link from wallet to addresses is already on the record, so a cracked key is matched instantly to a wallet whose balance is visible. It does not make the cracking any faster. It moves you up the queue.

For multisig it gives away more. A multisig descriptor contains every cosigner xpub and the threshold. An attacker who breaks two keys can read straight off it whether two is enough. That is the same information a spend would leak, except a published descriptor leaks it without you ever moving a coin.

The privacy cost is permanent and separate. Whoever holds your xpub sees your full balance, your history, and every future payment you receive. You cannot revoke it or rotate it. The only fix is moving to a new seed.

Examples of sharing, including the ones people forget:

• Pasting an xpub into a block explorer, portfolio tracker, or balance checker.
• Adding a watch-only wallet in a phone app or web service.
• Giving the xpub to an accountant, an auditor, or tax software.
• Saving a descriptor to iCloud, Google Drive, Dropbox, or a syncing password manager.
• Emailing or messaging a multisig descriptor to cosigners.
• Posting a wallet setup screenshot or a descriptor QR code in a support forum, Telegram, or Discord.
• Leaving a descriptor in a gist, pastebin, or a git repository.
• A multisig coordinator service holding your configuration.

Sharing a descriptor with your own cosigners is normal and unavoidable in multisig. The question is whether it also ended up somewhere public or on a cloud service. Tick the box if you are unsure, because the model treats unknowns as exposed.