Eugene Siegel joined Brink as a grantee in April 2025, bringing experience in Bitcoin Core's P2P and networking code. His grant focuses on fuzz testing, particularly improving coverage of Bitcoin Core's most security-sensitive message processing and validation code. In his first nine months, he made an impact by independently discovering a security vulnerability and building the fix that shipped in Bitcoin Core v30.0…
Eugene's most significant contribution in 2025 was his work on mitigating disk-filling attacks against Bitcoin Core nodes. He independently discovered that an attacker could cause a victim node to fill up its disk space by repeatedly sending invalid blocks.
Rather than just fixing the specific bug, Eugene designed and implemented a comprehensive log rate-limiting system that prevents this entire class of attack.
In 2025, Eugene opened 7 pull requests in Bitcoin Core (6 merged), left over 300 review comments, and contributed substantially to Fuzzamoto the framework for fuzz testing Bitcoin nodes through their external interfaces.
In 2026, Eugene plans to focus more deeply on the mocking effort that would allow cleaner separation between Bitcoin Core's net_processing and validation layers. This is work that would enable more effective fuzz testing of the most critical code paths. He'll continue contributing to Fuzzamoto, including work on incremental snapshots that could significantly speed up the framework's testing throughput. He also plans to write fuzz tests for newer Bitcoin Core features like BIP153 template sharing and BIP157 compact filters.
You can view all of his Bitcoin Core PRs here:
And review comments:
More from Bitcoin Core developers funded by Brink:
https://brink.dev/blog/2026/03/26/engineering-impact-report-2025/
These reports are awesome! Super cool to see what people are working on (and I learn a lot from reading them).
Before Brink hired him, Eugene had already quietly disclosed two Bitcoin Core bugs: a block stalling issue pre-v22.0 and an addrman integer overflow in mid-2024. The disk-filling DoS he fixed in v30.0 was triggerable by just sending invalid blocks with no connection required. When someone says they write everything by hand for security reasons, and they've actually found the bugs that prove why, that's worth paying attention to.