This was pointed out on Twitter as well. It’s true.

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

http://bitcoincore.org

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

http://bitcoincore.org 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

http://Corecheck.dev

Core dev wiki

Bitcoin wiki

Summaries of communal knowledge

Optech

Release packaging for distros

Janitoring old issues/PRs

BOSS program

Summer of Bitcoin

Original: https://btctranscripts.com/bitcoin-core-dev-tech/2025-02/non-development-contributions

I’m saying people like myself “throw out” (use) the term “maintenance” but we rarely discuss what it actually encompasses.

Gloria has been at Chaincode for about 6 months.

This post is about minimizing dependencies

This post isn’t about op_return

And we don’t fund Gloria

The English parts were mine. The “cctools-port, libtapi, and ld64 to llvm binutils and lld” parts were you know who

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.

https://brink.dev/blog/2025/09/19/minimizing-dependencies/

Apologies for this being late. We ran into technical troubles during the first recording attempt

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

https://brink.dev/blog/2025/08/07/eng-call-russell-oconnor-formal-verification/

Jameson Lopp and Tim Ruffing on quantum

Steven Roose on the OP_TEMPLATEHASH soft fork bundle

David Gumberg on compact block prefilling

Lauren Shareshian from Block on mempool fee estimation

nostr:note1m07vc6tgzecf3u2rahygyau5rn9xv65kcwcfv3lylxgats9r5hqsc27wma

One year ago Marco De Leon embarked on a year long Brink fellowship in our London office. Today, after a year of progress and contributions, we’re happy to bring him on as a full-time Bitcoin Core engineer!

"The idea of diving into a codebase as critical and complex as Bitcoin Core’s was intimidating, and frankly, I was a bit worried I didn’t have enough experience to contribute meaningfully. The fellowship provided the perfect bridge..."

https://brink.dev/blog/2025/07/31/marco-fuzzing-fellowship/

Marco, with guidance from his mentor Niklas Gögge, focused his fellowship on fuzz testing, a technique for catching subtle bugs and security vulnerabilities.

https://brink.dev/blog/2023/07/14/fuzzing/

His work took him from improving existing fuzz tests, to removing the longstanding mainnet checkpoints, to improving type safety in the Bitcoin Core codebase.

We are proud of Marco and Niklas for their efforts this past year. Bitcoin is more secure because of Marco's contributions and Bitcoin is stronger with another experienced engineer working on security into the future.

If you're interested in fuzzing and a career as an open source Bitcoin engineer, like Marco, we are pleased to offer, in addition to the fellowship, a new Bitcoin Core Fuzzing Internship at Brink

Join us and contribute to Bitcoin security through fuzzing!

https://bitcoinerjobs.com/job/1801236-bitcoin-core-fuzzing-internship

The CTV and CSFS open letter segment got a little spicy with some real talk

We really dug in on Tadge's commit/reveal scheme for quantum as well

nostr:note1qrea0l73j8c7cdhx07cyvnn5j7rew6jy5y3xsh33htuxnpz064vqe92kra

Also, glozow has an extended checklist that builds on that release process:

https://github.com/glozow/bitcoin-notes/blob/master/release_checklist.md

What is Bitcoin Core's release process for managing release candidates, minor releases, and major releases?

Bitcoin Core's Release Process doc:

https://github.com/bitcoin/bitcoin/blob/master/doc/release-process.md

Eric Voskuil joined Bitcoin engineers to discuss architectural and performance differences between libbitcoin and Bitcoin Core:

- libbitcoin’s history/latest updates

- libbitcoin architecture

- Initial block download (IBD) performance

- IBD workflow

- SwiftSync

- Q&A

Watch the 90 minute discussion:

https://brink.dev/blog/2025/06/17/eng-call-eric-voskuil-utxo-model/

Bad bot

Optech's "Changing Consensus" monthly segment always makes for an interesting recap podcast

nostr:note1leu6c9ld9kyjwpuggy269vzqfgqeps5a3zlgwgqr23z0wez3966slzl6p8

I think Optech has done a great job of surfacing and summarizing "RTFM"-type content from from the mailing list, github, delving, etc. But two points on that:

1. There are communications/informations that Optech wouldnt typically cover that could still be valuable for a wider audience. In the OP_RETURN skirmish example: information around moderation policies, who are the moderators, what is a "BAN", etc.

2. As Bitcoin grows, the Optech content becomes less accessible or even reachable for the "average" Bitcoiner and Optech summary content itself becomes "RTFM" in need of translation for a wider audience.

I agree with your thoughts, and am really just adding my $.02 on the "has been adequately disseminated" point.

What do you suggest?

Anyone that can help amplify signal would be valuable!

There is a lot going on in the OP_RETURN debate, but I definitely agree with this:

"What the OP_RETURN debate has demonstrated is that Bitcoin Core and the Bitcoin technical community have not done a good job communicating their value – not to mention the rationale behind their decisions – to the average bitcoin user."

https://blockspace.media/insight/op_return-debate-the-influencers-vs-the-devs/

The Bitcoin Core developers have produced artifacts and content on these matters already, but those of us closely observing need to do a better job of disseminating that information to a broader set of Bitcoin ecosystem participants.

"The single biggest problem in communication is the illusion that it has taken place."

I need to do better.