Coldcard, the Media, and the Anatomy of AI Retardation
stackernews-media-ai-anatomy
- Organisation
- Stacker News
- Evidence role
- Community discussion
- Published
- 2026-07-31
- Source changes
- 0
- Detected differences
- 0
- Unreviewed
- 0
- Copies held
- 1
Aeneas on the media coverage of the incident and AI-generated commentary, engaging with Coinkite's technical backgrounder. Opinion and media criticism, attributed to the author. 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 .
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-01T09:31:18.711Z", "text": "I think the AI attribution to finding the error is largely correct. \n\nI use LLMs to prescreen new releases of software I use for a very extensive list of patterns and sometimes, when there is a really big change, to make end-to-end comparisons of a section of a diff to help me save some time on trying to understand what is going on here. In this latter process, without even too much specification of that process on any of the modern agentic models, including the open ones, will absolutely flag up an unactivated new feature. Signal is a great example of an app that enables new features in their libraries and then for a few weeks may not use it in the actual app. Happens often. It means I can go easy on review if something isn't activated and wait a bit until it is used on a hot path.\n\nBefore I built this framework with LLMs, this whole process was very hard for me to do and a massive time sink. I often wasted time on not-yet activated features and had to revisit and re-review thousands of lines of code for a second or third time when such features finally got activated. That is now a lot easier because I have much better documentation thanks to the new process. The LLMs are both what enables me to keep doing this but are bottom line also an optional feature. If my set of apps was smaller, or my review speed much higher, I could do the same thing without LLM, if I just kept the process around the reviews. The LLM saves time, but also triggered me to make a better framework - especially because as little as 3-4 months ago, I got a lot more false positives and there were lots of obvious things it missed, so I needed a refinement process.\n\nSince I reviewed this code back in my manual age, because I was in fact using a coldcard, I know this code. Looked at it deeply more than once. I did not figure out this error. I am also quite sure that an LLM would find it in 1-shot when asking the right question, can probably be a one-liner: \"draw a schematic of how the sources of randomness across secure elements integrate\" -> BINGO. That's a 3 minute job for an LLM. It will likely even tell you that there is an entire branch of code that is not integrated in a nice little italic formatted markdown sentence.\n\nWhy this was an attack: either no one asked this question, or no one read the slop output. That's all this took. This is low hanging fruit. If this attack being orchestrated by an LLM-empowered person of poor morality worries you, hold on to your nuts because this was cheap, easy and even a poorly executed attack. It can and will get much worse on the technical side, but hopefully not catch as many victims on the implementation side. I also think that this cheap and easy attack has completely destroyed coinkite, perhaps permanently.\n\n----\n\n> This threatens to shift the 'moral of the story' toward something useless, instead of the more pertinent issue of how Bitcoiners use and treat hardware wallets\n\nI agree with you that the shifting of attention is both unnecessary and not the right thing to do. My conclusion is different though: we cannot count on just because something being open source, that it gets actual eyes. We do have a problem that is bigger than shifting blame to AI. The problem is that we have review debt on Bitcoin software and firmware and that we're counting too much on efforts of others that simply are fictional. Wishful thinking.\n\nDespite nvk not being the person to bring this news, especially not now; do not be arrogant. Yes, there needs to be a human to tell the AI what to do, what to look at. The only way to make sure it gets done is to do it yourself.", "user": { "name": "optimism" } }, { "createdAt": "2026-08-01T00:17:38.624Z", "text": "Agree, this is \"dog ate my homework\" level stuff.\n\nAnd *even if* the attacker did use AI to discover the vulnerability, this was *not* some super duper hidden vuln that required a super duper powered AI to find out.\n\nI think the AI narrative is painting a very misleading picture about the nature of this bug.", "user": { "name": "SimpleStacker" } }, { "createdAt": "2026-07-31T23:52:08.860Z", "text": "Aaand the Bitcoin Magazine fucks are now joining into the AI narrative, replete with their own slop image. \n\n\n\nAgain, what's the source AI has fuck all to do with this? Just complete speculation in CoinKite's blog post that conveniently shifts blame off themselves. \n\nThe reason we don't have nice things, in my honest opinion, is because even during serious times when we should be talking about things seriously but calmly, we're surrounded by retardation like this.", "user": { "name": "Aeneas" } }, { "createdAt": "2026-08-01T00:37:25.297Z", "text": ">but I'm not surprised Coldkite's AI gave their code a greenlight because AI tends to fuck up a lot\n\nHahaha! This is absolutely fact!!\n\nBecause these days everything is about AI. \n\nBitcoin podcasts talk more about AI than Bitcoin. People are convinced 13 year olds vibe coding video games is going to lead to some sort of economic productivity boom!", "user": { "name": "BlokchainB" } }, { "createdAt": "2026-08-01T04:11:36.219Z", "text": "I agree that pinning this on AI is a massive red herring.\n\nThe inputs were not even pseudo-random. On a low-cost processor, pseudo-randomness might be obtained by plucking from a table of numbers aboard the MCU. The numbers [or more accurately binary strings] would be seemingly random, but recycled. Bad enough.\n\nAlthough, in this case, it looks like many Coldcard wallet users seem to have ended-up with seeds were substantially generated using the Serial Numbers (MCU UID's) of individual Coldcard devices. It therefore follows that persons with knowledge of these Serial Numbers (which may or may not be sequential) would have a very significant difficulty advantage in brute-forcing private keys that correspond to known UTXO addresses.\n\nLooks a bit like bug-dooring.\n\nI reckon that if this is investigated properly, there's a non-zero chance of some recovery of funds. Probably a good idea for affected users keep hold of their devices, since the MCU ID's could potentially be useful.\n\nSolicitor-client privilege applies in all Canadian provinces, so if somebody has important info, or has done something that they regret, they can go to a solicitor for a coffee and a confidential chat...\n\n", "user": { "name": "anon" } },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.