Author: Juan Galt
Source: https://bitcoinmagazine.com/print/the-core-issue-the-role-and-history-of-bitcoin-core-maintainers
In the beginning, there was only Satoshi Nakamoto and a strong idea. Satoshi Nakamoto started developing Bitcoin no later than 2007 , and as far as we know, it was developed entirely by himself until October 31, 2008—a few weeks after he released the Bitcoin white paper—when Satoshi Nakamoto brought in the first contributor to the project, Hal Finney.
Subsequent events revealed that Finney was crucial to Bitcoin's initial success. According to recently disclosed Email 4 , Satoshi Nakamoto's node was unable to receive "inbound connections" for several days after mining the genesis block, making Finney's node the only one other users could connect to. Satoshi Nakamoto told Finney in a private email, "Your node receiving inbound connections was a major factor in the network surviving the first day or two."
Finney was also the first known reviewer and contributor to the Bitcoin code. Before the software was fully released, Satoshi Nakamoto shared it with Finney and a handful of legendary cypherpunks. Even before the first version of the Bitcoin project was released, Finney had already contributed code—as disclosed by Ray Dillinger, who also received unpublished code from Satoshi Nakamoto.
Dillinger's blog features an interview with Nathaniel Popper. In the interview, Popper says, "That was when we started discussing floating-point types in accounting code, and I learned that Finney was also involved. Finney was reviewing the scripting language for transactions at the time, and his code, my code, all interacted with the accounting code."
This description roughly aligns with the oldest known Bitcoin project archive on the SourceForge code platform—Satoshi Nakamoto added Finney to the project on December 18, 2008. Nakamoto's decision marked the first instance where "Maintainer" level permissions for the project could potentially be held by someone else. Finney could, and very likely could, obtain developer status for the Bitcoin project on the SourceForge platform, thus enabling him to download, modify, and upload new versions to the project.
So, besides being a code contributor, code reviewer, and node operator, is Hal Finney also a maintainer of the Bitcoin project?
The strictest definition of a "maintainer" is someone who has "commit permissions" (or write permissions) on the main development branch of a software project. For projects like Bitcoin, contributors can "submit" code to the project's development branch and send "PRs" (merge requests) to integrate that code into the main branch. However, these updates can only be "merged" into the main branch through the maintainer 's "commit permissions"...
Based on this definition, Finney can be aptly called the first maintainer after Satoshi Nakamoto. However, to become a maintainer of Bitcoin Core, simply having commit privileges is not enough; one must have a good reputation in the developer community and also be a diligent and capable contributor.
Translator's Note: Roughly speaking, Satoshi Nakamoto created the "Bitcoin" project on the Sourceforce platform, which was the first Bitcoin node client. After Nakamoto left, the existing code was migrated to the GitHub platform, and the project name was changed to "Bitcoin Core." As can be seen from the original text, the author does not emphasize this distinction, and actually treats both as the same project, consistently using the term "Bitcoin" to refer to it, rather than specifically referring to the former project (or the former period). Therefore, "Bitcoin Core" is used here simply to indicate that the requirements for maintainers increased later on.
The maintainers of the Bitcoin project are sometimes active developers who are well-known to other maintainers and seem well-suited for the role; but at other times, they are active code reviewers who simply merge code contributions that seem to have reached a consensus and refuse to merge code that has not reached a consensus.
Conversely, maintainers have become a prestigious figure in the Bitcoin industry, but they are also easily tarnished by mistakes. Sometimes, prominent maintainers are considered corrupt by other maintainers and their privileges are revoked, such as Gavin Andresen 7 , who vouched for the fraudster Craig Wright as Satoshi Nakamoto. Other times, maintainers resign to avoid targeted harassment, such as Gregory Maxwell 8 .
In general, contributors expect the maintainers of the Bitcoin project to be engineers, not politicians. For example, on the discussion pages of various PRs on GitHub, people expect discussions to focus on specific technical and implementation details mentioned in the code, rather than the person who initiated the commit, their political views, or loyalty. Discussions involving consensus and controversy that could spark heated debate typically move to the Bitcoin mailing list and other forums, as do political topics.
The key point is that, throughout Bitcoin's history, the power held by the "maintainers"—regardless of the specifics—has arguably shrunk steadily as the project has grown since Satoshi Nakamoto's inception. There have even been instances where code had been merged into the main branch only to be removed again during subsequent reviews—demonstrating that the maintainers' decisions are no longer final.
Throughout Bitcoin's history, maintainers have sometimes been accused of acting as gate keepers, refusing to incorporate updates supported by one segment of the community—often partly because another segment of the community opposes them. In these cases, the maintainer role does possess a difficult-to-quantify "taste-making" power—determining whether a code commit has achieved consensus.
The exclusive power to decide whether or not to merge (some code) may be absolutely necessary and unavoidable for open-source projects, because if anyone can merge any code at any time, the project cannot be considered safe and stable. In a hostile environment, an elite system that reviews code solely based on its ideas and value is arguably the best model we can pursue; any other option is an authoritarian political system.
Unfortunately, information about the early stages of the Bitcoin project is extremely scarce, leaving us with only a glimpse into Hal Finney's role before the genesis block. In open-source software development, the history of maintainer permissions is very opaque. Platforms like Sourceforge and GitHub do not publicly disclose the history of commit permissions or detailed member permissions. The fact that Satoshi Nakamoto added Finney to Sourceforge is a very rare occurrence in the history of Bitcoin's maintainers.
However, version control systems like SVN and Git, while implemented weeks after Bitcoin's first release, did track code commits and project branch history for public review, providing us with publicly available information about what happened. As a result, our knowledge of Bitcoin project maintainers' history often comes from their first and last commits to the main branch, announcements on Bitcointalk (or other) forums, and (extremely rare) news of active maintainers revoking their permissions. A large portion of this article is based on Bitcoin Core maintainer Ava Chow's historical records.<sup> 10 </sup>
The ability to track commit permissions (or maintainers) was improved in 2014: the Bitcoin Core project added a "trusted public key" system¹¹ , which included a whitelist of PGP public keys that could commit code to the main branch. Public keys could only be added to or removed from this list by merging code with active maintainers; and all code committed to the main branch was signed (with the corresponding private key), which could be publicly verified by anyone—by comparing the signature of the software with the corresponding PGP public key.
The Trusted Public Key System was added by Matt Corallo as a security measure. He told Bitcoin Magazine that this feature is the result of a general process of improvement and optimization, not a response to any particular stimulus or event.
A Brief History of Bitcoin Core Maintainers: The Satoshi Nakamoto Era
On January 3, 2009, Satoshi Nakamoto mined the genesis block 13 of the Bitcoin network, effectively pushing this electronic currency into public testing. In this block, he added a message—a headline from a British national daily newspaper: “The Times 03/Jan/2009 Chancellor on brink of second bailout for banks”—anchoring and timestamping the birth of Bitcoin to the physical world. This headline, forever etched on the Bitcoin blockchain, serves as a subtle yet enduring reminder of Bitcoin's mission.
On January 8, 2009, at 2 PM, version 0.1.0 of Bitcoin software was released and announced on multiple forums (including the "Cypherpunks" mailing list). Satoshi Nakamoto wrote in the announcement: "Announcing the first release of the Bitcoin software; a new electronic cash system that uses a peer-to-peer network to prevent double-spending. It is completely decentralized with no server or central authority."
In the initial release of Bitcoin, the version installable on Windows was compiled by Satoshi Nakamoto, and its source code was also placed in a .rar compressed file and released on SourceForge.net. This action naturally positioned Satoshi Nakamoto as the founder and primary maintainer of the Bitcoin project—a role naturally associated with open-source software projects. During Bitcoin's development, Nakamoto would obtain code submitted by other developers, download it to his own system, review and merge the code, and then create a new release—this final task, distinguishing maintainers from contributors, persisted throughout the entire history of the Bitcoin project. This workflow continued until Satoshi Nakamoto's passing in October 2010, influencing versions 0.1.0 to 0.3.19 of the Bitcoin software.
Following its initial release, Bitcoin received numerous updates. In late January 2009, a third developer officially became a contributor to the project. Martti Malmi, using the username "sirius-m," created the "first commit" on Sourceforge, bringing the SVN source code version control system online. SVN, similar to Git, was a popular version control system at the time. Malmi committed the code to the "Trunk" branch, similar to the "master" branch on GitHub, thus becoming the second official maintainer in the history of Bitcoin's open-source development. In 2009, Malmi also made many other contributions, including the first Linux version of Bitcoin , release 0.2.0 .
In August 2010, Lazloh Hanyecz—yes, the guy who became famous for spending 10,000 BTC on a pizza in 2010—joined as another maintainer, a month after he contributed Bitcoin's first iOS version to the 0.3.0 release.
As the lead maintainer, one aspect of Satoshi Nakamoto's role was (literally) managing the entire network. Nakamoto privately asked Lazloh—the first person to use a graphics card (GPU) to mine Bitcoin blocks—to slow down his mining speed to accommodate the network. "The longer we postpone the GPU arms race, the more mature the OpenCL library will become, and the more people will be able to use OpenCL-compatible graphics cards," Nakamoto told Lazloh in 2009,19 attempting to extend Bitcoin's CPU mining era. At that time, Bitcoin's future was completely uncertain, and mining was the primary incentive for running Bitcoin nodes.
On July 17 , 2010, Bitcoin version 0.3.2 was released. Satoshi Nakamoto added the "checkpointing system" as a security measure, which hardcodes a hash value as the valid hash value for a given block height. Its purpose was to prevent the blockchain from being reassembled and deepened to the point of overturning the "widely accepted blockchain" (Satoshi Nakamoto's original words in the announcement) under miner attacks (theoretically, this is possible). Nakamoto added, "There's no need to retain the non-zero possibility of being able to modify it again after a few months; it's unpopular."
The checkpoint system gave future maintainers a new responsibility—to decide which block height and its winning hash to hardcode in future releases; this was the case back when Gavin Andresen led the Bitcoin project.23 This checkpoint system was eventually phased out because proof-of-work made deep refactoring infeasible.
Satoshi Nakamoto's immense power as the maintainer and founder of the project was fully demonstrated in the numerical overflow bug incident in October 2010: at that time, three transactions created 184 billion BTC that did not exist (and should not have existed). This transaction attempted to move such a huge amount that the transaction verification code at the time "overflowed during the summation," thus breaking the consensus.
Translator's Note: The author's description here is vague and incorrect. In reality, a single transaction created this amount of BTC, which was received by three addresses (one of which was a miner's address in a Coinbase transaction). The transaction verification code at the time simply subtracted the sum of the output amounts from the sum of the input amounts; as long as the result was positive (indicating that the input amount was greater than the output amount), it passed. However, the output amounts were too large, and the sum exceeded the number that could be represented by a fixed length, resulting in a negative number. Therefore, regardless of the input amount, it would always pass verification. From a technical perspective, it did not break consensus (causing the network to split into mutually exclusive parts). See the author's footnote for details.
This is the most famous bug in Bitcoin history, sometimes called the "inflation bug," and arguably the most dangerous vulnerability to the project's survival. Many community members noticed the transaction just hours after it was mined and alerted Satoshi Nakamoto to take action. With the help of several contributors (including Andresen ), Satoshi Nakamoto created Bitcoin patch version 26 , changing the relevant verification code.
Satoshi Nakamoto instructed miners to migrate to this patched version and resynchronize blockchain 27 , resulting in the entire network rolling back to its state before the invalid transaction was confirmed. This was a hard fork, reversing Bitcoin blocks mined within the previous 19 hours. This likely represents the pinnacle of centralization within the Bitcoin project under Satoshi Nakamoto's leadership, and the culmination of concentrated power in the maintainer's role.
Following the "numerical overflow bug" incident, Satoshi Nakamoto implemented the "Alert System" 28 in version 0.3.11. This system—and somewhat controversial—would display a warning and disable basic functionality on nodes at critical risk. This alert system could only be triggered by a message signed with a key that only Nakamoto possessed. He argued, "It's better to be scared by a brief downtime when your node is at risk if you don't pause than to be scared by a thief having already stolen all your investment." A few months later, Nakamoto disabled this alert system in his final release.
According to SVN records, only Satoshi Nakamoto ever merged code from other contributors and pushed official releases of Bitcoin , at least until Gavin Andresen became the lead maintainer on December 19 , 2010. As early as February 30 of that year, Andresen directly contributed code to Nakamoto; and on October 11 , he made his first commit to the Trunk branch of SVN. A few months later, Nakamoto released his last version of the Bitcoin project: 0.3.19 , and then disappeared from history.
As of the time of writing, more than 1,200 people have contributed code to the Bitcoin Core project.
Gavin Andresen era
With Satoshi Nakamoto ceasing contributions to the project, Gavin Andresen became the sole active contributor with commit privileges. As Andresen increased his involvement, Malmi slowed down, making Andresen the de facto lead maintainer. While Satoshi Nakamoto never publicly announced handing this role over to Andresen, he did send an email to Mike Hearn (an active contributor at the time ) , containing the famous quote, "I have other things to do. Gavin and the others will get this done."
"With Satoshi Nakamoto's blessing," 34 Andresen took over as head of the Bitcoin project maintainers, expanded the maintainer team, and began migrating from Sourceforge to GitHub 35. This process took considerable time. It wasn't until July 14, 2011, that we saw the first commit, a branch from Andresen's official GitHub account, merged into the Bitcoin project 36 , marking the completion of this process.
Unlike the Satoshi Nakamoto era, this merge was completed through the GitHub platform. This essentially entrusts GitHub.com with a degree of trust, assuring them they won't tamper with the code; previously, this process was manually performed by Satoshi Nakamoto on his own machine. It's worth noting that regardless of the method or whether GitHub is involved in the merge, the differences between the different versions of the code are auditable because the project itself is open source. In this era, code merges can be reviewed by developers at both ends of the process before and after the GitHub merge (something roughly), although this thorough caution ultimately led to the creation of a trusted public key system. However, this still initiates a new trend, determining how Bitcoin projects will merge code for at least the next three years.
On September 13, 2011, the Bitcoin project on the SourceForge platform was officially shut down, with GitHub becoming the new collaboration platform. The old Bitcoin project page became an archive. Because Malmi and Lazloh primarily contributed code on SourceForge and did not have GitHub accounts at the time, their commit permissions effectively ended with this official migration. Furthermore, with Satoshi Nakamoto's departure, their contribution frequency decreased.
On April 27, 2011, version 0.3.21 was released, the first version under Andresen's leadership. It was also the first version to include a "Readme" file containing a PGP-signed message detailing the updates, the released installation files and hashes, and expressing gratitude to the contributors. Among the 16 nominated contributors were some well-known Bitcoin Core developers, such as Luke Dashjr, Matt Corallo, Pieter Wuille, and Jeff Garzik.
In the following years, perhaps to distribute the power and responsibility Gavin had gained through the maintainer role, and to fill the void left by the departure of Satoshi Nakamoto, Malmi, and Lazloh, several new maintainers emerged. Chris Moore, using the name "dooglas," had commit privileges from January 21, 2011 to March 31 , 2011; and has remained a contributor to the project ever since.
A few months later, on the first day of June 2011, Pieter Wuille gained commit privileges . Wuille had discovered Bitcoin in 2010 and quickly began contributing code to the project. After gaining commit privileges, Wuille gradually became a prominent Bitcoin Core developer, earning respect for his numerous small performance improvements, significant cumulative improvements to the user experience, and many other contributions. To this day, Wuille remains the third most prolific contributor to Bitcoin Core, and his GitHub username is " sipa ".
Jeff Garzik became a maintainer a few days later (June 6th). Garzik had been contributing code to the Bitcoin project since version 0.3.21 and later became a well-known Bitcoin developer. He brought his experience from the Linux open-source ecosystem to the Bitcoin project. Garzik is often praised for improving the stability of Bitcoin clients.
Years later, in the summer of 2016, after "months of inactivity," Garzik's commit privileges were revoked (according to Chow's documents). During the years when the Bitcoin "block size war" was heating up, Garzik sided with the upgrade to larger blocks ; the block size war caused much debate and friction among some members of the Bitcoin community, which may have been one reason for his reduced development activity. Later, a year after the war broke out, Garzik also led a failed fork movement, the version number "Segwit2x".
Translator's Note: To help readers understand the "number of commits" metric that appears repeatedly in the context, some explanations are added here.
Version control systems like Git and SVN treat a software's codebase as a repository whose state can be continuously changed, which is the foundation for their support of distributed development. Developers constantly add and delete code, which means they are constantly changing the state of the codebase; and each state change is marked with a "commit" (which is a hash value).
As mentioned earlier, in open-source development projects (which are distributed by definition), people push for updates to the original codebase by "forking" the codebase, modifying it locally (forming a new commit), and then sending a "Pull Request (PR)" to the original codebase.
To facilitate parallel work, codebases often form multiple "branches". Furthermore, these pull requests (PRs) may undergo further modifications after being issued (resulting in new commits); finally, once a PR is approved, the maintainer merges it (containing multiple commits) into the main branch (this merge also creates a commit).
Therefore, the so-called "commit count" counts the number of times a user has participated in modifying the codebase state, not the number of pull requests (PRs). This is why the author mentions that many maintainers' commits are primarily merges (from other people's PRs). In other words, this number reflects the depth of a person's involvement in development, not the number of code changes they initially proposed.
On July 5, 2011, Mara van der Laan (then known as "Wladamir") gained commit privileges, becoming the eighth official maintainer of Bitcoin Core. Van der Laan had been active on the Bitcointalk forum since November 2010 and began contributing to the Bitcoin project in May 2011, initially focusing on the graphical interface of the Bitcoin QT client, and bringing with him extensive academic experience in computer graphics. <sup>48 </sup>
On September 19, 2011, Nils Schneider (using the pseudonym "tcatm") gained commit privileges after frequently contributing to and optimizing the Bitcoin client's background performance. During his time as maintainer, he made significant contributions to the client's internationalization: adding several updates related to multilingual support <sup>49</sup> ; overseeing the removal of the "Crypto++" dependency library, reducing unnecessary dependencies<sup> 50 </sup>. Nils served as maintainer for approximately one year, with his last commit being issued on March 31, 2012<sup> 15 </sup>
On February 11 , 2012, Gregory Maxwell (using the pseudonym "gmaxwell") first merged the code. Prior to this, he had contributed numerous code entries and actively participated in technical commentary on the Bitcointalk forum for a full year . This marked the beginning of his three-year career as a maintainer. During this period, Maxwell focused primarily on the client-side P2P networking layer, as well as work related to consensus mechanisms and verification. To this day, he enjoys high respect within the broader Bitcoin community and occasionally participates in technical discussions and debates. Maxwell relinquished commit privileges in December 2015: as the block size war intensified, his support for small blocks led to widespread online harassment.
The Bitcoin Core maintainer team continued to expand over the course of a year. On September 27, 2012, Gavin announced the next phase of his personal vision for the future of Bitcoin: the "Bitcoin Foundation." This foundation, modeled after the Linux Foundation—a prime example of Gvain's vision of the Linux operating system as a successful large-scale open-source project—attracted much attention and support, but also drew considerable criticism. In the announcement, Gavin stated, "I want the Bitcoin Foundation to be an open, member-driven organization, and I hope that you and your organization will not only be members, but also help the Foundation achieve its mission." Over the next few years, the foundation helped pay the salaries of many Bitcoin Core contributors and maintainers.
Mara van der Laan era
In April 2014, Mara van der Laan was chosen by Gavin Andresen as his successor to lead the Bitcoin Core maintainers role, as Andresen had decided to transition to a more academic role, which he termed "Chief Scientist." In a blog post on the Bitcoin Foundation website, Andresen stated, "Mara van der Laan has been working full-time for Bitcoin Core for several months now, receiving payment—thank you again to all the Foundation members for stepping up and funding the development of Bitcoin Core—and has been doing an excellent job. He has agreed to succeed me as the 'Bitcoin Core Maintainer.'"
From then on, Ven der Laan, using the names "Laanwj" and "wumpus," led the development of Bitcoin Core for nine years. To this day, he remains the person who has submitted the most code to the "bitcoin" codebase (7419 times according to GitHub statistics—the vast majority of which were code merges). According to Chow's records, "for personal reasons," Ven der Laan resigned from his maintainer role in February 2023.
When Ven der Laan became a maintainer, the first change he brought (and one of the most significant) was the implementation of the aforementioned trusted public key system, committed by Matt Corallo on December 20 , 2014.58 This system helped address the opacity of the maintainer's role by adding a file containing PGP public key fingerprints (along with a series of related tools) 59 to the main branch of the "bitcoin" codebase. One tool ensured that the maintainer's commits were PGP-signed, while another script could verify the signature of the commit against a list of trusted PGP public keys.
Because these public keys are contained in the main branch of the codebase, only maintainers can add and remove public keys from the manifest (with a valid signature). This leaves a record in Git's version control system. We can also use PRs to add and remove maintainers, and contributors can comment on the PR page.
On November 13, 2015, Jonas Schnelli, using the username "jonasschnelli," gained commit privileges. Van der Laan granted him the role of maintainer for the GUI library and announced it in the bitcoin mailing list. Schnelli had been contributing code to Bitcoin since 2013, becoming one of the top 10 contributors to the Bitcoin project on GitHub; many commits appear to have been made while he was a maintainer, merging code for the repository. He served as a maintainer for six years before relinquishing commit privileges on October 21, 2021; he posted on Twitter showcasing his experience and expressing strong confidence in the future of the Bitcoin developer community.
According to Corallo, the primary role of trusted public key systems is to "avoid trusting GitHub" when merging developer code—a common practice during the Andresen era. Afterward, maintainers would merge code locally and then update the repository.
Translator's note: In terms of form, there are two projects on the Github website: (1) the "Bitcoin" project, which includes the "bitcoin" library (which can compile code for
Bitcoin Coresoftware) and the "BIPs" library; (2) the "Bitcoin Core" project, which includes the "GUI" library mentioned above (which can compile a graphical interface version ofBitcoin CorecalledBitcoin QT), as well as other code libraries.
On April 13, 2016, Marco Falke (username "maflcko") gained commit privileges . Van der Laan announced this decision in the Bitcoin mailing list, stating, "Here I announce Marco Falke as the new 'Testing & QA' maintainer for Bitcoin Core." Falke continued contributing code to Bitcoin Core until 2023, when he relinquished commit privileges and maintainer status for personal reasons.
Less than a month later, on May 6, 2016, Gavin Andresen's commit privileges were removed. This decision was made by Van der Laan, 65 after Andresen endorsed Criag Wright (who is now widely known to be an imposter of Satoshi Nakamoto). At the time, many in the Bitcoin community had already doubted Wright's claims, and Andresen's stance was quickly revealed to be a result of Wright's deception. A few months earlier, Mike Hearn, a contributor to a Bitcoin project considered to have close ties with Andresen, had advocated on a podcast that Andresen should revoke the commit privileges of all other maintainers, becoming a "benevolent dictator" of the Bitcoin project, 66 as many other open-source projects had already done. Andresen did not heed Hearn's advice, but this incident highlighted the tense atmosphere within the Bitcoin community. As the block wars began, Wright also became involved.
Years later, Andresen expressed regret over these events, saying, "I now know it was a mistake to trust Craig Wright so much. I regret getting involved in that 'find out who is (and who isn't) Satoshi Nakamoto' game. I'll never play it again."
Many years later, another contributor gained commit privileges. On December 4, 2018, Samuel Dobson (username "MeshCollider") was nominated by Van der Laan as a maintainer of the wallet module. Dobson had been contributing code to the Bitcoin project since at least the summer of 2017, and during his career as a Bitcoin developer, he made over 300 commits, primarily focusing on the Bitcoin Core wallet module. To pursue his PhD, Dobson relinquished his commit privileges and maintainer role in February 2023.
On June 7, 2019, Michael Ford gained commit privileges; he was among the first of the latest generation of maintainers still active today. Ford's username is "Fanquake," and he was possibly the first contributor to gain commit privileges through internal consensus (nominated at a Bitcoin Core developer conference in Amsterdam). Following this period, commits based on contributor consensus became a trend, indicating a move towards decentralization in Bitcoin project development; meetings were held in numerous locations and environments , even via IRC (Internet Chat Rooms).
Ford has been contributing code to the Bitcoin project since February 2012, making him one of the most senior maintainers in the project's history. According to GitHub, Ford has 4920 commits, ranking second in terms of the number of commits to date; many of these commits are merging and maintaining updates from other contributors.
Contributor Consensus Era
On January 21, 2021, Van der Laan published a blog post (73) that broke with the tradition established by Satoshi Nakamoto and Andresen—by appointing a maintainer lead for Bitcoin Core development. In this post, Van der Laan stated that she would gradually delegate many of the maintainer lead responsibilities to others, explaining that Bitcoin had become such a large project that the model established by Satoshi Nakamoto and Andresen was no longer feasible, and that it was time to decentralize Bitcoin Core development.
Van der Laan outlined a series of responsibilities that others should bear and provided a roadmap for making the Bitcoin project's software release process more censorship-resistant. Examples include transferring ownership of the Bitcoincore.org website to an organization rather than having it under her control, while encouraging the creation of mirror sites; distributing new versions of installation files via torrents (or even IPFS); questioning Github.com and calling for the search for alternative code contribution platforms; a threshold signature scheme for use among maintainers, allowing them to sign release versions through some form of cryptographic consensus, rather than having one person be the final PGP signer for a version; and so on.
This article actually marks the end of Van der Laan's role as the lead maintainer and is a milestone symbolizing the maturity of the Bitcoin project, just months after the release of version 0.20.0 and days before the release of version 0.21.0.
Hannadii Stepanov (username "hebasto") gained commit privileges on March 19, 2021, becoming a maintainer of the Bitcoin client's GUI library. Stepanov had been contributing code to Bitcoin Core since August 2018, accumulating over a thousand commits before becoming a maintainer, ranking him 5th on GitHub for Bitcoin project commits, with a total of 2070 commits to date. Stepanov is still a maintainer at the time of writing.
Ava Chow gained commit privileges (77) on December 12, 2020, becoming a maintainer of the wallet module; she has been contributing code (78 ) since January 2016. Her username is "achow101," and she is a well-known contributor to the Bitcoin development community, whose contributions extend beyond GitHub commits to include extensive historical research on the Bitcoin Core maintainers. Chow is also known for live-streaming her Bitcoin Core code review (79) on Twitch; this stream attracted a considerable audience and promoted Bitcoin technology education. Chow ranks fourth on GitHub with 2198 commits and still possesses commit privileges at the time of writing.
Gloria Zhao gained commit privileges on August 7, 2022, and was nominated by the contributor consensus ( number 80) . Her role is trading pool strategy maintainer (number 81 ). Zhao began contributing code in March 2020 and committed at least 200 times before gaining commit privileges. She is currently ranked 9th with 777 commits. Zhao remains a maintainer today.
Russ Yanofsky gained commit privileges on June 10, 2023 (83) , nominated by contributor consensus (84) , and his role is interface maintainer. Russ specializes in modularity and multithreaded work, which earned him the maintainer role. He has been contributing code since October 2016 (85) , with a total of 970 commits to date, ranking 7th. Yanofsky's username is "rynofsky," and he remains a maintainer.
References
1. https://www.metzdowd.com/pipermail/cryptography/2008-November/014863.html ↩
2. https://Nakamoto.nakamotoinstitute.org/emails/cryptography/1/ ↩
3. https://web.archive.org/web/20090106201347/http://sourceforge.net/projects/bitcoin/ ↩
4. https://www.coindesk.com/markets/2020/11/26/previously-unpublished-emails-of-Nakamoto-nakamoto-present-a-new-puzzle ↩
5. https://www.ofnumbers.com/2018/10/01/interview-with-ray-dillinger/ ↩
6. https://bitcoin.stackexchange.com/questions/99674/how-do-devs-decide-who-should-have-commit-access-what-is-the-process/99676#comment112930_99676
7. https://web.archive.org/web/20230406134017/http://gavinandresen.ninja/Nakamoto ↩
8. https://www.reddit.com/r/Bitcoin/comments/3x7mrr/comment/cy29vkx/ ↩
9. https://github.com/bitcoin/bitcoin/pull/31908
10. https://bitcointalk.org/index.php?topic=1774750.0 ↩
11. https://github.com/bitcoin/bitcoin/blob/master/contrib/verify-commits/README.md
12. https://github.com/bitcoin/bitcoin/commits/master/contrib/verify-commits/trusted-keys ↩
13. https://mempool.space/block/0 ↩
14. https://Nakamoto.nakamotoinstitute.org/emails/cryptography/16/ ↩
15. https://sourceforge.net/p/bitcoin/code/1/tree/ ↩ ↩
16. https://bitcointalk.org/index.php?topic=16.msg73#msg73 ↩
17. https://en.bitcoin.it/wiki/Laszlo_Hanyecz ↩
18. https://bitcointalk.org/index.php?topic=238.msg2004#msg2004 ↩
19. https://www.bitcoin.com/Nakamoto-archive/emails/laszlo-hanec/1/ ↩
20. https://bitcointalk.org/index.php?topic=437.msg3807#msg3807 ↩
twenty one. https://github.com/bitcoin/bitcoin/commit/4110f33cded01bde5f01a6312248fa6fdd14cc76#diff-118fcbaaba162ba17933c7893247df3aR1344
twenty two. https://github.com/bitcoin/bitcoin/commit/bd7d9140f915d68e0abfdcd7ebdbb681c87d18c7
twenty three. https://en.bitcoin.it/wiki/Value_overflow_incident ↩ ↩
twenty four. https://bitcointalk.org/index.php?topic=822.0 ↩
25. https://bitcointalk.org/index.php?topic=823.msg9524#msg9524 ↩
26. https://sourceforge.net/p/bitcoin/code/139/log/ ↩
27. https://bitcointalk.org/index.php?topic=823.msg9531#msg9531 ↩
28. https://bitcointalk.org/index.php?topic=898.0 ↩
29. https://bitcointalk.org/index.php?topic=2367.0;all ↩
30. https://bitcointalk.org/index.php?topic=383.msg3198#msg3198 ↩
31. https://sourceforge.net/p/bitcoin/code/165
32. https://bitcointalk.org/index.php?topic=2228.msg29565#msg29565 ↩
33. https://www.bitcoin.com/satoshi-archive/emails/mike-hearn/16/ ↩
34. https://github.com/bitcoin/bitcoin/commits?before=a4e96cae7d3db3f7bfffd14a7fb6754ffbbc084e+46430
35. https://bitcointalk.org/index.php?topic=2367.msg31651#msg31651 ↩
36. https://web.archive.org/web/20101218045728/http://sourceforge.net/projects/bitcoin/develop/ ↩
37. https://web.archive.org/web/20110708091605/http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.21/ ↩
38. https://github.com/bitcoin/bitcoin/commit/86c0af514b59971f7a5c3876898165667cbbeb6b ↩
39. https://github.com/bitcoin/bitcoin/commit/86c0af514b59971f7a5c3876898165667cbbeb6b ↩
40. https://www.reddit.com/r/Bitcoin/comments/4hvevo/comment/d2t16mh/ ↩
41. https://github.com/bitcoin/bitcoin/commits?author=dooglus ↩
42. https://github.com/bitcoin/bitcoin/commit/fbfbf94deb4224ce65bdbbc9151ddd44a4128753 ↩
43. https://businessabc.net/wiki/pieter-wuille ↩
44. https://github.com/bitcoin/bitcoin/commit/62b427ec5532065744f9836e6a7b1676428c3434
