Fuzz testing and Bitcoin Core... We received a pretty overwhelming response to our recent job post for a Bitcoin Core Fuzzing Internship at Brink. Brink received over 70 applications for the role with many qualified candidates. After the results of a coding challenge, we decided to actually move forward with two engineers for the 3 month role. Dongjia Zhang is a Ph.D. fuzzing researcher and maintainer of the LibAFL fuzzing library used to fuzz test Bitcoin Core. Stratos has a background in vulnerability research and will join Dongjia in working with Niklas (@dergoegge) in the coming months to enhance the fuzz testing capabilities in Bitcoin Core. Fuzz testing is the idea of throwing a bunch of quasi-random inputs at various functions of a codebase and seeing if anything abnormal happens. Think of it like mining for bugs. There is work in both the Bitcoin Core codebase as well as fuzz tooling (like fuzzamoto) in order to test more and more of Bitcoin Core in this way. Here is a bit more about fuzz testing in Bitcoin Core:
Niklas Gögge on Fuzz Testing
Niklas Gögge on Fuzz Testing.
 Here is a conversation we had with Matt Morehouse on fuzz testing the Lightning Network:
Matt Morehouse on Fuzz Testing the Lightning Network
Matt Morehouse presents the state of fuzz testing in Lightning.
 Marco (@macrohead7) recently completed his year long onsite fuzzing fellowship at Brink and provided some thoughts as well:
Marco
Marco De Leon recounts his experiences and accomplishments during his year long fellowship.
 Brink is proud to support the build out of further fuzzing capabilities in the Bitcoin Core codebase as well as other ecosystem softwares. We have not had intern roles before either and are excited to see how it works out. Welcome Dongjia and Stratos! image
The topic of non-developer contributions to Bitcoin and Bitcoin Core came up in a thread the other day. So I wanted to elevate this list, in case people are interested. Ways to contribute other than code: Education / Outreach Optech Conferences Saving Satoshi Fundraising Bitdevs User feedback Reproducing issues Priorities? Security Dependency auditing CVE disclosure Mailing list Pen testing Dev Tooling CI Signet Fuzzing Drahtbot Corecheck,dev Bitcoin dev wiki Mentoring Developer hubs Review clubs Release Process Testing guide Building binaries Signing binaries translations Packaging for distro Monitoring b10c stuff etc Standardization BIPs Bolts etc Events Coredev Online communication channels Mailing list Delving IRC Twitter / etc Stack exchange
Bitcoin Core
Bitcoin
Bitcoin
 Backups of stuff Dev Infrastructure Fuzzing Devops stuff Dns seeds User feedback Outward Talk to miners? Exchanges? Surveys Research BRW Janitor work Reproducing Other items listed: Coredev conference BIPs (review, reading) Stack exchange CI Fuzzer machines Devops Monitoring
Bitcoin Core
Bitcoin
Bitcoin
 maintaining/hosting Signet / inquisition Utilities for interacting with Bitcoin (Core) Educational stuff like saving satoshi Delving Mailing list Backup of delving/mailing list/github comments IRC and logs Drahtbot / meetingbot Bitcoinacks (?) Fundraising Developer hubs Review clubs Technical talks / podcasts / outreach Bitdevs Deterministic builds (running) Dns seed Dependency auditing/pruning Architecture CI doesn’t account for Reproducing issues Moderation of github Research Week Twitter threads Translations Security Security mailing list CVE management / disclosure etc Pen testing
corecheck - Test Coverage
 Core dev wiki Bitcoin wiki Summaries of communal knowledge Optech Release packaging for distros Janitoring old issues/PRs BOSS program Summer of Bitcoin Original:
Non-development Contributions
Many people, myself included, tout the importance of software maintenance in the context of Bitcoin Core. It is easy to throw out "maintenance!" and most people will nod their head in agreement, but I think its helpful to have some examples to understand the depth of this work and risks of not doing it. There are many categories of maintenance work, today I am just going to zoom in on one: minimizing dependencies. Recently someone attempted to put in a backdoor into XZ, a library used by softwares in hundreds of millions of computers around the world. Even a couple weeks ago hackers slipped malicious code into dozens of NPM packages that receive millions of downloads each week. Bitcoin Core and other Bitcoin software are not immune to these kinds of attacks. While Bitcoin Core has a robust culture of code review and testing, Bitcoin Core uses third-party libraries as well. Code from these libraries is run, in addition to Bitcoin Core's code, when you are running your node. Any bug, vulnerability, or performance issue in these libraries (dependencies) can cause issues for Bitcoin Core. Updates to these dependencies of Bitcoin Core are a potential risk and need to be regularly tracked and reviewed. From a security perspective, these dependencies should also be minimized and eliminated where possible. Bitcoin Core developers have spent years minimizing the number of dependencies of the project. In some cases replacing them with minimal, in-house alternatives that achieve the same function in order to reduce attack surface. In this latest Brink blog, we outline the risks of using dependencies as well as several examples of Bitcoin Core removing problematic or unnecessary dependencies of the project.
The importance of minimizing dependencies in Bitcoin Core
Relying on external code is a risk. We look at the work in Bitcoin Core to minimize these kind of dependencies.
Russell O’Connor joined Brink to explain his work on formal verification of software, the process of mathematically proving that a program satisfies its specification. - Overview of formal verification of software - Walkthrough w/ libsecp256k1 - Coq, Rocq, Clightgen - SafeGCD - Q&A
Russell O
Russell O