szhbsd 中本聪离开比特币后越来越多的项目方参与进来，之后促成了 BIP （比特币升级提议）流程的诞生。
原文标题：《干货 | 不完整比特币开发史（上）：简述》 撰文：0xB10C 翻译：阿剑
要想完全理解比特币开发现状背后的原因，就不能不了解一些历史事件。本文着重列举了中本聪离开这个项目前后的历史事件、软件发布和漏洞修复；还额外添加了一个章节叙述比特币开发的现状。文章后附的时间线为每一个事件提供了额外的细节。
对于这里的大部分事件，我都不是亲历者。所以这份时间线的一大部分引自 John Newbery 的一次名为 「比特币开发的历史与哲学」 的演讲。本文的标题也写得很清楚了，本文没有，也做不到包含每一个重要事件。历史总在不断变化，如果你认为我遗漏了什么事件，或想提议我作一些修改，请在开源项目 bitcoin-development-history 中提交一个 issue，这也是我用来附加更多时间线的办法。
中本聪仍在的时候
这份时间线的起点是 2007 年早期。中本聪开始开发比特币。这个点对点的电子现金系统没有受信任的地方。整个系统完全由用户运行的软件来控制。
早期，有贡献者加入了中本聪的工作。除了软件的开发，这些新来的贡献者还为软件添加了 Linux 和 maxOS 操作系统的支持。到了 2010 年夏天，中本聪给软件做了一些关键的修改。比如，引入了 「检查点」 作为一项安全措施，来对抗传播低难度链的攻击。使用了这些检查点的节点会拒绝那些特定高度与特定区块不符的链。检查点是由中本聪独自硬编码的，理论上来说，这让中本聪可以自己决定整个网络要跟随哪条链。
加入检查点的几天后，中本聪在版本 v0.3.3 的软件中放出了第一个共识机制变更。中本聪敦促用户升级。在接下来一个月里，多个小版本更新陆续放出。其中一个修复了一个致命的溢出漏洞。这个漏洞被利用来创造了两个高价值的 UTXO。中本聪建议矿工们重组包含了恶意交易的区块。
一周以后，中本聪加入了一个警报系统，来提醒节点运营者网络中出现的类似 bug 和问题。这个警报系统有一个安全模式。这个安全模式一旦触发，就会禁用整个网络的所有关于货币处理的 RPC 方法。只有中本聪能够用一个私钥签名来创建有效的网络警报。一些用户开始提出质疑：如果其他人，比如某个政府，拿到了这个私钥，那网络会变成什么样呢？
这个时候，中本聪对比特币网络有太大的权力。但大家主要担心的不是中本聪会变坏、会摧毁整个网络，而是一个去中心化的网络中不应该存在一个单点故障。
到了 2010 年 10 月，中本聪在 Bitcointalk 论坛上发布了他的最后一个帖子，宣布移除这个安全模式。中本聪在他最后留下的电子邮件之一里面写道：「我准备到别的地方去了。有了 Gavin 和大家，这个项目会得到很好的维护。」 一些人主张，中本聪离开比特币世界，是他最伟大的贡献之一。
中本聪离开之后
几乎同一时间，整个开发流程从 SVN 转移到了 GitHub 上。BlueMatt、sipa、laanwj 和 gmaxwell 加入了这个项目。在 2011 年中，BIP （比特币升级提议）流程应运而生。在 2011 年的最后一个季度和 2012 年的第一个月，社区讨论了允许交易的接收者指定花费条件的多个提案。由此，P2SH 交易引入了比特币。
在 2012 年末，比特币基金会宣告成立。比特币基金会（Bitcoin Foundation）模仿的是 Linux 基金会。在公告帖子下面，一些人留言表示担心开发会变得中心化。
Bitcoin v0.8.0 在 2013 年春天发布。两周以后，一场意料之外的硬分叉在网络中升级了和没升级的节点间爆发。硬分叉很快就被解决了，矿工们都把挖矿算力切换到了对已升级和未升级节点都有效的链上。
在 2013 年末，Bitcoin 软件更名为 Bitcoin Core。在接下来几年里，包括 Chaincode 和 Blockstream 在内的公司成立。后来，MIT Digital Currency Initiative 加入了 Chaincode 和 Blockstream，为开发比特币的开发者和研究者提供报酬。在 2015 年二月，Joseph Poon 和 Tadgw Dryja 放出了闪电网络白皮书的第一份草稿。
第二年，Luke Dashjr 通过 BIP 2 修订了 BIP 流程；Bitcoin Core 放出了 v0.13.0，加入了 SegWit 作为软分叉。在 2016 年 11 月，警报系统完全弃用。到了 2017 年 8 月，SegWit 在比特币网络上激活。2019 年，又一家公司 Square Crypto 开始资助比特币开发。在 2019 年 5 月，Pieter Wuille 提出了 BIP Taproot。
比特币开发的现状
在过去几年中，比特币的开发文化日益去中心化、目标明确而且严格。现在 Bitcoin Core 代码库有 6 名维护者，分布在三个国家。只有他们能够合并由贡献者提出的代码更改。不过，在内容合并之前，更改的内容还需经过一个审议流程，这个流程也变得严格得多。
举个例子，在比特币早期，有个与 P2SH 相竞争的提议，叫做 「OP _ EVAL」。有个实现了 OP _ EVAL 的 pull request （「合并请求」）在 2011 年底被合并到了代码库中。即便是这样对共识有重大变更的代码，它也只有一个审核人。Russell O’Connor 开了一个 issue 批评了这个实现的一部分，并主张这么大的、对共识极为关键的变更应该得到更多的审核和测试。
这件事推动了如何通过更多的测试和审核来实现更高质量的代码的持续讨论。到了今天，每一个合并请求都有多个开发者来审核。如果某个改变触及到了对安全性甚至共识的关键部分，审核的流程还需要通过更多的审核员审核，需要大量的测试，通常会花费几个月的时间。活跃的 Bitcoin Core 贡献者 John Newbery 告诉我，「只需一个审核人员首肯就能合并影响共识的代码的事情，已经一去不复返」。
人们也投入了很多精力到自动化的测试中，比如，有 C++ 语言编写的单元测试和 Python 语言编写的功能性测试。每一个不简单的变更都要相应更新现有的测试或者在框架中加入新的测试。在单元测试和功能测试以外，还要在 Bitcoin Core 上做模糊测试，以及建立基准测试框架来度量代码的性能。举个例子，bitcoinperf.com 网络提供了 Grafana 和 codespeed 接口来可视化周期性的基准测试的结果。
多年努力下来，Bitcoin Core 软件已经形成了一个清晰的发布流程。Bitcoin Core 的大版本每 6 个月发布一次。发行计划包括一个翻译流程，一个特性冻结流程，还通常有多个候选版本。近期 Cory Fields 和 Carl Dong 还致力于提高 Bitcoin Core 构建过程的安全性，使用确定性和可引导的构建包。这个新的构建系统可能还没准备好支持即将在今年秋天发布的 Bitcoin Core v0.19.0，但未来可以提供更好的构建过程安全性。
结论
十年间，比特币的开发文化沧海桑田，从围绕中本聪的高度中心化，变为围绕几千名 GitHub 贡献者（2018 年数据）的去中心化。显然，代码审核、代码质量和安全性的高标准都是有必要的。这些标准得到了遵循和持之以恒的提高。
我认为，要完全理解比特币开发现状背后的哲学，了解这些历史事件是必不可少的。所以我做了一个把更多事件串起来的时间线。
若有进一步的研究需求，建议阅读 Alex B. 写的《The Tao Of Bitcoin Development （比特币开发之道）》、Eric Lombrozo 写的《The Bitcoin Core Merge Process （Bitcoin Core 代码合并流程）》以及 Jameson Lopp 的大作《Who Controls Bitcoin Core？（谁控制着 Bitcoin Core？）》。
致谢
感谢 John Newbery 帮助我梳理并审核这篇文章。他在自己的演讲《History and Philosophy of Bitcoin Development （比特币开发的历史和哲学）》中做了很多历史考证工作，该演讲也是我这篇文章的基础。此外，我非常感激 Chaincode Labs，他邀请我参加他们的 2019 夏令营（Summer Residency），在那里我遇见了很多有意思的人，学到了很多东西，也正是在那里，我开始着手整理时间线和撰写这篇文章。
