Did AI find this bug?

Public discussion often combines two different claims: that AI helped people reproduce the vulnerability after disclosure, and that AI originally found it. The captured record supports the first as a reported event. It does not establish the second.

What Coinkite said

"we have to assume that someone used AI to review previous versions of our firmware" Coinkite, entropy technical backgrounder

The phrase "we have to assume" identifies the discovery claim as Coinkite's inference. The same passage separately reports that an earlier internal AI review did not find the defect. No model, transcript, prompt, discovery date or account from the original finder has been published in the sources held here.

NVK's later statement argued that AI-assisted review is accelerating discovery of latent defects and that public firmware should be assumed to receive both defensive and adversarial review. That is an attributed security position, not evidence about how this defect was originally found.

Early hypotheses about the operator

Kevin Loaec published an early hypothesis that the operator had asked an AI system to produce a brute-force and sweep script. The observation behind it was narrower: the visible sweep searched BIP84 paths, used limited derivation depth and sometimes found only part of a wallet. Those details can inform a hypothesis about the script, but they do not identify how it was written.

Dhruv Bansal's three-post response is held as part one, part two and the third instalment. It began with the human impact and community response, then described multi-vendor collaborative custody as protection against a single manufacturer or counterparty failure. The final post argued that Bitcoin, AI and computer security increasingly overlap, and advocated layered protections, redundancy and humans in the loop. Its reference to an attacker using an LLM is part of that broader warning, not independent evidence about the operator or the original discovery method.

Claim register

Discovery and reproduction are different tests

The defect was also discoverable by tracing the open-source call and link path manually. That establishes an alternative route to discovery, but it does not tell us which route the original finder used.

A worked human route to the same path

That alternative route stopped being hypothetical on 1 August 2026, when bitcoin++ Insider Edition published Dustin Dettmer's commit-history walkthrough. Working from the public repository, it reaches the board override, the disabled macro and the symbol the seed path actually calls, and it credits no model assistance. This archive checked its commit-level assertions against the pinned clones and found most of them exact, one dating claim unsupported and one cited commit not locatable; that adjudication is on the developer-response page.

The relevance here is narrow and worth stating precisely. A published human walkthrough demonstrates that the path was reachable by ordinary code reading, which weakens any argument that the defect was so obscure that only a model could have surfaced it. It says nothing about which route the original finder took, because it was written after disclosure with the faulty path already named. It moves the manual route from asserted to demonstrated, and leaves the discovery question exactly where it was.