Bitcoin Core Chief Code Maintainer: 3 Plans to Decentralize Bitcoin Development

Note: The original author is Wladimir van der Laan, the current chief maintainer of the Bitcoin Core project. Regarding the recent turmoil caused by the deletion of the Bitcoin white paper by Bitcoincore.org, he said that he felt a lot of pressure and would try to gradually get rid of key decision-making roles and participate more in behind-the-scenes development work. In addition, he also proposed some plans to improve the decentralization of Bitcoin development.

Recent events have made me reflect on a number of things. Additionally, the responses on social media have made me realize that people have strange expectations of me and what my role in the Bitcoin Core project is.

The growth of Bitcoin

Bitcoin has evolved a lot since I started contributing to it in 2011. Some acceptable arrangements for a small FOSS project running a $600 billion market cap system no longer exist. Market cap is very misleading, and I'm not interested in specific numbers.

One thing is clear: this is a serious project and we need to start taking decentralization seriously.

keep going

I realize that I am a centralization bottleneck, and even though I think Bitcoin is a very interesting project and believe it is one of the most important things going on right now, I also have many other interests. This makes me feel stressed, and I don't want it, and I don't want to get into weird arguments on social media, I want to define myself as a person.

Decentralize power

I will start by delegating my own tasks and reducing my involvement. I don’t plan to stop contributing to Bitcoin or even the Bitcoin Core project, but I want to move away from a key role and do more behind the scenes work.

Note that we have had a nice increase in development activity, and maintenance of the code itself has been going on among multiple people for a while. I'm not the most active maintainer at the moment. You can look at the number of git merges over the past year.

bitcoin$ git log --pretty="format:%cn" --merges --since=2020-01-01 | sort| uniq -c
313 fanquake
51 Jonas Schnelli
727 MarcoFalke
7 Pieter Wuille
65 Samuel Dobson
363 Wladimir J. van der Laan

Last year, only about 24% of merge work was done by me.

plan

However, I think there are still many things that need to be solved:

1. Decentralized Release

1. In the short term, move bitcoincore.org to an organization rather than private ownership to reduce the “bus index”.

2. I think it would be nice if some other organization set up a mirror so there's less motivation to try to shut down bitcoincore.org.

3. In the long run, it is necessary to completely get rid of a website for code releases. Because whoever owns the website can shut it down with just the click of a button, and it seems that the global Internet is preparing to make censorship easier and easier. We need a decentralized network. One option for us is IPFS, which is starting to become popular. For the binary itself, there is already an option to download it through torrents.

2. Decentralized release process and release signature

1. Authorize more parts of the release process. Other maintainers should be able to release the Bitcoin code without my involvement.

2. Rename the GPG key used to sign SHA256SUMS.asc to "Bitcoin Core release signing key" instead of my personal title. Make some construction so that N out of M (minimum) trusted gitian signers who successfully build, automatically generate signed distributions.

3. The same is true for native code signing on Windows and macOS.

4. In the long run, it may be better to split the keys, for example via RSA threshold signatures, so that the whole process can be distributed across different geographical locations.

3. Decentralized development centers

1. It's not clear whether github can be trusted to represent our interests in the long run. Although issues and PRs are backed up via the API, moving them elsewhere could severely disrupt development. Also, jumping from one provider to another would be bad, and ideally the whole process wouldn't need to rely on a central server at all. To that end, I've been keeping an eye on the radicle project, a P2P distributed code collaboration platform that, while not fully implemented yet, seems promising.

Some of the requirements here at Bitcoin are very different from other open source software projects, so we had to develop some tools. Of course, we also needed some help.

Some small issues to consider:

1. Find someone else to replace me as IRC meeting chair, or rotate it among multiple people.

2. Release (and release candidate) mails posted to the bitcoin-dev and bitcoin-core-dev lists will no longer be signed and sent by me.

3. I host a few development-specific tools (like IRC and the PR notification bot on mastodon). Since they are non-critical and I have very little time to maintain them, I'm fine with that for now.

As for the decentralized Bitcoin node software itself:

1. Carl Dong's libbitcoin_kernel is working. Bitcoin Core is a large monolithic project that includes the consensus code, which is more critical than other parts. The kernel will be an isolated part with a well-defined interface and, at some point, its own change review process. The difference from the previous libbitcoin_consensus plan is that the kernel is stateful: it includes UTXO management and validation. But it does not include P2P, storage pool strategy, wallet, GUI, and RPC code. It can be reused in different clients to allow for more diversity in clients, but without the risk of deviating from the consensus implementation.

This is what I will focus on with Bitcoin Core over the course of 2021.

Original text: https://laanwj.github.io/2021/01/21/decentralize.html

Author: Wladimir van der Laan

Compiled by: Satuoxi