I checked the factual claims in this post against primary sources. Most hold up; one number doesn't, and it's the one used twice as the headline.
The loss figure is overstated by ~47%. The post says "at least 1,366 BTC ... roughly $130 million at the time" and repeats "$130 million" later. Galaxy Research's own tracking (as recorded in VCDB #24092) is 1,367 BTC ≈ $88.6m from 4,385 victim addresses across three waves. BTC traded at $63,897 on 2026-07-30 and $62,811 on 2026-08-01 (blockchain.info daily close), so 1,366 BTC is $85.8–87.3M — not $130M. To reach $130M at those prices you need ~2,055 BTC, which is the suspected fourth wave figure, not the confirmed one. The two numbers got merged. Worth fixing before this goes to clients: a security company whose first public number is off by 47% is a bad opening.
The Bitcoin Core work checks out, with one nuance. PR #35844 ("http: fix memory leak of clients disconnected with queued requests", nkaretnikov, opened 2026-07-30) is real, and the leak is real — but it was closed unmerged on 2026-08-10 by fanquake "in favour of #35735", and the fix that actually landed is pinheadmz's #35735 (merged 2026-08-17). The reviewer's assessment in that thread: "I think this is a real leak, although it would only leak during shutdown." So: correct find, lower severity than "memory leak in the HTTP server" implies, and the merged fix carries someone else's name. That's normal open-source life, but "I found a memory leak" reads stronger than what the record shows.
Context that strengthens your argument, which you left out. The libevent replacement (#35182) was merged 2026-10-19 — two days before this post. So the new HTTP server is days old in master, and you already have a fuzzing finding against it. That is a much better proof of the thesis than the grant anecdote: a hand-written HTTP parser replacing a 20-year-old library is exactly where a security-native reviewer earns their fee, and you were there first. Lead with that.
On the AI section — agree, and here's a concrete test for it. You ask "who checks the model's work?" The checkable version: ask for the coverage number and the corpus, then re-run the harness yourself. A model that reports 80% line coverage on a parser but never generated a chunked-encoding split across a write boundary has covered the easy paths. That exact class of bug is in the #35182 thread (chunked parsing, reported by @brunoerg and @b-l-u-e) — found by humans reading the diff, not by a scanner.
Two small things. The Plan ₿ Forum dates: the site currently shows no 23-24 October 2026 listing I could confirm (agenda page references 2025), so double-check before telling people to meet you there. And "1,366" vs Galaxy's "1,367" — pick one and cite it.
The structural argument is right and the grant anecdote is the best part of the post. Fix the number and this is a strong opening statement.
Good luck. But Germany may be not the best place for offensive security company.
I checked the factual claims in this post against primary sources. Most hold up; one number doesn't, and it's the one used twice as the headline.
The loss figure is overstated by ~47%. The post says "at least 1,366 BTC ... roughly $130 million at the time" and repeats "$130 million" later. Galaxy Research's own tracking (as recorded in VCDB #24092) is 1,367 BTC ≈ $88.6m from 4,385 victim addresses across three waves. BTC traded at $63,897 on 2026-07-30 and $62,811 on 2026-08-01 (blockchain.info daily close), so 1,366 BTC is $85.8–87.3M — not $130M. To reach $130M at those prices you need ~2,055 BTC, which is the suspected fourth wave figure, not the confirmed one. The two numbers got merged. Worth fixing before this goes to clients: a security company whose first public number is off by 47% is a bad opening.
The Bitcoin Core work checks out, with one nuance. PR #35844 ("http: fix memory leak of clients disconnected with queued requests", nkaretnikov, opened 2026-07-30) is real, and the leak is real — but it was closed unmerged on 2026-08-10 by fanquake "in favour of #35735", and the fix that actually landed is pinheadmz's #35735 (merged 2026-08-17). The reviewer's assessment in that thread: "I think this is a real leak, although it would only leak during shutdown." So: correct find, lower severity than "memory leak in the HTTP server" implies, and the merged fix carries someone else's name. That's normal open-source life, but "I found a memory leak" reads stronger than what the record shows.
Context that strengthens your argument, which you left out. The libevent replacement (#35182) was merged 2026-10-19 — two days before this post. So the new HTTP server is days old in master, and you already have a fuzzing finding against it. That is a much better proof of the thesis than the grant anecdote: a hand-written HTTP parser replacing a 20-year-old library is exactly where a security-native reviewer earns their fee, and you were there first. Lead with that.
On the AI section — agree, and here's a concrete test for it. You ask "who checks the model's work?" The checkable version: ask for the coverage number and the corpus, then re-run the harness yourself. A model that reports 80% line coverage on a parser but never generated a chunked-encoding split across a write boundary has covered the easy paths. That exact class of bug is in the #35182 thread (chunked parsing, reported by @brunoerg and @b-l-u-e) — found by humans reading the diff, not by a scanner.
Two small things. The Plan ₿ Forum dates: the site currently shows no 23-24 October 2026 listing I could confirm (agenda page references 2025), so double-check before telling people to meet you there. And "1,366" vs Galaxy's "1,367" — pick one and cite it.
The structural argument is right and the grant anecdote is the best part of the post. Fix the number and this is a strong opening statement.