BCHABC 与BCHSV之战

交易货币VS 投资资产

BITcoin Core 路在何方？

BCHABC与BCHSV之战搅的整个币圈风声水起，关于BTC是否背离了中本聪的初衷的声音也莫衷一是。最终，BCHABC棋高一筹，积累了更多的工作量证明了实力。

自从今年8月1日比特币现金（BCH）开了头之后，比特币（BTC）硬分叉就变得一发不可收拾。

截止目前包括已经分叉成功的，即将分叉的，还有宣布失败的就有6种。那么比特币频繁的硬分叉背后，BTCCoin Core 开发者团队持有怎样的观点，这也许意味着资本大鳄的真实意向。

多年来，谁控制Bitcoin Core的GitHub存储库的问题反复出现，这被多方称为比特币协议的“中心控制点”。但笔者认为，这本身是一个转移注意力的问题，它产生于权威主义的视角--这种模式并不适用于比特币。

对于外行人来说，这当然不是显而易见的，因此本文的目的是解释Bitcoin Core是如何运作的，比特币在Bitcoin core团队手中是如何发展的。

Bitcoin的历史

Bitcoin Core是开发比特币协议的一个焦点，而不是一个命令和一个控制点。如果它由于任何原因不复存在，那么就会出现一个新的焦点——它所基于的技术通信平台（目前是GitHub存储库）仅仅是为了方便，而不是项目的完整性。事实上，我们已经看到了比特币在开发平台甚至名称方面的重点转变。

2009年初，比特币项目的源代码只是SourceForge上托管的一个rar文件，比特币项目早期的开发者们会通过电子邮件与中本聪交换代码。

2009年10月30日，Sirius（Martti Malmi）在SourceForge上为比特币项目创建了一个subversion存储库。

2011年，比特币项目从SourceForge迁移到GitHub。

2014年，比特币项目更名为Bitcoin Core。

没有任何个人具有太多特权

尽管组织中有一些GitHub的“维护者”帐户能够将代码合并到主分支中，但这更像是一种清洁功能，而不是所谓的权力地位。如果任何人都可以进行合并，那么很快就会变成“厨房里的厨师太多”。

 Bitcoin Core遵循最小特权原则，即如果被滥用，任何赋予个人的权力都会被其他人弹劾从而丧失特权。

抗拒者认为，由于任何数量的GitHub“维护者”都可以使用他们的管理特权将代码注入到存储库中，而不需要维护人员的同意，因此Github 的代码并非是完全可信的。但是，GitHub攻击者也不可能攻破比特币核心维护者的PGP密钥。

Bitcoin Core不是基于GitHub帐户的代码完整性，而是具有持续集成系统，该系统执行必须对每个合并提交进行签名的可信PGP密钥的检查。 

虽然这些密钥与已知身份相关联，但仍然不能安全地认为它总是如此 - 密钥可能会受到损害，除非原始密钥所有者通知其他维护者，否则我们不会知道。 因此，提交密钥也不能提供完美的安全性，它们只会使攻击者更难以注入任意代码。

通往王国的密钥

在编写本文时，这些PGP指纹是可信的：

71A3B16735405025D447E8F274810B012346C9A6

133EAC179436F14A5CF1B794860FEB804E66932032EE5C4C3FA15CCADB46ABE529D4BCB6416F53ECB8B3F1C0E58C15DB6A81D30C3648A882F4316B9BCA03882CB1FC067B5D3ACFE4D300116E1C875A3D

这些密钥被注册为：

Wladimir J. van der Laan <laanwj@protonmail.com>Pieter Wuille <pieter.wuille@gmail.com>Jonas Schnelli <dev@jonasschnelli.ch>Marco Falke <marco.falke@tum.de>Samuel Dobson <dobsonsa68@gmail.com>

这是否意味着我们能信任这五个人？并不是这样。密钥不能证明身份——这些密钥可能落会入其他人的手中。如果运行verify-commits python脚本，你真的能得到的保证是什么？

python3 contrib/verify-commits/verify-commits.py Using verify-commits data from bitcoin/contrib/verify-commitsAll Tree-SHA512s matched up to 309bf16257b2395ce502017be627186b749ee749There is a valid path from “HEAD” to 82bcf405f6db1d55b684a1f63a4aabad376cdad7

事实上，能真正信任的只是这些已经签名的。

verify-commits脚本是一个完整性检查，任何开发人员都可以在他们的机器上运行。

执行后它会在2015年12月提交82bcf405之后，检查每次合并提交时的PGP签名 - 在编写时超过3,400次合并。如果脚本成功完成，它会告诉我们自那时以来已经更改的每一行代码都已通过比特币核心开发过程，并由具有维护密钥的人“签字”。

虽然这不是一个防弹保证，没有人注入恶意代码（维护者可能成为流氓，或者他们的钥匙被盗），但它会大大减少攻击面。什么是维护者以及他们是如何实现这一角色的？我们稍后会深入研究。

分层安全

比特币核心代码的完整性不能仅依赖于少数加密密钥，这就是为什么存在大量其他检查的原因。这有许多安全层来提供深度防御：

拉请求安全性

• 任何人都可以通过在比特币/比特币上打开针对主分支的拉取请求，来自由地提出代码更改，以改进软件。

• 开发人员审核拉取请求以确保它们无害。任何人都可以自由地审查拉取请求并提供反馈 - 在为比特币核心做出贡献时，没有看门人或入学考试。如果一个pull请求达到了对它的合并没有合理的反对意见，那么维护者就会进行合并。

• 核心维护者设置审核准则以确保它们不会将未签名的提交推送到存储库中。

• 可以选择通过OpenTimestamps对合并提交进行安全时间戳。

• Travis Continuous Integration系统定期运行此脚本以检查git树（历史记录）的完整性，并验证master分支中的所有提交是否都使用其中一个可信PGP密钥进行签名。

• 任何想要运行此脚本以验证所有合并提交的PGP签名的人都可以追溯到2015年12月。我在撰写本文时运行它， 花了25分钟在我的笔记本电脑上完成。

发布安全性

• Gitian确定性构建系统由多个开发人员独立运行，目标是创建相同的二进制文件。如果有人设法创建与其他开发人员的构建不匹配的构建，则表明引入了非确定性，因此最终版本不会发生。如果存在非确定性，开发人员会找出出错的地方，修复它，然后构建另一个候选版本。一旦确定性构建成功，那么开发人员就会对生成的二进制文件进行签名，从而保证二进制文件和工具链不被篡改并且使用了相同的源。此方法将构建和分发过程作为单点故障删除。任何具有技术技能的人都可以运行自己的构建系统。

说明在这里：

使用SVM或物理系统为Gittian的位币核心区块设置指令。Gitian是用于构建比特币核心可执行文件的确定性构建过程。它提供了一种合理地确保可执行文件确实是从git源构建的方法。它还确保使用相同的、经过测试的依赖关系并将其静态地构建到执行命令中。

• 一旦Gitian构建成功完成并由构建者签名，Bitcoin Core维护者将用每个构建的SHA256散列对消息进行PGP签名。如果你决定运行预先构建的二进制文件，则可以在下载后检查其哈希值，然后使用哈希值验证签名版本消息的真实性。这里可以找到这样做的说明。

以上所有内容都是开源的，任何人只要具备这种技能和愿望，都可以对其进行审核。

• 最后，即使经过了上述所有质量和完整性检查，提交到Bitcoin Core并最终进入版本的代码也不会被任何集中式组织部署到节点网络上。相反，每个节点操作员必须做出有意识的决定以更新它们运行的代码。比特币核心故意不包括自动更新功能，因为它可能用于让用户运行他们没有明确选择的代码。

尽管比特币核心项目实施了所有技术安全措施，但它们都不是完美的，理论上它们中的任何一个都可能受到损害。比特币核心代码完整性的最后一道防线与任何其他开源项目相同。因此始终保持警惕，审查比特币核心代码的眼睛越多，恶意或有缺陷的代码进入发布版的可能性就越小。

代码覆盖率

比特币核心有很多测试代码。每个PR运行都有一个集成的测试套件，每晚都会在主服务器上运行扩展的测试套件。

你可以通过以下方式检查测试的代码覆盖率：

• 克隆比特币核心GitHub存储库

• 安装从源构建所需的依赖项

• 运行这些命令

• 在./total_coverage/index.html中查看报告

• 或者，您可以在此处查看Marco Falke主持的报道报告

具有如此高水平的测试覆盖率，意味着代码按预期运行会具有更高的确定性。

当涉及到共识关键软件时，测试是一个大问题。对于特别复杂的更改，开发人员有时会进行突变测试。也就是说，他们会通过故意破坏代码并查看测试是否按预期失败来测试这个测试。 

Greg Maxwell在讨论0.15版本时对这个过程给出了一些见解： “测试是软件的测试，但是测试的测试是什么呢？该软件。要测试这个测试，你必须破解该软件。”  ——Greg Maxwell

自由市场竞争

BitMEX写了一篇关于比特币实现生态系统的精彩文章。有十几种不同的比特币兼容实现，甚至还有更多的“竞争网络”实现。这是开源的自由——任何对Bitcoin Core项目的努力不满意的人都可以自由地开始自己的项目。他们可以从零开始，也可以分叉核心软件。

在撰写本文时，96％的可达比特币节点正在运行某种版本的Bitcoin Core。为什么会这样？如果切换到另一个软件实现所需的工作量最小，那么Bitcoin Core如何在节点网络上具有近乎垄断的地位？毕竟，许多其他实现提供了与Bitcoin Core兼容或至少高度相似的RPC API。

我认为这是Bitcoin Core成为发展重点的结果。它拥有大量开发人员的时间和支持它的人才，这意味着由Bitcoin Core项目生成的代码往往是最有性能、最健壮、最安全的。在资金管理方面，节点运营商只想运行最好的软件。此外，考虑到这是共识软件，而且比特币协议没有一个正式的规范，因为没有人有权利编写规范。使用焦点实现比较安全，因为你更有可能与大多数网络的其他部分兼容bug-for-bug？。从这个意义上说，开发焦点的代码与现有的规范最接近。

谁是核心开发成员

不熟悉Bitcoin Core开发过程的人可能会从外部看项目，并将Core视为一个单一实体。事实并非如此！

Core贡献者之间经常存在分歧，即使是最多产的贡献者也编写了大量从未合并到项目中的代码。如果你阅读了贡献指南，你可能会注意到它们相当宽松 - 这个过程最好被描述为“粗略的共识”。

维护者将考虑补丁是否符合项目的一般原则；是否满足包含的最低标准；以及是否判断贡献者的一般共识。

Bitcoin Core 的核心维护者是谁？他们是那些通过在一段时间内做出高质量的贡献，在项目中积累了足够社会资本的贡献者。当现有的维护者组认为，将角色扩展到在某个领域表现出能力，可靠性和动机的贡献者时，他们可以授予对该人的GitHub帐户的提交权限。

主要维护人员的角色是对项目的所有方面进行监督并负责协调发布的人。它多年来一直是自愿传递的：Satoshi Nakamoto：1/3/09 - 2/23/11

Gavin Andresen：2/23/11 - 4/7/14

Wladimir van der Laan：4/7/14 — 至今

Bitcoin Core的 维护者通常被称为清洁员，因为维护者实际上没有权力做出与贡献者或用户的共识背道而驰的决策。然而，由于生态系统的额外关注，这个角色可能会非常繁重。

例如，Gregory Maxwell在2017年由于个人原因放弃了他的维护者角色，可能是因为他在规模辩论中遇到的公众压力。Wladimir写了一篇深思熟虑的文章，讲述了作为核心维护者的压力，以及为什么应该删除Gavin的提交访问权限，这让很多人感到不满。

类似地，当Jeff Garzik从GitHub组织中被移除时，他和其他人对此感到不满，可是他在两年内没有为Core做出贡献。让他的GitHub帐户具有对存储库的写入权限，这对项目没有任何好处 - 它只会产生安全风险并违反了Wladimir 在其文章中提到的最小权限原则。

其他人可能看了看Core，并认为它是一个技术专家或象牙塔，使新进入者难以加入。但是，如果你与贡献者交谈，你会发现事实并非如此。虽然这些年来只有十几个人有过访问权限，但仍有数百名开发人员做出了贡献。我自己做了一些小小的贡献;虽然我不认为自己是“核心开发者”，但从技术上讲，我就是其中之一。没有人可以阻止你做出贡献！

人们最关心的事情之一似乎是比特币开发的焦点不仅仅是比特币核心GitHub帐户定义的结构。虽然Bitcoin Core有一些结构（它使用集中通信渠道进行协调），但项目本身不受任何参与者的控制 - 即使是那些在GitHub存储库上升级了特权的人。

虽然维护人员组织的政变技术上有可能劫持GitHub存储库，审查不同意见的开发人员，甚至可能维持“比特币核心”的品牌名称，但结果将是比特币核心将不再是开发焦点。

不同意维护者行为的开发人员只需将代码分叉并将其工作转移到不同的存储库，而比特币核心维护者没有管理员权限。

即使没有“政变”本身，如果一个有争议的变化以某种方式进入Core，一些开发人员会分叉软件，创建有争议的变化，并使其可供用户使用。你可以争辩说，这正是当Amaury Sechet分叉Bitcoin Core并删除了隔离见证功能来创建比特币ABC时发生的事情。或者，如果Core拒绝某些人想要的更改建议，开发人员可以分叉并添加这些更改。

这已经发生了很多次，例如：Mike Hearn分叉Core创建比特币XT

Andrew Stone分叉Core创造了比特币无限

Jeff Garzik分叉Core创建BTC1

分叉代码很容易，转移比特币开发的重点是很难的 - 你必须说服贡献者，让他们花时间更好地为不同的项目做贡献。

很难说服许多人不要盲目跟随比特币核心的变化，这可能是一种自我强化的信念，因为如果用户不了解他们的选择而不参与共识过程，他们就会把他们的一些权利让给开发者。

然而，在2017年的UASF（用户激活的软叉）运动中，用户的权力得到了行使。一名使用假名shaolinfry的匿名比特币开发商提出了BIP 148，这迫使矿工在将发生的区块高度激活隔离见证功能。可是，BIP 148被证明太有争议而不被Bitcoin Core所采用，所以shaolinfry分叉Core并制作了“比特币UASF”软件。

这个软件的实现获得了非常大的牵引力，似乎产生了足够的压力来说服矿工在BIP 148截止日期之前采用BIP 91来激活分叉。在我看来，最好的比特币核心贡献者是那些实行极端所有权的人。举个例子 - 虽然John Newbery没有编写包含这个特定共识bug的代码，但他认为有责任不通过仔细审查来防止它被合并，以及在编写测试用例时没有找到它。

我们都是中本聪。

贡献Bitcoin Core

虽然有足够的资源可以帮助有抱负的开发人员，但开始为Core做贡献会让人感到畏惧。虽然你可能希望从Jimmy Song的温和介绍开始，可以在这里找到贡献指南：

Alex B.撰写了一篇关于比特币发展理念的优秀文章 - 任何想要成为认真贡献者的人都可以通过阅读本文来节省大量时间。

一个具体的例子可能会有所帮助，在撰写本文时，为了审计GitHub提交历史的完整性，我在我的机器上运行verify-commit.py脚本时遇到了困难。为了节省未来的开发人员的时间，使他们不必处理这些问题，我打开了拉取请求以改进文档。

从PR历史中可以看出，有4位不同的开发人员提出了如何改进拉取请求的建议。这包括使用不同的wiki标记到简化的bash命令，以及可以在verify-commits.py脚本中使用的新参数。我同意所有的建议都是有意义的，所以我将它们合并到我的代码中，并推送了一个更新版本来满足我的拉动请求。此时，参与审查的开发者承认他们发现PR是可以接受的，维护者Marco Falke将其标记为包含在0.18版本中。经过几天的努力，开发者没有异议，代码被维护者Samuel Dobson合并到了Core中。

谁控制着比特币？

正如我多年来广泛讨论的那样，完全理解比特币作为一个系统几乎是不可能的。比特币的定义（控制）协议就像语言的定义。语言自发出现;关于词语意义的共识是有机的而不是字典所决定的。

就像字典描述语言现象而不是定义它一样，比特币实现也用代码描述比特币的语言。没有人被迫同意字典中给定单词的定义，也没有人通过运行它来强制同意给定比特币实现中的代码。语言不受民主制约，比特币也不受民主的制约;虽然你可能听到人们引用矿工，节点，开发者或用户“投票”，但是没有这样的机制可以使任何形式的多数投票能够强迫少数反对者接受他们不同意的变更。

比特币是无政府状态 - 没有统治者，但并非没有规则。规则由网络上的各个参与者定义和实施。虽然比特币协议本身的更改，通常是通过比特币改进提案流程进行的，但即使这是推荐的最佳做法，也不会强迫任何人遵循它。它只是一种更为正式的方式，试图通过同行评审和建立共识的过程来指导变革。

这很难解释和理解，这是比特币的反脆弱性的一个关键方面 - 如果有一个单一的控制点，它也将是一个单一的失败点，将受到比特币成功威胁的强大实体的利用。

最终，每个节点运营商通过确保网络上没有其他人违反他们同意的规则来管理自己。然而，若是有任何人持以反对，哪怕是极少数，控制单一失败点的运营商将会被其他的维护者共同驱逐。这种安全模型是比特币自下而上治理的基础。

没有人控制比特币。没有人控制比特币开发的重点。感谢John Newbery。