Bitcoin Core 维护者角色演变史

作者：Juan Galt

来源：https://bitcoinmagazine.com/print/the-core-issue-the-role-and-history-of-bitcoin-core-maintainers

在最开始的时候，只有中本聪一个人，和一个强大的理念。中本聪最晚从 2007 年开始开发比特币 ¹，并且根据我们所知，完全是一个人在开发，一直到 2008 年 10 月 31 日 —— 他发出比特币白皮书 ² —— 的几周以后，中本聪为这个项目带来了第一个贡献者，Hal Finney（哈尔·芬尼） ³。

事后表明，Finney 对于比特币最初的成功是极为关键的。根据最近才披露的邮件 ⁴，中本聪的节点在挖出创世区块之后，一连好几天都无法收到 “入站连接”，因此 Finney 的节点成了其他用户能够连接的唯一节点。中本聪告诉在一封私人邮件中告诉 Finney：“你的节点收取了入站连接，是整个网络得以撑过最初一两天的主要因素。”

Finney 也是已知的第一个比特币代码审核人和贡献者。在把软件完全公开之前，中本聪把它分享给了 Finney 和少数几个密码朋克传奇人物。甚至早在比特币这个项目发布第一个版本以前，Finney 就已经贡献过代码了 —— 这是 Ray Dillinger 披露的，他也收到了中本聪分享的还未公开的代码。

Dillinger 的博客刊载了一份 Nathaniel Popper 对他的访谈 ⁵。他在访谈中说：“那是我们开始讨论会计代码中的浮点数类型的时候，我知道了 Finney 也参与其中。Finney 当时正在审核交易的脚本编程语言，他的代码、我的代码，都跟会计代码交互。“

这段描述跟我们已知 Bitcoin 项目在 Sourceforge 代码平台上的最古老的档案，是大致对得上的 —— 中本聪在 2008 年 12 月 18 日将 Finney 添加到项目中。中本聪的这个决定，标志着项目的 “维护者（Maintainer）” 级别的权限可能由其他人持有的第一种情形。Finney 可以取得、也很可能取得了 Sourceforge 平台上 Bitcoin 项目的开发者身份，因此可以下载、修改和上传新版本到这个项目。

那么，除了是一个代码贡献者、代码审核人、节点运营者，Hal Finney 也是比特币项目的一个维护者吗？

“维护者” 的最严格的定义是，拥有一个软件项目的主要开发分支的 “commit 权限”（或者说写入权限）的人。对 Bitcoin 这样的项目而言，贡献者可以 “提交” 代码到项目的开发分支，并发送 “PR（合并请求）”、让这些代码整合到主要分支，但是，这些更新只有通过维护者 ⁶ 的 “commit 权限”，才能 “合并” 到主分支 ……

根据这个定义，Finney 可以很恰当地称为中本聪之后的第一位维护者。但是，成为 Bitcoin Core 的一位维护者，可以说仅仅拥有 commit 权限是不够的；TA 在开发者社区中要有良好的声望，并且同时也是勤奋的、有能力的贡献者。

译者注：粗略地说，中本聪在 Sourceforce 平台上创建了 “Bitcoin” 项目，这是第一种比特币节点客户端；中本聪离开后，已有的代码迁移到了 Github 平台，项目名称也改为 “Bitcoin Core”。从原文可知，作者并不强调这一分别，实际上把两者当成同一个项目并一直用 “Bitcoin” 一词来指代它，而不是专指前面那个项目（或者说前面那个时期）。因此，这里使用 “Bitcoin Core”，只是为了表示后来对维护者的要求提高了。

Bitcoin 项目的维护者，有时候是项目的活跃开发者，对其他维护者来说知根知底、似乎很适合这个角色；但也有一些时候，是积极的代码审核人，仅仅合并似乎达成了共识的代码贡献，并且拒绝合并没有得到共识的代码。

反过来，维护者在比特币行业中变成了有地位的身份，也很容易因为犯错而败坏名声。有时候，著名的维护者会被其他维护者认为已经腐化，其权限也因此被撤销，比如 Gavin Andresen ⁷，他担保骗子 Craig Wright 就是中本聪。也有时候，维护者会为了规避针对性的骚扰而辞去角色，比如 Gregory Maxwell ⁸。

总的来说，贡献者们期望 Bitcoin 项目的维护者是一位管工程的人，而不是搞政治的人。比如说，在 Github 网站的各 PR 的讨论页面，人们期望讨论的是一次具体的代码提及的技术和实现细节，而不是发起这次提交的人、他们的政治观点、忠诚度。涉及共识并且有争议、会引发激烈争论的讨论，通常会转移到 bitcoin 邮件组和其它论坛，有关政治的话题也是如此。

重点是，在比特币的历史上，“维护者” 这个角色所具有的权力 —— 不管具体是哪一些 —— 可以说随着这个项目从中本聪创始之日起逐渐成长就不断萎缩。甚至出现了代码已经合并到了主分支、却又在后续审核中再次移除的例子 ⁹ —— 表明维护者的决定也不是最终决定了。

在 Bitcoin 项目的历史上，有时候维护者会被指责充当了拦路人（gate keepers）、拒绝合并社区的一部分人已经支持的更新到项目中 —— 通常有一部分原因是社区的另一部分人反对他们。这时候，维护者角色确实拥有一种难以量化的 “潮流塑造（taste making）” 权力 —— 判断一项代码提交有没有得到共识。

排他性的决定合并（一些代码）与否的权力，对开源开发的项目来说也许是绝对必要、无法避免的，因为如果任何人都能随时合并任何代码，那这个项目就无法被当作是安全的、稳定的。在一个敌对环境中，一个仅仅根据代码的想法和价值来审核的精英体制，可以说就是我们能够追求的最好模式了，任何其它选择都是集权式的政治体制。

不幸的是，关于 Bitcoin 项目开发最初情形的资料非常稀有，使我们只能一窥 Hal Finney 在创世区块之前扮演的角色。开源软件开发中，维护者权限的历史是非常不透明的。Sourceforge 和 Github 这样的平台，不会公开行使 commit 权限的历史和详细的成员权限。中本聪添加 Finney 到 Sourceforge 这样的记录，在 Bitcoin 项目的维护者史上是非常罕见的。

不过，SVN 和 Git 这样的版本控制系统，虽然是在 Bitcoin 发布第一个版本的几周之后实现的，但确实跟踪了代码提交和项目分支的历史，供公众审核，这给了我们看出发生了什么的公开信息。结果是，我们对 Bitcoin 项目维护者历史的知识，常常来自他们对主分支的第一次和最后一次提交、在 Bitcointalk（或其它）论坛上的公告，以及被活跃的维护者撤销权限的消息（极为罕见）。本文内容的一大部分，都来自 Bitcoin Core 维护者 Ava Chow 对相关历史的记录 ¹⁰。

对 commit 权限（或者说维护者）的跟踪能力，在 2014 年得到了提升：Bitcoin Core 项目加入了 “受信任公钥” 系统 ¹¹，添加了一个可以向主分支 commit 代码的 PGP 公钥的白名单。公钥只有通过活跃维护者合并代码才能进入或退出这个名单；而所有提交到主分支的代码都会被（对应的私钥）签名，这是任何人都能过公开验证的 —— 将对软件的签名与对应的 PGP 公钥比对。

受信任公钥系统是由 Matt Corallo 作为一种安全措施而加入的 ¹²，他告诉 Bitcoin Magazine，这个特性是一套通用的提升和优化过程的结果，并不是对哪一项刺激或者说哪一件事情的反应。

Bitcoin Core 维护者简史：中本聪时代

在 2009 年 1 月 3 日，中本聪挖出了比特币网络的创世区块 ¹³，事实上将这种电子货币推入公开测试阶段。他在这个区块中添加了一段信息 —— 来自英国的全国性日常新闻报的一个标题：“The Times 03/Jan/2009 Chancellor on brink of second bailout for banks（泰晤士报 2009 年 1 月 3 日财政大臣正在第二次救助银行的边缘）” —— 将比特币的诞生与物理世界相锚定并盖上了时间戳。这个标题永远地留在比特币的区块链上，恰是对比特币的使命的巧妙且永恒的提醒。

在 2009 年 1 月 8 日晚上 ¹⁴，版本 0.1.0 的 Bitcoin 软件发布，并在多个论坛上宣告（也包括 “密码朋克” 邮件组）。中本聪在公共中写道：“宣布 Bitcoin 软件的第一个发行版本；这是一种新的电子现金系统，使用一个点对点网络来防止重复花费。它是完全去中心化的，没有服务端或者中心权威。”

在 Bitcoin 的第一次发行版中，可以在 Windows 系统上安装的版本是由中本聪编译的，并且其源代码也也放在了一个 .rar 压缩文件中，发布在 SourceForge.net 上。这个举动天然让中本聪成了 Bitcoin 项目的创始人和主要维护者 —— 与开源软件项目天然相伴相随的角色。在开发 Bitcoin 的时候，中本聪会取得其他开发者提交的代码、下载到他自己的及其上、审核以及合并代码，然后制作处新的发行版本 —— 这最后一项任务，将维护者与贡献者区别开来，贯穿了 Bitcoin 项目的整个历史。这套工作流程一直持续到中本聪在 2010 年 10 月消失，影响了 Bitcoin 软件的 0.1.0 到 0.3.19 版本。

Bitcoin 第一次发行之后，马上就发布了多次更新；在 2009 年 1 月底，第三位开发者正式成为这个项目的一位贡献者。Martti Malmi 使用 “sirius-m” 的用户名在 Sourceforge 网站上制作了 “第一次提交” ¹⁵，将 SVN 源代码版本控制系统带到了网上。SVN 跟 git 相似，都是版本控制系统，在那时候比较流行。Malmi 将代码提交到 “Trunk” 分支，就像 Github 平台上的 “master” 分支（主分支），所以 Malmi 也成了 Bitcoin 项目开源开发历史上的第二位正式的维护者。在 2009 年，Malmi 还作出了许多贡献，包括 Bitcoin 的第一个 Linux 版本，时值 0.2.0 发行版 ¹⁶。

又到 2010 年 8 月，Lazloh Hanyecz —— 没错，就是因为在 2010 年花 10000 BTC 买了一张披萨饼 ¹⁷ 而出名的那哥们 —— 才加入成为另一位维护者 ¹⁸，那是在他为 Bitcoin 的 0.3.0 发行版贡献了 Bitcoin 的第一个 iOS 版本的一个月后。

作为维护者主管，中本聪的其中一面是（字面意义上的）管理整个网络。中本聪曾经私下要求 Lazloh —— 第一个使用显卡（GPU）来挖掘比特币区块的人 —— 降低他的挖矿速度以照顾整个网络。“我们越是推迟 GPU 的军备竞赛，OpenCL 库就能越成熟，也就有越多人能够用上兼容 OpenCL 的显卡”，中本聪在 2009 年跟 Lazloh 这么说 ¹⁹，尝试延长比特币的 CPU 挖矿时代。那时候比特币的未来是完全不确定的，挖矿是运行比特币节点的主要激励。

2010 年 7 月 17 日，Bitcoin 的 0.3.2 版本发布 ²⁰ ²¹ ，中本聪添加了 “检查点系统（check pointing system）” 作为一种安全措施，它硬编码一个哈希值作为某个区块高度的有效哈希值。它的用意是防止区块链在矿工攻击下重组、深度极深以至于颠覆 “已被广泛接受的区块链”（中本聪在公告里的原话）（理论上是有这种可能）。中本聪还补充了一句：“没必要保留这种几个月后还能回头修改的非零可能性，它不受人欢迎”。

检查点系统使未来的维护者有了一个新的职责 —— 在未来的发行版中决定硬编码哪个区块高度及其胜出哈希值；在 Gavin Andresen 领导 Bitcoin 项目开发的时代就是如此 ²³ 。这个检查点系统最后呗淘汰了，因为工作量证明已经让深度重组不可行。

中本聪作为维护者主管和项目创始人的权力之大，在 2010 年 10 月的数值溢出 bug 事件 ²³ 中得到了充分展现：那时候，三笔交易创造出了原本不存在（也不应该存在）的 1840 亿 BTC。这笔交易尝试移动非常巨大的金额，以至于当时的交易验证代码 “在加总时产生了溢出”、从而打破了共识。

译者注：作者在这里的叙述模糊，而且有误。实际上是一笔交易创造出了这么多 BTC，被三个地址接收（其中一个是矿工在 coinbase 交易中的地址）；当时的交易验证代码只是用输入的面额总和去减输出的面额总和，只要结果是正数（表明输入金额大于输出金额）就通过；而输出的面额太大，加起来的和超过了固定长度所能表达的数字，就溢出成了负数，那么不论输入的金额大小，都一定会通过验证。从技术层面看，它并没有打破共识（导致网络分裂成互不认可的局部）。详情可见作者提供的脚注。

这是比特币历史上最著名的 bug ，有时候被称为 “通胀 bug”，可能也是对这个项目的生死存亡最为危险的漏洞。许多社区成员在这笔交易被挖出的几个小时之后注意到了这笔交易，提醒中本聪采取行动。中本聪，在几位贡献者 ²⁴（包括 Andresen ²⁵）的帮助之下，创建了 Bitcoin 的一个补丁版本 ²⁶，改变了相关的验证代码。

中本聪要求矿工们迁移到这个带有补丁的版本并重新同步区块链 ²⁷，结果是整个网络回滚到了这笔无效交易得到确认以前的状态。这是一次硬分叉，撤销了 19 个小时内挖出的比特币区块。这可能代表了 Bitcoin 项目在中本聪领导下中心化的巅峰，也是在维护者主管角色上集中的权力的巅峰。

在 “数值溢出 Bug” 事件之后，中本聪在版本 0.3.11 实现了 “警报系统” ²⁸。这个系统 —— 一定程度上也是有争议的 —— 将让处于致命风险下的节点显示一条警告并停用基本功能。这个警报系统只能使用由一个密钥签过名的消息来触发，而这个密钥只有中本聪掌握。他辩称：“在你的节点如不暂停便处于风险之中时，被短暂的宕机时间吓到，总好过让窃贼已经偷走你所有的投资吓到。” 几个月后，中本聪在自己最后一个发布的版本中禁用了这个警报系统。

根据 SVN 记录，只有中本聪曾经合并过其他贡献者的代码以及推送 Bitcoin 的正式发行版本，至少在 Gavin Andresen 在 2010 年 12 月 19 日成为维护者主管 ²⁹ 之前是这样。早在该年的 2 月 ³⁰，Andresen 就曾经直接向中本聪贡献代码；并且，在该年的 10 月 11 日 ³¹，制作了他向 SVN 的 Trunk 分支的第一个 commit。几个月后，中本聪发布了他在 Bitcoin 项目中的最后一个版本：0.3.19 ³²，然后，消失在了历史中。

截至本文撰写之时，超过 1200 个人，曾经给 Bitcoin Core 项目贡献过代码。

Gavin Andresen 时代

随着中本聪不再给这个项目贡献代码，Gavin Andresen 成了唯一一个拥有 commit 权限的活跃贡献者。随着 Andresen 增加投入，Malmi 已经放慢了速度，所以 Andresen 成了默认的维护者主管。虽然中本聪从来没有发出公开声明将这个角色交给 Andresen，他确实给 Mike Hearn（当时的一位活跃贡献者）发了一封邮件，这就是那句著名的 “我要做别的事情去了。Gavin 和各位会把这件事做好。” 的出处 ³³。

“带着中本聪的祝福” ³⁴，Andresen 接手了 Bitcoin 项目维护者主管的职责，扩大了维护者团队，同时开始着手从 Sourceforge 迁移到 Github ³⁵。这个过程花费了不少时间。一直到 2011 年 7 月 14 日，我们看到第一个提交，来自 Andresen 的正式 github 账户的一个分支，合并到 Bitcoin 项目中 ³⁶，这个过程才算完成。

与中本聪时代不同，这次合并是由 Github 平台完成的；这样做等于是交托了一些信任给 Github.com，相信它不会对代码动手脚；以往，这个过程都是由中本聪手动在自己的机器上完成的。值得指出的是，不管怎鹅模样，不论是否由 Github 来合并，不同版本的代码差异是可以审计的，因为项目本身是开源的。在这个时代，代码合并可以由流程两端的开发者在 Github 合并之前以及之后审核（大概就是如此），虽然充分的谨慎最终导致受信任公钥系统的诞生。不过，这还是开启了一种新的趋势，决定了 Bitcoin 项目在接下来至少三年时间里的代码合并方式。

2011 年 9 月 13 日，Sourceforge 平台上的 Bitcoin 项目正式关闭，将 Github 作为新的合作平台，旧的 Bitcoin 项目页面从此变成了档案。因为 Malmi 和 Lazloh 主要在 Sourceforge 上贡献代码，那时候没有 Github 账户，所以他们的 commit 权限也随着这次正式的迁移而实际上终结，同时，随着中本聪的离开，他们的贡献频率也下降了。

2011 年 4 月 27 日，0.3.21 版本发布，这是在 Andresen 领导下的第一个版本。它也是第一个包含了一个 “Readme” 文件的版本，其中包含了一条 PGP 签名过的消息 ³⁷，细数了更新的内容、包含了发布的安装文件和哈希值，并向贡献者们表达了感谢。被提名的 16 位贡献者中，有一些是广为人知的 Bitcoin Core 开发者，比如 Luke Dashjr、Matt Corallo、Pieter Wuille 和 Jeff Garzik 。

接下来的几年里，也许是为了分散 Gavin 通过维护者角色而获得的权力和责任、以及填补由中本聪、Malmi 和 Lazloh 离开而留下的空白，出现了一些新的维护者。Chris Moore ³⁸ 使用名字 “dooglas”，在 2011 年 1 月 21 日 ³⁹ 到 3 月 31 日 ⁴⁰ 期间拥有 commit 权限；并且此后依然是项目的贡献者 ⁴¹。

几个月后，在 2011 年 6 月的第一天，Pieter Wuille 获得了 commit 权限 ⁴²。Wuille 是在 2010 年发现比特币的，并且很快就开始给这个项目贡献代码。获得 commit 权限之后，Wuille 逐渐成为一位著名的 Bitcoin Core 开发者，因为提供了许多小型的性能提升、累积出用户体验上的巨大提升，以及许多其他贡献，而收获了尊敬 ⁴³。直到今天，Wuille 依然是给 Bitcoin Core 提交代码次数的第三名，他在 Github 上的用户名是 “sipa”。

Jeff Garzik 在几天后（6 月 6 日）成为维护者 ⁴⁴。Garzik 从当年的 0.3.21 版本就开始给 Bitcoin 项目贡献代码，并且后来也成为著名的比特币开发者。他将来自 Linux 开源生态系统的经验 ⁴⁵ 带到 Bitcoin 项目中。Garzik 常常被赞誉提高了 Bitcoin 客户端的稳定性。

多年以后，在 2016 年夏天，在 “连续数月没有活动” 之后，Garzik 的 commit 权限被撤销（说法来自 Chow 的文件）。在比特币的 “区块体积战争” 开始升温的那些年里，Garzik 站在扩大区块的升级那边 ⁴⁶；区块体积战争导致了许多争论以及比特币社区一些成员之间的摩擦，可能也是他的开发活动减少的一个原因。后来，Garzik 还在战争爆发一年以后领导了一次失败的分叉运动，版本号为 “Segwit2x”。

译者注：为方便读者理解在上下文中一再出现的 “提交次数” 指标，此处添加一些说明。

Git 和 SVN 这样的版本控制系统，将一个软件的代码基础（code base）视为一个可以不断变更状态的代码库（repository），这是它支持分布式开发的基础。开发者不断添加和删除代码，就是在不断变更代码库的状态；而每一次状态变更，都会以一个 “commit（提交）” 来标记（它是一个哈希值）。

前面已经提到，在开源开发的项目（按照定义就是分布式开发的）中，人们通过 “复刻（fork）” 代码库、在本地修改后（形成新的 commit）之后向原代码库发送 “Pull Rrquest（PR，合并请求）”，来推动原代码库的更新。

为方便工作并行开展，代码库往往会形成多个 “分支（branch）”。并且，这些 PR 在发出之后，可能也要经历进一步的修改（又形成新的 commit）；最终，一个 PR 合格之后，由维护者将它（包含多个 commit）合并（merge）到主分支（这次合并也会形成一个 commit）。

因此，所谓的 “提交次数”，统计的是该用户参与修改代码库状态的次数，并不等于发送 PR 的次数。也正因此，作者才提到，许多维护者的提交（commit）主要是合并（来自其他人的 PR）。可以说，这个数字统计的是其人参与开发的程度之深，而不是该人最先提议的代码变更数量多少。

2011 年 7 月 5 日，Mara van der Laan（那时候叫做 “Wladamir”）获得了 commit 权限，成了 Bitcoin Core 的第八位正式的维护者。Van der Laan 早在 2010 年 11 月就开始在 Bitcointalk 论坛上活跃，从 2011 年 5 月开始给 Bitcoin 项目贡献，最初关注的是 Bitcoin QT 客户端的图形界面，并且带来了计算机图形学的深厚学术经验 ⁴⁸。

2011 年 9 月 19 日，Nils Schneider（用名 “tcatm”）在频繁贡献、优化了 Bitcoin 客户端在后台的工作表现之后，获得了 commit 权限。在他担任维护者期间，他为客户端的国际化作出了重大贡献：添加了多个与多语言支持相关的更新 ⁴⁹；监督了 “Crypto++” 依赖库的移除，减少了不必要的依赖项 ⁵⁰。Nils 担任维护者的时间差不多有一年，他的最后一次提交是在 2012 年 3 月 31 日发出的 ¹⁵。

2012 年 2 月 11 日 ⁵²，Gregory Maxwell（用名 “gmaxwell”）第一次合并了代码。此前他已经贡献了多项代码，并且在 Bitcointalk 论坛上发表技术评论、活跃了一整年 ⁵³。从此，他开始了作为维护者的三年生涯。在此期间，Maxwell 关注的主要是客户端的 P2P 联网层，以及与共识机制和验证相关的工作。直至今日，他在广大的比特币社区中依然享有非常高的尊敬，并且偶尔还会参加在技术讨论和辩论。Maxwell 在 2015 年 12 月放弃了 commit 权限：随着区块体积战争开始升温，因为他支持小区块，互联网上的骚扰随之而来。

Bitcoin Core 维护者团队在一年多的时间里持续扩张。到了 2012 年 9 月 27 日，Gavin 宣布了他对比特币的未来的个人愿景的下一个阶段，“比特币基金会（Bitcoin Foundation）” ⁵⁵。这个基金会模仿了 “Linux 基金会” —— Gvain 将 Linux 操作系统视作成功的大型开源项目的一个绝佳案例 —— 吸引了许多关注和支持，也招来了许多批评。在公告中，Gavin 说：“我希望比特币基金会成为一个开放的、会员驱动的组织，并且希望你和你的组织不仅成为一个会员，也帮助基金会实现它的使命”。接下来几年时间里，这个基金会帮助支付了许多 Bitcoin Core 贡献者和维护者的薪水。

Mara van der Laan 时代

2014 年 4 月，Mara van der Laan 被 Gavin Andresen 选为自己的继任者，担任维护者主管，因为 Andresen 已经决定转型成一个更有学术色彩的角色，他称为 “首席科学家”。在 Andresen 发布在比特币基金会网站的一篇博文 ⁵⁶ 中，他说：“迄今，Mara van der Laan 已经接受报酬、为 Bitcoin Core 全职工作几个月了 —— 再次感谢各位基金会成员挺身而出、资助 Bitcoin Core 的开发 —— 并且一直做得非常出色。他已经同意接替我成为 ‘ Bitcoin Core 维护者’。”

从此，Ven der Laan 使用名字 “Laanwj” 和 “wumpus”，领导 Bitcoin Core 的开发长达 9 年时间，直至今日，依然是向 “bitcoin” 代码库 ⁵⁷ 提交代码次数最多的人（根据 Github 网站的统计，共计 7419 次 —— 绝大多数都是合并代码）。根据 Chow 的记录，“出于个人原因”，Ven der Laan 在 2023 年 2 月辞去了维护者角色。

Ven der Laan 担任维护者的时候，带来的第一项变更（也是最重大的变更之一）是实现了前面说的受信任公钥系统，由 Matt Corallo 在 2014 年 12 月 20 日提交 ⁵⁸。这个系统通过向 “bitcoin” 代码库主分支添加包含 PGP 公钥指纹的文件（以及一系列相关的工具） ⁵⁹，帮助解决了维护者角色的不透明问题。其中一项工具会确保维护者的提交（commit）是由 PGP 签名过的，另一个脚本则可用来根据受信任的 PGP 公钥的清单来验证提交的签名。

因为这些公钥包含在代码库的主分支中，所以只有维护者可以（凭借有效的签名）向清单添加公钥和从清单移除公钥，这就会在 Git 的版本控制系统中留下记录，同时，我们因此可以用 PR 来添加和移除维护者，贡献者们都可以在 PR 页面发表评论。

2015 年 11 月 13 日，Jonas Schnelli 获得了 commit 权限，他的用户名是 “jonasschnelli”。Van der Laan 为他授予了 GUI 库维护者角色，也在 bitcoin 邮件组中宣布了 ⁶⁰。Schnelli 从 2013 年开始给比特币贡献代码，后来成为了在 Github 上 Bitcoin 项目的前 10 名贡献者之一；许多提交似乎也是在担任维护者期间为代码库合并代码。他担任维护者长达六年，在 2021 年 10 月 21 日放弃 commit 权限；他在 Twitter 社交媒体捧台上写了一篇帖子，展示了他的经历，并表达了对未来的比特币开发者社区的强烈信心 ⁶¹。

根据 Corallo 的说法，受信任公钥系统的主要角色是 “避免信任 Github” 来合并开发者的代码 —— 这是在 Andresen 时代常态化的做法。此后，维护者会在本地合并代码，然后更新代码库。

译者注：从形式上来说，Github 网站上有两个项目：（1）“Bitcoin” 项目，包含 “bitcoin” 库（能够编译出 Bitcoin Core 软件的代码）和 “BIPs” 库；（2）“Bitcoin Core” 项目，包含上文所说的 “GUI” 库（可以编译出 Bitcoin Core 的图形界面版本 Bitcoin QT），以及其它代码库。

2016 年 4 月 13 日，Marco Falke（用户名为 “maflcko”）获得了 commit 权限 ⁶²。Van der Laan在 bitcoin 邮件组中宣布了这个决定 ⁶³，原话是：“在这里，我宣布 Marco Falke 作为 Bitcoin Core 的新的 ‘Testing & QA（测试与质量控制）’ 维护者”。Falke 一直给 Bitcoin Core 贡献代码，直到 2023 年，他出于个人原因，放弃 commit 权限和维护者身份 ⁶⁴。

不到一个月之后，2016 年 5 月 6 日，Gavin Andresen 的 commit 权限被移除。这个决定是 Van der Laan 作出的 ⁶⁵，在 Andresen 给（现在众所周知是假冒了中本聪的）Criag Wright 站台之后。当时，比特币社区的许多人都已经怀疑 Wright 的说法，而 Andresen 当时的立场也被迅速揭晓是出于 Wright 的欺骗。几个月前，被视为与 Andresen 来往密切的一个 Bitcoin 项目的贡献者 Mike Hearn，就在一档播客里鼓吹 Andresen 应该撤销所有其他维护者的 commit 权限，成为 Bitcoin 项目的 “仁慈独裁者” ⁶⁶，就像许多其它开源项目已经形成的那样。Andresen 没有听从 Hern 的建议，但这件事情表明了比特币社区内部的紧张气氛。随着区块战争开打，Wright 也参与其中。

多年以后，Andresen 曾经表达对这些事情的后悔，他说：“我现在晓得以前那么信任 Craig Wright 是错的了。我后悔自己卷进那个 ‘找找谁是（谁不是）中本聪’ 的游戏。我再也不玩了。”

又过了许多年，才有另一位贡献者获得 commit 权限。2018 年 12 月 4 日，Samuel Dobson（用户名为 “MeshCollider”）被 Van der Laan 提名为钱包模块的维护者 ⁶⁷。Dobson 最晚从 2017 年夏天就开始给 Bitcoin 项目贡献代码，并且在作为比特币开发者的生涯中，总计制作了超过 300 次提交，主要关注的是 Bitcoin Core 的钱包模块。为了拿到博士学位，Dobson 在 2023 年 2 月放弃了自己的 commit 权限和维护者角色 ⁶⁹。

2019 年 6 月 7 日，Michael Ford 获得了 commit 权限；他是至今仍在担任工作的最新一代维护者中最早加入的。Ford 的用户名是 “Fanquake”，可能是第一位因为贡献者内部的共识而获得 commit 权限的贡献者（在阿姆斯特丹的一次 Bitcoin Core 开发者会议上被提名） ###70## ⁷¹ 。在这个时期之后，由贡献者共识来提米，变成了一种趋势，表明 Bitcoin 项目的开发走向去中心化；会议会在许多地方和环境下举行，甚至是通过 IRC（互联网在线聊天室）。

Ford 从 2012 年 2 月开始给 Bitcoin 项目贡献代码 ⁷²，因此是 Bitcoin 项目历史上最资深的维护者之一。根据 Github 网站的统计，Ford 以 4920 次提交，位列迄今为止提交次数最多的第二名；许多提交都是对其他贡献者工作的合并和维护性更新。

贡献者共识时代

2021 年 1 月 21 日，Van der Laan 发出了一篇博客文章 ⁷³，打破了从中本聪和 Andresen 开始的传统 —— 为 Bitcoin Core 的开发安排维护者主管。在这篇博文中，Van der Laan 说她将逐步委托他人承担维护者主管的许多工作，并且解释说：Bitcoin 已经成了一个很大的项目，无法在使用由中本聪和 Andresen 建立的模式了，而且，是时候让 Bitcoin Core 的开发分散化了。

Van der Laan 列出了其他人需要承担的一系列责任，并为 Bitcoin 项目的软件发布流程更具审查抗性留下了一份路线图，比如，将 Bitcoincore.org 网站的所有权移交给一个组织，而不是由她控制，同时鼓励大家制作镜像网站；新版本的安装文件通过 torrent（甚至 IPFS）来分发；怀疑 Github.com，呼吁开始寻找替代的代码贡献平台；一种用在维护者之间的门限签名方案，使得他们可以通过某种密码学共识来签名发行版本，而不是让某个人成为一个版本的最终 PGP 签名人；等等。

这篇文章实际上标志着 Van der Laan 作为维护者主管的角色的终结，也是一个里程碑，象征着 Bitcoin 项目的成熟，就在 0.20.0 版本发布的几个月后、0.21.0 版本发布的几天前 ⁷⁴。

Hannadii Stepanov（用户名为 “hebasto”）在 2021 年 3 月 19 日获得了 commit 权限，成为了 Bitcoin 客户端的 GUI 库维护者 ⁷⁵。Stepanov 从 2018 年 8 月开始给 Bitcoin Core 贡献代码 ⁷⁶，在成为一名维护者之前，积累了超过一千次代码贡献，使他位列 Github 的 Bitcoin 项目提交次数排名的第 5 位，截至当前，总计 2070 次。Stepanov 在本文撰写之时仍在担任维护者。

Ava Chow 在 2020 年 12 月 12 日获得 commit 权限 ⁷⁷，成为钱包模块维护者；她从 2016 年 1 月开始贡献代码 ⁷⁸。她的用户名是 “achow101”，是一位著名的贡献者，对比特币开发社区的贡献不仅限于 github 上的提交，还包括许多关于 Bitcoin Core 维护者的大量历史学研究。Chow 也因为在 Twitch 上直播审核 Bitcoin Core 代码 ⁷⁹ 而知名；这个直播界面吸引了一些活跃的听众，也推动了比特币技术的教育。Chow 在 Github 上以 2198 次提交排名第四，在本文撰写之时依然拥有 commit 权限。

Gloria Zhao 在 2022 年 8 月 7 日获得了 commit 权限，也是由贡献者共识提名的 ⁸⁰，角色是交易池策略维护者 ⁸¹。Zhao 从 2020 年 3 月开始贡献代码，在获得 commit 权限之前至少提交了 200 次代码。现在，她以 777 次提交排名第 9 位。Zhao 在今天依然是维护者。

Russ Yanofsky 在 2023 年 6 月 10 日获得了 commit 权限 ⁸³，由贡献者共识提名 ⁸⁴，角色是接口维护者。Russ 专精于模块化和多线程工作，这使他获得了维护者角色。他从 2016 年 10 月开始贡献代码 ⁸⁵，迄今总计提交 970 次代码，排名第 7 位。Yanofsky 的用户名是 “rynofsky”，至今依然是维护者。