schmidty's avatar
schmidty 3 months ago
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.

Replies (13)

schmidty's avatar
schmidty 3 months ago
The English parts were mine. The “cctools-port, libtapi, and ld64 to llvm binutils and lld” parts were you know who
BitcoinIsFuture's avatar
BitcoinIsFuture 3 months ago
I don't think people "throw out "maintenance!"". People throw out a change. OP_RETURN changing from 83 Bytes to 100 000 Bytes is a change. Its not a dependency either. In my opinion this change is not only bad, its mallicious. What it definitely has are weak arguments from Core. And some related bad actions from Core too. That is why I switched to Bitcoin Knots. And just for context for the people who read this, Brink is the entity that financially supports Gloria Zhao / GLACA. Glaca supports this change with arguments that ...
Damn bro why do you act like we are retarded? This is a really childish attempt to mix up bug fixes with changes that allow litteral CSAM distribution.
schmidty's avatar
schmidty 3 months ago
This post is about minimizing dependencies
BitcoinIsFuture's avatar
BitcoinIsFuture 3 months ago
Alright. Then I am just saying that people who are against OP_RETURN change do not "throw out "maintenance!"". Brink does not fund Gloria?
Lets be brave now and say it together: op-return should not be blown open so that we protect bitcoin's monetary mission against CSAM attacks.
schmidty's avatar
schmidty 3 months ago
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.
dope. i love learning about historical development decisions like these. please write more like these. and as always, thank you!