Tracing the Attacker's Steps Through 1,082 BTC Coldcard Drain - Praveen Perera
stackernews-tracing-attacker-steps-praveen
- Organisation
- Stacker News
- Evidence role
- Community discussion
- Published
- 2026-08-14
- Source changes
- 0
- Detected differences
- 0
- Unreviewed
- 0
- Copies held
- 1
Scoresby links Praveen Perera's analysis of the 1,082 BTC Coldcard drain, focusing on 153 swept addresses that researchers have not been able to reconstruct seeds for. Perera describes a search effort covering 104 billion candidate seeds and 5.60 trillion address checks, and argues a missed derivation path is unlikely. Held as a dated technical follow-up on the attacker methodology and the remaining reconstruction gap. The claims and calculations are Perera's own and are not independently verified here.
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 .
This post is held twice: here, with this project's own note on why it matters, and again as part of the conversation captured at , which is polled for changes. Both copies are the same post; neither is a separate event.
Snapshot and diff bodies for this chain monitor are held in the local evidence archive but withheld from the public site because they can contain the addresses of people who published nothing themselves. Capture times and reviewed change summaries remain available below.
Held captures
-
Recovered from the Internet Archive rather than captured by this project. The row records that third-party provenance separately from captures made by this project.
What changed from the previous capture 0 lines
Extracted text as captured
{ "data": { "item": { "comments": { "comments": [ { "createdAt": "2026-08-14T11:14:13.411Z", "text": "# ~lol \n\n> I also suspect that whoever wrote the sweep code was more familiar with an account-based chain, such as Ethereum, than with Bitcoin wallet software. On Ethereum, ranking accounts by balance and sending one transfer per account is natural. The cost of a basic transfer does not depend on how many earlier deposits funded the account. Bitcoin value lives in separate UTXOs, so input selection affects the fee.\n>\n> The transaction pattern is consistent with an account-balance mental model and weak Bitcoin wallet handling. The sweep kept addresses from the same seed as separate jobs, spent a 294-satoshi input that added about 2,040 satoshis to the fee, and left a 0.16083170 BTC UTXO behind an unprocessed page.\n>\n> A weak-seed scanner naturally produces address records, and an address-based API encourages the same design.", "user": { "name": "0xbitcoiner" } }, { "createdAt": "2026-08-14T11:01:44.781Z", "text": "\n\n[source](https://x.com/KLoaec/status/2088209131731648928)", "user": { "name": "Scoresby" } }, { "createdAt": "2026-08-14T13:24:08.299Z", "text": "Maybe the 153 addresses was attacker ‘stealing’ from themselves? A sort of red herring?", "user": { "name": "fountainhead" } }, { "createdAt": "2026-08-14T12:19:53.662Z", "text": "the 153 addresses nobody can rebuild a seed for is the scariest part of this. the rest all trace to the same RNG flaw, so the attacker had another derivation path or another leak nobody's found yet. and it cost two hundred bucks of gpu time to map a thousand btc drain, that ratio is the whole story", "user": { "name": "fifoofa" } } ] }, "createdAt": "2026-08-14T10:55:15.778Z", "text": "This is a really great analysis of how the coldcard attacker went about identifying and sweeping funds. The author is the maintained of Cove Wallet, @praveenperera.\n\nThe most interesting finding is that there are 153 addresses that were swept in the first wave, but which no researcher has been able to reconstruct the seeds for. \n\n> All 153 transactions use the same builder as the recovered set. The difference therefore appears upstream of transaction construction: candidate generation, device state, derivation coverage, or the data used to select targets.\n> \n> The search history makes the gap more interesting than a normal incomplete scan.\n> \n> * Expanding BIP49 receive coverage past index 25 recovered a new Wave 1 seed at index 40.\n> * Searching nonzero BIP84 accounts recovered two more Wave 1 seeds.\n> * Checking more address indexes on both the receive and change branches recovered additional Wave 1 sources.\n> * Nine alternative Coldcard event traces matched new candidate seeds to historically funded addresses outside Wave 1 and reproduced already-known Wave 1 sources, but found no new source in the 153.\n> * Searches above the observed pad range, plus partial and evenly spaced tests across the full 32-bit pad range, found no new member of the 153.\n> * An independently reported full raw-pad search also found none, although its full artifacts are not public.\n> \n> Across the PRNG paths and address derivations I tested, I checked 104 billion candidate seeds and performed 5.60 trillion address checks, at a GPU cost of about $200. That search effort is why I think a missed path is unlikely, although a shared blind spot remains possible. \n\nPraveen also also notes that no other researcher he has spoken with has reproduced a seed from one of these 153 addresses. Clearly, there is some missing piece of information or non obvious method that the attacker had but that the researchers lack. \n\nPerhaps the information that allows researchers to figure out how the attacker swept these 153 addresses will reveal something about the approach that helps to identify the attacker. \n\nThe whole article is full of interesting observations and well worth the read. Here are a few highlights:\n\n> Once I had recreated the affected seed-generation process, I generated candidate seeds, derived their Bitcoin addresses, and compared those addresses with the Wave 1 transaction set. This linked 1,042 of the 1,195 sweep transactions to 328 reconstructed seeds. They account for 949.70395260 BTC, or 87.72% of the value. The final 153 transactions contain 132.94923662 BTC.\n> \n> No researcher I have spoken with has reproduced a seed for any of those 153 source addresses. That repeated failure may be the most useful clue about what the attacker knew or did differently. The last part of this post examines that gap.\n\n> * **The final 153 source addresses, containing 132.94923662 BTC, remain unexplained.** No researcher I have spoken with has reproduced a seed for any of them. They use the same transaction builder as the recovered set, so the missing difference appears to be earlier in the attacker’s process. Public reconstruction attempts may be missing an input or a candidate-generation method.\n\n> All 1,195 traceable source transactions have the same basic form:\n> \n> * transaction version 2;\n> * locktime 0;\n> * final input sequence `0xffffffff`, so no opt-in RBF;\n> * one destination output;\n> * one source address per transaction;\n> * a fee equal to 30 times the same static size estimate;\n> * no low-R signature grinding.\n> \n> The input order is more distinctive. There are 145 transactions with more than one input. All 145 spend the source address’s UTXOs from newest funding transaction to oldest. This is not BIP69 ordering, wallet coin selection, or the natural order produced by most general wallet software. It looks like an address API returned transaction references in reverse blockchain order and the sweep builder kept that order.\n\n> The results were still handled as separate address records. The 1,042 source transactions map to 328 seeds, with as many as 58 swept addresses from one seed. That behavior fits a process that derived standard paths, ranked addresses by balance, and saved address-and-key records without preserving the wallet as the unit of work.\n\n> I think the attacker used a paid blockchain-data API to discover balances and UTXOs, then signed the transactions with separate code. [BlockCypher](https://www.blockcypher.com/dev/bitcoin/#address-endpoint) is the closest technical match I have found. Its Bitcoin address endpoint returns newest records first, defaults to 200 records, and tells the caller when another page exists. For the address with 225 UTXOs, I reproduced the exact 200 selected UTXOs, in the same order, with the live BlockCypher endpoint. This makes BlockCypher my leading hypothesis for the UTXO-discovery step.", "title": "Tracing the Attacker’s Steps Through 1,082 BTC Coldcard Drain - Praveen Perera", "user": { "name": "Scoresby"Excerpt only. The complete copy is held offline and backs quotations on this site. The original publication remains the canonical public source.
0 presentation-noise differences. Sidebar, ticker and other page chrome churn that our review classified as not being changes to what the source says.
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.
Compare the screenshot or a quotation against the original while it is available.