HELP

Building a new node, planning to run latest Bitcoin Core (25.0) - never read any code from bitcoin core until now.

Looks like a massive codebase. I have rudimentary knowledge of C language. I'm clicking through a few pages of the code, wondering how can I trust a codebase I don't fully know. I guess trust is inevitable? Even in a "trustless" system?

Just the fact that it is open source, and *someone* would be double checking the DEVS?

Because what if an organization paid off all the Devs at simultaneously to plant a malicious code line deep in the code, that intelligently sabotages the security or efficacy in some intelligent, genius way, to critically or catastrophically damage the network? This is massively more practical and dangerous than the classic, infeasible "51% sustained attack".

On github it looks like literally only a handful of contributors doing the Lion's share of commits. Isn't this the most practical potential weakness of bitcoin? How can we mitigate as plebs? Is the only way to dedicate ourselves personally to reading the full code and grokking it entirely, as well as every release?

Or just run the release on my node and "trust"? Fuck, man. Is it more important to have a full node running asap (now) to be "sovereign and decentralized", and move on with other important projects, despite not having the months/years of firsthand code verification to really know it is free from potential malicious lines?

Like who has actually read the full code and understood it to gauge the integrity, besides those full-time devs on github?

Any thoughts appreciated...

Reply to this note

Please Login to reply.

Discussion

How to cheat and get free Bitcoin by changing the code.

Step 1. Change the code to give you free Bitcoin.

Step 2. Convince 51 percent of Bitcoin miners to use your version of the code that gives you free Bitcoin, and makes their Bitcoin now worthless.

It has been done before. The Bitcoin Cash fork is what happens when you change the code. Bitcoin Gold, Bitcoin SV, are all results of changes to the code, done by people that thought their version of Bitcoin was better.

By the way, it's written in Go, not C.

Man you made my day. Thank you I had a much-needed laugh after struggling with my 2014 dell laptop and USB drive that won't run.

I guess I was the first one to think of Step 1 🤣

That makes me a special hacker-type right?

Free bitcoin sounds amazing, but man that would take away the value, it's true 😂!

First, the latest is v26

Second, I believe there are other implementations of Bitcoin (however I expect bitcoin core makes up >50% of the nodes, so a vulnerability in core would still be a huge risk)

Third, you don't have to read all the code to determine certain security properties. For example, lets say you are concerned with your private key being leaked. Just read the code that processes the private key. The code that validates blocks, doesn't matter for this purpose.

So you have to know what it is you are trying to prove, but then it becomes a much more managable task.

A quick search turned up this alternative bitcoin implementation: https://bitcoinmagazine.com/technical/btcd-a-full-bitcoin-alternative-written-in-go-1368114292

That's a good point, it would be magnitudes simpler to review just the pertinent security bits. Thank you DrHax

I'll check out btcd, I had thought that was a part of bitcoin core.

Just to be clear, I'm not recommending btcd because I don't have any experience with it, but I do think that having ecosystem diversity is a good thing.

I agree, I will most likely run bitcoin core v25. But that gave me a better understanding of what exists in terms of bitcoin software. Thanks.

Yeah, I used to run a practice and lead a team of people who did software security audits, so I've spent a good deal of time thinking about how to go through all the relevant code as fast as possible and make sure nothing was overlooked.

I appreciate it when:

I. Code is really small, or failing that

II. It's architected in a way that I can be confident that a failure in one part of the code won't affect another part of the code

You have such a deep pool of experience. I appreciate you sharing so much of it here with us on nostr and with your offline work devving.