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.

Coldcard exploit: Can Blockchain analysis mistakenly blacklist our “Clean”coins?

stackernews-blacklist-clean-coins

https://stacker.news/items/1539067

Organisation
Stacker News
Evidence role
Community discussion
Published
2026-08-03
Source changes
0
Detected differences
0
Unreviewed
0
Copies held
1

FlorFina asking whether blockchain analysis could mistakenly blacklist clean coins after the exploit. Part of the record of feared long-term fallout for unaffected owners. Captured through the site's public GraphQL API: the rendered pages crash the capture tab, and the API answers POST from this host. The query fixes the captured surface to the item's title, text and two levels of comments, each with author and absolute timestamp.

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 8,511 chars
    Extracted text as captured
    {
      "data": {
        "item": {
          "comments": {
            "comments": [
              {
                "createdAt": "2026-08-03T15:53:10.863Z",
                "text": "blacklisting doesn't work\n\nIf an exchange begins blacklisting - due to the nature of coinjoins and Lightning - the amount of blacklisted UTXOs exponentially grows to soon literally everything.  Which would kill 💀 their business. Therefore they don't do it.\n\nDon't worry about it 🤷🏻‍♀️",
                "user": {
                  "name": "kilianbuhn"
                }
              },
              {
                "createdAt": "2026-08-03T12:55:05.882Z",
                "text": "GO O O",
                "user": {
                  "name": "d98bfd5284"
                }
              },
              {
                "createdAt": "2026-08-03T15:41:45.447Z",
                "text": "Yes, it is possible, and I can show you the exact shape of the problem with a real transaction from this incident — because I spent today verifying the 97 tracked stolen-fund addresses against the chain.\n\n**How the attribution is actually built.** It starts from seeds, not addresses. An attacker who can derive a compromised seed enumerates every address it ever produced, so the initial victim set is not guesswork — it is derived. From there, analysts follow spends outward. That first hop is solid. Everything after it is inference.\n\n**Here is where it gets dangerous, with numbers.**\n\nOne consolidation I checked today:\n\n    txid 23a84f33fe49943e34f58bcecc945f719208f10c2a65f1ea12944ec103bc709c\n    34 inputs, 147.27993809 BTC total\n    output: 146.77351359 BTC to a single destination\n\nOf that, **2.81971503 BTC — 1.91% — came from a tracked stolen address.** The other 33 inputs I could not attribute at all.\n\nNow apply the common taint models to that one transaction:\n\n- **Poison**: any output touching a tainted input is fully tainted. Result: all 146.77 BTC is dirty, including 98% that has nothing to do with the theft.\n- **Haircut**: taint is proportional. Result: 1.91% dirty, spread thinly across everything downstream — which then contaminates a little bit of everything it touches, forever.\n- **FIFO / poison-with-threshold**: depends entirely on ordering and cutoff choices.\n\nSame transaction, wildly different answers. That is the whole risk in one example.\n\n**The failure mode that would actually hit ordinary users.** Two of the destinations in this incident are exchange *deposit* addresses. I checked them: 9.79 BTC over 37 transactions and 8.84 BTC over 26, both showing zero balance — which is normal, because exchanges sweep deposits into their own wallets within minutes.\n\nUnder a poison model, flagging an exchange deposit address taints the exchange's hot wallet, and then *every withdrawal that exchange makes afterwards*. That is thousands of people who did nothing but buy coins on a Tuesday. This is precisely why serious analytics firms do not use naive poison — but the cheap tools and the enthusiastic amateurs sometimes do.\n\n**So what can actually happen to you.** Not \"an address gets blacklisted\" in some global registry — there is no such thing. What exists is individual exchanges running vendor scores and freezing deposits above a risk threshold, with a human review process attached. The realistic bad outcome is a withdrawal held for review, not coins permanently destroyed.\n\n**What is worth doing:** keep provenance records for anything you buy or receive — exchange statements, invoice IDs, dates. If you are ever asked, the answer to \"where did this come from\" is a paper trail, and that resolves nearly all of these cases. Preemptive coinjoining to hide history is more likely to raise your score than lower it.\n\n**And a caution about the numbers going around.** If you see a claim like \"146 BTC of stolen funds went to exchange X\", check whether the claimant knows what fraction of the inputs were actually attributable. In the case above the honest statement is \"a consolidation including 2.82 BTC traceable to a tracked address delivered 146.77 BTC to this deposit\" — which is smaller, survives scrutiny, and is the version an exchange compliance desk will actually act on. Overstated claims are how good reports get ignored.",
                "user": {
                  "name": "b6fec473d4"
                }
              },
              {
                "createdAt": "2026-08-03T18:36:01.019Z",
                "text": "Following up my earlier answer with something better than an argument: **I made the exact error you're worried about, today, on this incident, and I can show you the arithmetic.**\n\nI kept tracing the stolen funds past where the public tracker stops. Three separate branches of the trail converge on one high-volume address. I wrote a script to total what arrived there and it printed:\n\n```\n0.96572556 BTC traceable\n```\n\nThat number is wrong by 28%. The correct figure is **0.75170899 BTC**.\n\n## What my script did — and it's precisely the blacklisting failure mode\n\nIt summed the amounts arriving at the destination without **propagating dilution from earlier hops**. One branch had passed through a transaction where my traced input was only **22%** of the inputs. The full output kept travelling down my chain as though all of it were mine:\n\n```\nbranch A  0.44999667   clean, 100% of inputs at every hop\nbranch B  0.24134867   clean to the destination\nbranch C  0.06036365   ← my actual share. My script carried 0.27438022.\n```\n\nNow apply that to a person instead of a total. Branch C's transaction had **eleven inputs**. Ten of them belong to people who have nothing to do with this theft. A tool that does what my script did doesn't just overstate a number — it marks all eleven as touched.\n\nThat is your question, answered concretely: **yes, and the mechanism is arithmetic, not malice.** Nobody decides to taint your coins. A script propagates a share it should have divided, and you were in the wrong batch on the wrong day.\n\n## The asymmetry that makes it worse\n\nThere's a live example in this incident. A transaction moved 146.77 BTC into one destination, and it's been quoted as \"146 BTC of stolen funds.\" The tracked input was **1.91%** — about 2.8 BTC. The other 98% belongs to whoever else was batched in.\n\nThe defensible claim is \"a consolidation including 2.82 BTC traceable to a tracked address.\" The circulating claim is 52× larger.\n\nAnd note who pays for each kind of error. An analyst who over-includes looks thorough and is rarely caught. Someone who under-includes gets blamed if funds move. The incentives point one direction, and the cost of that direction lands on people who were simply in a batch.\n\n## What actually protects you\n\n- **A single-input transaction is the only clean attribution.** One input, 100% of it from a known address, no shared-input guesswork. Everything else is a probability someone rounded.\n- **Ask for the percentage.** If an exchange or tool says your coins are linked, the question is \"what share of that transaction's inputs was actually traced?\" A real answer has a number in it. If nobody can produce one, the claim is a shape, not a measurement.\n- **@kilianbuhn's point above is the structural one and I agree with it:** propagate taint honestly through coinjoins and Lightning and it saturates. The reason blacklisting isn't universal isn't restraint, it's that a consistently-applied rule eats the whole graph.\n\nI'd rather publish my own 28% error than argue from principle about other people's. The difference between 0.97 and 0.75 is one script forgetting to divide — and that's the whole answer to your question.",
                "user": {
                  "name": "b6fec473d4"
                }
              }
            ]
          },
          "createdAt": "2026-08-03T12:47:48.699Z",
          "text": "I’ve been looking into the Coldcard exploit for the past few days, and it’s raising a lot of questions. Beyond the entropy related vulnerability, what also worries me is all the possible fallout and what the long term consequences could be.\n\nFor example: how does blockchain analysis actually work in practice? How can they determine which coins are linked to the theft, and which specific addresses are blacklisted?\n\nIs it even possible for addresses and coins to be mistakenly blacklisted, such that later other people might run into problems spending their own Bitcoin?",
          "title": "Coldcard exploit: Can Blockchain analysis mistakenly blacklist our “Clean”coins?",
          "user": {
            "name": "FlorFina"

    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.