Bitcoin Fog operator’s conviction upheld without Chainalysis disclosing source code
The September 25 ruling relied on corroborated Reactor testimony and a case-specific failure to justify source-code access. Read the full story on CryptoSlateUnderstand the crypto stories that matter and what to watch next. Get The Catalyst in your inbox
The Bitcoin Fog appeal upheld expert testimony based on proprietary wallet tracing, with explained methods and corroboration supporting its admission. Roman Sterlingov’s effort to obtain the software’s source code failed on the record presented to the courts.
Blockchain analysis company Chainalysis drew attention to that result in October 13 commentary, presenting it as further validation of its Reactor software. The judgment itself came on September 25, when the D.C. Circuit affirmed Sterlingov’s convictions and 150-month sentence for operating Bitcoin Fog, a service that mixed users’ bitcoin to obscure transaction trails.
The decision matters because it explains how proprietary analysis became usable courtroom evidence and why this particular disclosure challenge failed. Its reasoning keeps three questions separate: whether expert testimony is reliable enough to admit, whether addresses have been attributed correctly, and what that evidence establishes about a person.
Related ReadingUnder Federal Rule of Evidence 702, the party offering a qualified expert must demonstrate, more likely than not, that the testimony will help the fact-finder, rests on sufficient facts or data, uses reliable principles and methods, and reflects a reliable application of those methods to the case.
Daubert supplies considerations for that reliability inquiry, including testing, peer review, known or potential error rates, and general acceptance. The appeals court explained that these considerations are flexible and nonexhaustive.
The appellate posture also matters. The panel reviewed admission of the testimony for abuse of discretion, recognizing the trial judge’s latitude both in deciding how to assess reliability and in reaching a reliability determination.
FBI witness Luke Scholl and Chainalysis analyst Elizabeth Bisbee testified that Reactor clustered and attributed more than 900,000 Bitcoin addresses to Bitcoin Fog.
The opinion describes three kinds of clustering heuristics, or inference rules. Co-spend clustering treats addresses used together as transaction inputs as being controlled by one person or entity. Behavioral clustering looks for matching transaction patterns, including change-address behavior and digital fingerprints. Intelligence-based clustering adds information from sources such as data leaks, court documents and data partnerships.
The prosecution’s case also contained evidence beyond clustering. The opinion recounts IP-overlap analysis, Sterlingov’s earlier activity concerning mixers and darknet promotion, financial records, and Bitcoin Fog’s cessation of operations shortly after his arrest.
Related ReadingBoth Reactor witnesses acknowledged that the software had not been peer-reviewed and that they did not know its error rate. The panel nevertheless found other markers of reliability: the witnesses’ experience, comparisons with information obtained later through legal processes, use by law enforcement and private-sector specialists, explanations of the methods, and corroboration.
Two checks deserve particular care. First, the opinion cites a government contractor’s confirmation that Reactor correctly clustered and attributed 99.9% of a large group of addresses in another case. The opinion supplies that percentage without a complete public sampling design. Its stated scope is those addresses in that other case; using it as a product-wide error rate would expand the result beyond that scope.
Second, Scholl checked five known addresses used by Bitcoin Fog during the government’s undercover transactions. Reactor’s Bitcoin Fog cluster contained four. Sterlingov characterized the result as a 20% error rate, but the panel accepted the trial court’s explanation that Reactor was conservative and underinclusive for the purposes of this case.
Missing a known service address and wrongly assigning an unrelated address to that service are different errors.