Finney, it turns out, was critical to Bitcoin’s early success. According to recently surfaced emails^[4] Nakamoto’s node was unable to receive “incoming connections” for a couple of days after the minting of the genesis block, resulting in Finney being the only node other users could connect to. Nakamoto told Finney in a private email “Your node receiving incoming connections was the main thing keeping the network going the first day or two.”

Finney was also one of the first known reviewers and contributors to Bitcoin, Nakamoto shared the software with him and a few other cypherpunk legends before it was shown to the world. Finney even contributed code to the project before its first release, as revealed by Ray Dillinger who Nakamoto also shared pre-released versions of the code with.

In an interview conducted by Nathaniel Popper published on Dillinger’s blog, he said^[5]; “It was when we started talking about floating-point types in accounting code that I learned Finney was involved in the effort. Finney was reviewing the transaction scripting language, and both the code he had, and the code I had, interacted with the accounting code.”

The timeline roughly matches the activity page of the oldest Sourceforge web archive we have of the Bitcoin project page, where Nakamoto added Finney to the project on December 18, 2008. This decision by Nakamoto marks the first instance of Maintainer level permissions possibly being held by anyone other than Nakamoto. It is possible and likely that Finney gained developer status within the Sourceforge Bitcoin project, allowing him to download, modify and upload versions to Bitcoin to the site.

So, besides being a Contributor, reviewer, and a node runner, was Hal Finney also a Bitcoin Maintainer?

The strictest definition of a Maintainer is someone who has ‘commit access’ or write access to the primary development branch of a software project. Contributors to a project like Bitcoin may ‘commit’ code to development branches of the project, and submit ‘pull requests’ to have the code integrated to the master branch, but those updates can only be ‘merged’ into the master branch by its Maintainers^[6] through “commit access”..

By that definition, Finney may very well count as the first Maintainer after Nakamoto, but being a Bitcoin core Maintainer is arguably a lot more than just having commit access. Maintainers must also have a good reputation among the developer community and be frequent, producing Contributors.

Bitcoin Maintainers have in some cases been active developers of the project, who were well known enough by other Maintainers and seemed to be a good fit for the role. In other cases, they have been active reviewers and auditors of the code, merging code contributions that appear to have consensus, and refusing to merge code that does not.

The Maintainer role in turn carries a high status within the Bitcoin industry, and it is vulnerable to reputation ending mistakes. In some cases, famous Maintainers have had their access revoked, when considered by other Maintainers to be compromised, as seen in the case of Gavin Andresen^[7] when he endorsed scam artist Craig Wright as Satoshi Nakamoto. In other cases, Maintainers have quit the role, in response to targeted harassment as seen with Gregory Maxwell^[8].

Generally, the Maintainer role in Bitcoin is expected by Contributors to be an engineering role and not a political one. Discussions on Github pull requests for example are expected to be about the technical and implementation details of a particular commit, rather than the person making the commit, their particular politics, allegiances. Discussions that touch consensus and are controversial or hotly debated are generally relegated to the Bitcoin mailing list and other forums, as do topics of a political nature.

It is important to note that whatever power there is embedded in the Maintainer role has arguably diminished over Bitcoin’s history, as the project has grown from the early days of Nakamoto. There are even examples of code getting merged to the master branch, only to be removed again^[9] after further review, making decisions by Maintainers far from final.

Maintainers throughout Bitcoin’s history have at times been accused of being gate keepers, refusing to merge updates to Bitcoin that factions of the community support, often in part because other factions of the community oppose them. In this sense, the Maintainer role does carry a certain kind of ‘taste making’ power, the permission to discern whether a commit has consensus or not, something not easy to quantify.  

This exclusive permission to merge or not to merge may be an unavoidable necessity of open source development, as no project would be considered safe or stable if anyone could merge any code into it at any time. In an adversarial environment, a meritocracy that filters code suggestions based only on the content of the ideas and their merit is arguably the best model we can strive for, anything else is a centralizing political system.

As such, the Maintainer role has persisted across Bitcoin development history, often held by multiple people, expanding and contracting in responsibilities. The role often draws the attention and curiosity of the broader Bitcoin community, as Maintainers as well as Contributors earn, enjoy and suffer the burdens of an emergent kind of leadership, especially in technical matters.

Unfortunately, data about the very early stage of Bitcoin development is scarce, leaving us only with glimpses into what role Finney played before the Genesis block. Maintainer permission history is actually quite opaque across open source development. Hubs like Sourceforge and Github fail to expose commit access history or detailed membership permissions to the public. Records like Nakamoto adding Finney to Sourceforge are actually a rare sight in Bitcoin Maintainer history.

Nevertheless, version control systems like SVN and Git which were implemented weeks after the first release of Bitcoin, do track commits across time and branches for the public to review, giving us public insights into what has happened. As a result, our knowledge of Bitcoin Maintainer history tends to come from first and last commits made to the master repo, announcements on Bitcointalk, or other forums, and confirmation of access revocation by active Maintainers at the time —in rare cases. A significant portion of the research on this article comes from Bitcoin Core Maintainer Ava Chow’s documentation of the relevant history^[10].

The tracking of commit access or Maintainers was improved in 2014 with the addition of the trusted-keys system,^[11] which adds a white list of PGP public keys into the master branch of Bitcoin Core. Keys can only enter and exit the list via commits merged by active Maintainers, and all commits to the master branch should be signed, by the corresponding private keys, a process that anyone in the public can verify and audit, comparing the software signature to the corresponding PGP keys.

The trusted-keys system was added as a security safeguard by Matt Corallo^[12], who told Bitcoin Magazine the feature was the result of a general process of improvements and optimizations, and not a response to any particular catalyst or event.

On January 3rd 2009, Nakamoto minted the genesis block^[13], effectively launching the digital currency into public beta. He added a message to the block that anchored and time stamped Bitcoin’s launch to the physical world with a headline from the British daily national newspaper, “The Times 03/Jan/2009 Chancellor on brink of second bailout for banks”. The headline is forever embedded in Bitcoin’s blockchain, a subtle yet immutable reminder of Bitcoin’s purpose and birthright.

On the night of January 8th 2009^[14] version 0.1.0 of Bitcoin was released to the public, announced on various forums including the cypherpunk mailing list, on it Nakamoto wrote; “Announcing the first release of Bitcoin, a new electronic cash system that uses a peer-to-peer network to prevent double-spending. It’s completely decentralized with no server or central authority.”

The installable windows version of Bitcoin in this first release had been compiled by Nakamoto and the source code made available as part of a .rar file published on SourceForge.net. This act made Nakamoto the founder and Lead Maintainer of Bitcoin by default, a role built into the very nature of open source development. Nakamoto would take code commits from other developers during his time building Bitcoin, download them to his local machine, review and merge the code bases, and produce new version releases, a key task and work flow that differentiates Maintainers for Contributors throughout Bitcoin history. This process would continue until Nakamoto’s departure in December of 2010 and would impact versions 0.1.0 to 0.3.19 of Bitcoin.  

Multiple updates followed the first release of Bitcoin and by the end of January 2009, a third developer had officially become a Contributor to the project. Marti Malmi going by the username of “sirius-m” made the “First commit”^[15] to Sourceforge, bringing online the SVN source version control system — a kind of git, popular at the time. Malmi committed to the ‘Trunk’ comparable to a master branch on Github, making Malmi the second official Maintainer in Bitcoin’s open source development history. Malmi would make a variety of contributions throughout 2009 including the first Linux version of Bitcoin, with the 0.2.0 release^[16].

It wasn’t until the August of 2010 that Lazloh Hanyecz — famous for having paid 10,000 bitcoins for a pizza in 2010^[17] — would join as Maintainer^[18], a month after contributing the first iOS version of Bitcoin to the 0.3.0 release.

Part of Nakamoto’s role as Lead Maintainer of Bitcoin was the stewardship of the network. Nakamoto went as far as to personally ask Lazloh — who was one of the first to mine bitcoin with GPUs —  to slow down his production for the sake of the network. “The longer we can delay the GPU arms race, the more mature the OpenCL libraries get, and the more people will have OpenCL compatible video cards,” Nakamoto said to Lazloh in 2009^[19], looking to prolong the CPU mining era of Bitcoin, which was a major incentive to run Bitcoin nodes at a time when the future price of the coins was entirely uncertain.

On July 17th 2010 on version 0.3.2^[20][21] Nakamoto added the check pointing system, a security safeguard that hard coded a certain block height as valid and its corresponding winning hash. Its purpose was to protect the chain from miner attacks that could theoretically reorganize the chain well beyond what the “widely accepted block chain” was, Nakamoto said on the announcement, adding that “there’s no point in leaving open the unwanted non-zero possibility of revision months later.”

The checkpointing system would result in a new responsibility for future bitcoin Maintainers, who would have to hard code a new block height and its corresponding hash on future releases, well into Gavin Andresen’s era of Bitcoin development^[22]. The checkpointing system was eventually phased out, as the proof of work made deep reorgs unfeasible.

The height of Nakamoto’s power as Lead Maintainer and project founder would be demonstrated during the value overflow bug event of October 2010^[23], where three transactions created 184 million bitcoin that did not and should not exist. The number of coins the transaction attempted to move was so large that the transaction validation code at the time “overflowed when summed”, breaking consensus.  

This is historically Bitcoin’s most famous bug, sometimes called the ‘inflation bug’ and was likely the most dangerous to the project’s survival. Various community members started noticing the transactions hours after they were mined into the network, springing Nakamoto into action, who, with the help of a few Contributors^[24] including Andresen^[25], created a patched version of Bitcoin^[26] changing the relevant validation code.

Nakamoto asked miners to move to the patched version and resync the chain^[27], resulting in a roll back of the network to a state before the invalid transactions were confirmed. This was a hard fork that rolled back 19 hours of Bitcoin blocks, and probably represents the peak of Bitcoin’s centralization under Nakamoto’s leadership, as well as the peak of power that has ever been concentrated in the Lead Maintainer role.

Following the events of the Value Overflow Bug, Nakamoto implemented the Alert System on version 0.3.11^[28]. The feature — which was somewhat controversial — would make nodes at risk of a critical bug, show a warning and would disable essential features. This Alert System used messages that would have to be signed by a key only held by Nakamoto. He justified the feature saying that “getting surprised by some temporary down time when your node would otherwise be at risk is better than getting surprised by a thief draining all your inventory.” Months later Nakamoto disabled the Alert System in his final version release.

Per the SVN records, only Nakamoto ever merged the code of other Contributors and pushed new official release versions of the Bitcoin, at least until Gavin Andresen became Lead Maintainer in December 19th 2010^[29]. Andresen had been contributing code to Nakamoto directly as early as February^[30] that year, as seen in the release of 0.3.1, and would make his first commit to the SVN Trunk on October 11th^[31], a couple of months before Satoshi Nakamoto published his final version on Bitcoin, 0.3.19^[32], disappearing into history.

At the time of writing, over 1200 individual people have contributed code to the Bitcoin Core project.

The Gavin Andresen Era

With Nakamoto no longer contributing to the project, Gavin Andresen was left as one of the only active contributors to the project with commit access. Malmi had slowed down contribution as Andresen’s accelerated, so when Nakamoto left, Andresen was left as the default Lead Maintainer. While Nakamoto never made a public statement, granting the role to Andresen, he did send an email to Mike Hearn — a frequent Contributor at the time — famously saying “I’ve moved on to other things.  It’s in good hands with Gavin and everyone.”^[33]

“With Nakamoto’s Blessing”^[34] Andresen would take the mantle of Lead Maintainer of Bitcoin and would go on to expand the Maintainer team while also initiate the official migration from Sourceforge to Github^[35], a process which would take some time. It wasn’t until July 14th of 2011 that we would see the first commit merged to Bitcoin from a branch on Andresen’s official github account^[36].

Unlike the Nakamoto era of development, this merge was done by the Github platform, putting some trust on Github.com to not do something shady with the code, a process previously done by Nakamoto manually and on his local machine. It’s important to note that the differences between versions of the code are auditable anyway, Github merge or not, since the project is open source. Code merges in this era could and should have been reviewed by developers on both sides of the process, before Github merge and after, though an abundance of caution eventually led to the creation of the trusted-keys system. Nevertheless, this began a new trend in how code was merged into Bitcoin that would last for at least three years.

On September 13th, 2011, the Sourceforge Bitcoin project was officially shut down, favoring Github as the new collaboration platform, leaving the old Bitcoin page there as an archive. Since both Malmi and Lazloh were Contributors on Sourceforge primarily without Github accounts at the time, their commit access effectively ended with the official migration, as well as their slow down in contributions around Nakamoto’s departure.

On April 27 of 2011, version 0.3.21 was released, the first under Andresen’s leadership. It was also the first to include a Readme file a PGP signed^[37] message that detailed the update, contained hashes for the released installables and gave shout outs to Contributors. Among the 16 Contributors named are well known bitcoin core developers like Luke Dashjr, Matt Corallo, Pieter Wuille and Jeff Garzik.

The next couple of years saw a flurry of new Maintainers, perhaps in an attempt to decentralize what ever perceived power and responsibility Gavin held via the Maintainer role, and to fill in the gaps left by Nakamoto, Malmi and Lazloh. Chris Moore^[38] with the username “dooglas” gained commit access for a couple of months from January 21st^[39] until March 31st 2011^[40] and still contributes to the project from time to time^[41].

A few months later on the first of June of 2011, Pieter Wuille gained commit access^[42]. Wuille discovered Bitcoin in November of 2010 and soon started contributing to the project. After gaining commit access, Wuille would become a renowned Bitcoin core developer, generally credited with many small performance optimizations that sum up over time to large improvements in user experience among many other contributions^[43]. Today Wuille holds the third most commits to Bitcoin core, under the “sipa” username according to Github.  

Jeff Garzik would join as Maintainer a few days later on June 6th, 2011^[44]. Garzik started contributing to Bitcoin as early as version 0.3.21 that year and would also become renowned Bitcoin developer, bringing his extensive experience from the Linux open source ecosystem^[45] to the Bitcoin project. Garzik is generally credited with helping improve the stability of the Bitcoin client.

Years later in the summer of 2016 Garzik had his commit access revoked after “several months of inactivity” according to Chow. During these years the Bitcoin block size war had begun to heat up and Garzik was on the side of the big blocks update^[46], leading to lots of debate, and friction with some factions of the Bitcoin community, a likely cause of his drop in development activity. Garzik would go on to lead one of the failed forks of that war a year later, version Segwit2x.

A month later on July 5th of 2011, Mara van der Laan (who identified as Wladamir at the time) was granted commit access, becoming the eighth official Maintainer of Bitcoin Core. Van der Laan started engaging in the Bitcointalk forum as early as November 2010 and started contributing to Bitcoin by May 2011^[47] initially focusing on the GUI of the Bitcoin QT client and bringing deep academic experience in computer graphics^[48].

On September 19, 2011 Nils Schneider going by the username “tcatm” gained commit access after frequent contributions focused on optimising the Bitcoin client for working in the background. During his time as a Maintainer, he made big contributions helping to internationalize the client, adding multiple language related updates^[49], and oversaw the removal of the Crypto++ library, protecting the client from unnecessary dependencies^[50]. Nils worked as a Maintainer for almost a year with his last commit made in May 31st, 2012^[51].

In February 11 of 2012^[52] Gregory Maxwell with the username “gmaxwell” merged his first commit to Bitcoin after various code contributions and a full year of active technical commentary on the Bitcointalk forum^[53], starting off a three year career as a Bitcoin Maintainer. During this time, Maxwell focused largely on the P2P networking layer of the client as well as consensus and validation related work. To date he is held in very high regard by many in the broad Bitcoin community and occasionally contributes to technical discussions and debates. Maxwell gave up commit access in December of 2015^[54] as the Bitcoin block size war was heating up, due to internet harassment and other related concerns, as he took the small block position. 

After a year or so of expanding the Bitcoin core Maintainer team, on September 27th, 2012 Gavin announced the next step in his vision for Bitcoin’s future, the Bitcoin Foundation^[55]. Made in the image of the Linux foundation, which Gavin saw as a great example of a successful large open source project, the foundation attracted a great deal of attention and support as well as criticism. In his announcement post Gavin said; “I want the Bitcoin Foundation to be an open, member-driven organization, and hope that you or your organization will not only become a member but will help the Foundation accomplish its mission”. Over the next few years, the foundation would help pay the salaries of a variety of Bitcoin core Contributors and Maintainers.

The Mara van der Laan Era

In April 2014, Mara van der Laan was chosen by Gavin Andresen as his successor to the Lead Maintainer role, as Andresen had decided to move towards a more academic role he labeled “Chief Scientist”. In a blog post, published by Andresen on the Bitcoin Foundation website^[56] he wrote; “Wladimir van der Laan has been paid to work on Bitcoin Core full-time for several months now – again, thanks to all of you Foundation members for stepping up and helping to fund core development – and has been doing a fantastic job. He has agreed to take over for me as the ‘Bitcoin Core Maintainer.’”

Under the usernames “Laanwj” and “wumpus”, Ven der Laan would oversee 9 years of Bitcoin Core developments, today holding the crown as having made the most commits to the Bitcoin repo^[57] according to Github graphs, with 7,419 commits — most of them merges — to date. Van der Laan gave up the role in February 2023 for “personal reasons” according to Chow.

One of the first and most notable changes to the Maintainer role under Van der Laan was the implementation of the trusted-keys system, which was committed by Matt Corallo^[58] on December 20th of 2014. The system helped solve the opaque nature of the Maintainer role, by adding a file with PGP public key fingerprints to the master bitcoin repository, as well as a series of related tools^[59]. One of the tools makes sure that Maintainer commits are correctly PGP signed, another script can be used to verify commit signatures against the trusted-keys list of PGP keys.

By having these keys inside the master repo, only Maintainers are able to add and remove keys to the list with valid signatures, leaving a record on Git’s version control system, while giving us pull requests for the addition and removal of Maintainers, which Contributors and commit members can comment on.  

According to Corallo, the main role of the trusted-keys system was “to avoid trusting Github” to merge developer code, a practice normalized during Andresen’s era of development. Instead, Maintainers merge the code locally and update the repository.

On November 13, 2015, Jonas Schnelli was granted commit access, with the username “jonasschnelli”. He was granted the role of GUI Maintainer by Van der Laan, who announced it in the bitcoin mailing list^[60]. Schnelli who started contributing in 2013 to Bitcoin would go on to reach the top 10 of Bitcoin Contributors by commits on github, many also likely being merges during his role as Maintainer, which lasted 6 years. Schnelli gave up commit access in October 21st, 2021 for personal reasons, writing a thread on Twitter reflecting on his experience and expressing strong confidence in the bitcoin developer community that proceeded him^[61].

On April 13, 2016, Marco Falke was given commit access under the username “maflcko” ^[62]. Van der Laan announced the decision on the Bitcoin mailing list^[63], saying “Hereby I’m announcing Marco Falke as the new Testing & QA Maintainer for Bitcoin Core.” Falke contributed to core all the way until 2023, when he decided to give up commit access and the Maintainer role, for personal reasons^[64].

Less than a month later, on May 6th 2016, Gavin Andresen had his commit access removed. The decision made by Van der Laan came after Andresen endorsed now known Satoshi Nakamoto impersonator Craig Wright^[65]. Many in the Bitcoin community were already skeptical of Wright’s claims and Andresen’s position at the time was quickly revealed to be based on deception by Wright. Months earlier, Mike Hearn, a Bitcoin Contributor who was seen as close to Andresen, advocated on a podcast that Andresen should revoke commit access from all Maintainers and become a “Benevolent Dictator” of Bitcoin^[66], as is done in many other open source projects. Andresen did not follow Hearn’s advice, but the event demonstrated the levels of tension the Bitcoin community was under, as the block size war raged on, which Wright was also a part of.  

Years later Andresen would express his regrets about the events saying “I now know it was a mistake to trust Craig Wright as much as I did. I regret getting sucked into the “who is (or isn’t) Nakamoto” game, and I refuse to play that game any more.”

It would be a couple of years until the next Bitcoin Contributor would gain commit access. On December 4th of 2018, Samuel Dobson known by the username “MeshCollider” was made wallet Maintainer by Van der Laan^[67]. Dobson had been making contributions to Bitcoin since at least the summer of 2017^[68] and would go on to make over 300 commits throughout his Bitcoin developer career, focusing on the wallet side of the Bitcoin code base. Dobson gave up commit access and the Maintainer role in February of 2023 to focus on his PHD^[69].

A year later on June 7th 2019, Michael Ford would gain commit access, the first in the latest generation Maintainers who works on the role to date. Wielding the username “Fanquake”, Ford might have been the first Contributor to gain commit access by Contributor consensus, having been nominated during a core developer meetup in Amsterdam^[70] [71]. Nomination by Contributor consensus would become a trend after this period, demonstrating Bitcoin development’s trend towards decentralization, with meetings taking place in various locations and environments, and even via IRC.

Ford started contributing to Bitcoin in February of 2012^[72] and would thereafter become one of the most prolific Maintainers in Bitcoin history, locking in second place for the most commits according to Github with 4920 to date, many of them merges and maintenance related updates to the work of other Contributors.

The Contributor Consensus Era

On January 21st, 2021 Van der Laan published a blog^[73] that would break with the tradition started by Nakamoto and Andresen, of having a Lead Maintainer for Bitcoin core development. In it, Van der Laan explained that she would start delegating many of her roles as Lead Maintainer, that Bitcoin was too large of a project now to use the model setup by Nakamoto and Andresen, and effectively that it was time to decentralize Bitcoin core development.

Van der Laan made explicit a series of duties that needed to be done by others and laid a road map for making the software release process of Bitcoin more censorship resistant, such as moving the Bitcoincore.org website to the ownership of an organization rather than be under her control, while encouraging mirrors. The setup of release distribution via torrents and possibly IPFS, skepticism towards Github.com and a call out to start looking for alternative code contribution platforms, and a threshold signing scheme for Maintainers to be able to sign releases via some kind of cryptographic consensus, rather than having one person be the final PGP signer of a release, among other ideas.

The blog post effectively marked the end of Van der Laan’s role as Lead Maintainer, and symbolized a maturation milestone in Bitcoin, which came months after the release of version 0.20.0 and only days after the version 0.21.0 release^[74].

Hannadii Stepanov known by the username “hebasto” gained commit access in March 19th 2021 to be GUI Maintainer^[75] for the Bitcoin client. Stepanov began contributing code to Bitcoin core in August 2018^[76], with over a thousand code contributions before becoming a Maintainer, placing him at 5th place in Github’s commits ranking for the project with 2070 locked in to date. Stepanov remains a Bitcoin Maintainer as of the time of writing.

Ava Chow gained commit access in December 12, 2020^[77] as the wallet Maintainer, after contributing since January 2016^[78]. Wielding the username “achow101” Chow is a well known Contributor whose efforts in the Bitcoin development community go beyond github contributions, including a significant portion of the historical research in this history of core Maintainers. Chow is also know to do Bitcoin core review livestreams on Twitch^[79] which gathers an active audience, helping further technical Bitcoin education. Chow ranks on Github as number 4 with most commits at 2198, and still has commit access as of the time of writing.

Gloria Zhao gained commit access in August 7th 2022 after being nominated by Contributor consensus^[80], for the role of mempool and policy Maintainer^[81]. Zhao started contributing in March of 2020^[82] and had at least 200 commits in Bitcoin core before gaining commit access. Today she ranks at number 9 according to Github with 777 commits in the repo. Zhao is a Maintainer to this day.

Russ Yanofsky gained commit access in June 10th of 2023^[83] after being nominated by Contributor consensus^[84], to the role of interface Maintainer. Russ specializes in modularization and multiprocess work which earned him the role, after contributing to the project since October 2016^[85], with 970 commits for 7th place in Github ranking. Yanofsky is known by the username “ryanofsky” and remains a Maintainer to this day.

Don’t miss your chance to own The Core Issue — featuring articles written by many Core Developers explaining the projects they work on themselves!

This piece is the Letter from the Editor featured in the latest Print edition of Bitcoin Magazine, The Core Issue. We’re sharing it here as an early look at the ideas explored throughout the full issue.

[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 

[21] https://github.com/bitcoin/bitcoin/commit/4110f33cded01bde5f01a6312248fa6fdd14cc76#diff-118fcbaaba162ba17933c7893247df3aR1344 

[22] https://github.com/bitcoin/bitcoin/commit/bd7d9140f915d68e0abfdcd7ebdbb681c87d18c7 

[23] https://en.bitcoin.it/wiki/Value_overflow_incident 

[24] 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 

[45] https://bitcoinwiki.org/wiki/jeff-garzik 

[46] https://medium.com/@jgarzik/bitcoin-is-being-hot-wired-for-settlement-a5beb1df223a#.qgx99rxpr 

[47] https://github.com/laanwj?tab=overview&from=2011-05-01&to=2011-12-31 

[48] https://dl.acm.org/profile/81474651580 

[49] https://github.com/bitcoin/bitcoin/commit/560078a7685b33bdc8d1a94631633cb2af841976 

[50] https://github.com/bitcoin/bitcoin/commit/6ccff2cbdebca38e4913b679784a4865edfbb12a 

[51] https://github.com/bitcoin/bitcoin/commit/50fac686541686191647ddabd87d6dae75c24c52 

[52] https://github.com/bitcoin/bitcoin/commit/9f3de58d83f54536076be44fe945f56670ef9b60 

[53] https://bitcointalk.org/index.php?action=profile;u=11425;sa=showPosts;start=6000 

[54] https://www.reddit.com/r/Bitcoin/comments/3x7mrr/gmaxwell_unullc_no_longer_a_bitcoin_committer_on/cy29vkx/ 

[55] https://bitcointalk.org/index.php?topic=113400.0

[56] https://web.archive.org/web/20140915022516/https://bitcoinfoundation.org/2014/04/bitcoin-core-Maintainer-wladimir-van-der-laan/ 

[57] https://github.com/bitcoin/bitcoin/graphs/Contributors 

[58] https://github.com/bitcoin/bitcoin/commits/master/contrib/verify-commits/trusted-keys 

[59] https://github.com/bitcoin/bitcoin/blob/master/contrib/verify-commits/README.md 

[60] https://gnusha.org/pi/bitcoindev/20151113073052.GB19878@amethyst.visucore.com/ 

[61] https://x.com/_jonasschnelli_/status/1451268520159875080 

[62] https://github.com/bitcoin/bitcoin/pull/7921 

[63] https://www.mail-archive.com/bitcoin-core-dev%40lists.linuxfoundation.org/msg00003.html 

[64] https://x.com/MarcoFalke/status/1627987123788824576 

[65] https://laanwj.github.io/2016/05/06/hostility-scams-and-moving-forward.html 

[66] https://www.youtube.com/watch?v=8JmvkyQyD8w&t=2878s 

[67] https://github.com/bitcoin/bitcoin/commit/1ca050254145ebbbbf5910bfee2e82a45e465ca1 

[68] https://github.com/bitcoin/bitcoin/commit/41f3e84aaca82540582fd5a93fd632e752c3e6bf 

[69] https://x.com/MarcoFalke/status/1627987123788824576 

[70] https://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-06-Maintainers/ 

[71] https://github.com/bitcoin/bitcoin/pull/16162 

[72] https://github.com/bitcoin/bitcoin/commit/27adfb2e0c1caeef3970605f519edf9058f119ef 

[73] https://laanwj.github.io/2021/01/21/decentralize.html 

[74] https://github.com/bitcoin/bitcoin/releases?page=3 

[75] https://github.com/bitcoin/bitcoin/pull/21615 

[76] https://github.com/bitcoin/bitcoin/commit/11b9dbb439a15ed275cba673fdc743c612ea374f 

[77] https://github.com/bitcoin/bitcoin/pull/23798 

[78] https://github.com/bitcoin/bitcoin/commit/5ed2f16480142f0887cc1a6257ff53e2abc3e5b6 

[79] https://www.twitch.tv/achow101/ 

[80] https://gnusha.org/bitcoin-core-dev/2022-06-30.log 

[81] https://github.com/bitcoin/bitcoin/pull/25524 

[82] https://github.com/bitcoin/bitcoin/commit/2455aa5d7f54befeade05795ed8f5dd89d01042a 

[83] https://github.com/bitcoin/bitcoin/pull/27604 

[84] https://gnusha.org/bitcoin-core-dev/2023-05-04.log 

[85] https://github.com/bitcoin/bitcoin/commit/18dacf9bd25154e184b097ee4e8f786d9be25637