pull down to refresh

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.
21 sats \ 1 reply \ @carter 19 Sep
Knots is entirely dependant on Bitcoin Core
reply
Sssh
reply
From a security perspective, these dependencies should also be minimized and eliminated where possible.
this ^
reply
Indeed. Bitcoin is literally money so the stakes are higher than pretty much any project ever.
reply
Nice text, we need a more debian approach and less arch towards bitcoin. Maybe not a great analogy, but I mean thinking a lot more of what there's inside and slow to change/upgrade with new features and modernity.
reply
Spot on—maintenance might not be the sexiest part of software dev, but it's the glue holding everything together, especially in something as critical as Bitcoin Core. Those XZ and NPM scares are wake-up calls that hit way too close to home. Kudos to the devs for chipping away at those dependencies; it's like decluttering your digital garage to avoid hidden tripwires.
Back in the day, Bitcoin Core ditched its heavy reliance on OpenSSL (post-Heartbleed nightmare in 2014) by rolling their own super-efficient library called libsecp256k1. Not only did it shrink the attack surface, but it also sped up signature verifications by a whopping 4-7x in some cases. Talk about turning a risk into a win! Keep fighting the good fight...
reply
I think the OpenSSL -> libsecp256k1 effort is a great example. Hard to articulate how much work it was to make libsecp256k1. The recent natpmp feature rewrite is another example, even if not as intense.
reply