Gavin Andresen

项目创始人退居幕后，软件并不会自动得到维护。总要有人协调修复、测试和新版本发布。在 Bitcoin 早期，Gavin Andresen 接续 Satoshi 承担了这项责任。MIT 为 2015 年 11 月 17 日活动准备的人物介绍记载了这段经历，并已将 Wladimir van der Laan 列为主要维护者。这是软件开发中的职责，并非对网络的所有权。历史简介也不能证明今天仍有代码仓库访问权限；代码仓库就是大家共同存放源代码的地方。 [1]

新手可能理解数字货币的想法，却因为手里没有币，难以体验接收和发送。Andresen 用 Bitcoin Faucet 解决这一障碍。他在 2010 年 6 月 11 日宣布上线，投入最初的 1,100 BTC，并向用户提供五枚币用于尝试。访客不必等待自己挖到币，也不必先找到卖家。Faucet 分发的是已有资金，不会创造新比特币或区块奖励。它要降低的是第一次使用的门槛，而不是修改货币发行规则。 [2]

在 2010 年 6 月 11 日的回复中，Andresen 说明限制是每个 IP 地址五枚币，并不是每天都能领。IP 地址标识计算机网络中的连接，既不是比特币钱包地址，也不能可靠地对应每一个人。因此，保护服务与核实身份不是一回事。当时讨论的后续措施包括 CAPTCHA，也就是帮助区分真人和自动程序的验证任务。理解历史时，应把这一初始安排与后来的变化分开，不能按照今天同类服务的样子倒推过去。 [2]

另一项贡献解决的是不同的实际问题。收款人可能希望必须有多个签名，才能花掉收到的钱。付款人是否每次都要处理整套规则？2012 年的 BIP 16 描述了 Pay to Script Hash：付款指向一个 hash，即含有条件的脚本的简短数字指纹。BIP 是带编号的 Bitcoin 改进提案。脚本本身在这里叫 redeemScript，由之后花费资金的人提供。条件没有被取消，改变的是提交条件的时间和负责提交的人。 [3]

想象一个需要多人同意才能打开的钱箱。拿出钱箱的规定，并不会让钱自动交到你手上。同样，2012 年的 BIP 16 要求先检查所提交 redeemScript 的 hash，再执行脚本中的条件。知道脚本不等于拥有所需签名。这个提交的脚本还有 520 字节的技术上限；字节是数据大小的单位。对新手来说，关键是分清两项检查：拿出的规则是否正确，以及是否具备规则所要求的东西。 [3]

2015 年，Andresen 提交 BIP 101，建议逐步提高区块大小上限。文件把它称为 Hard Fork：某些被新规则允许的区块，会被旧规则拒绝。提案目录将它列为 Closed，也就是已关闭；相比之下，BIP 16 的状态是 Deployed，即已部署。这个对比说明，拥有 BIP 编号或知名作者并不能证明已经激活。阅读提案时，还要确认其中的规则是否真的开始使用。 [4] [3]

为什么扩大区块会引发争论？更大的区块能容纳更多交易，但其中的数据还需要发送、接收和验证。因此，2015 年的 BIP 101 也讨论了传输成本，以及更高要求可能有利于大型运营者的风险。网络连接缓慢的人，与大型挖矿企业面临的条件可能不同。作者对技术进步的期待，是支持提案的论据，而不是对所有未来情况都已测得的结论。问题在于如何兼顾容量和独立验证网络的能力。 [4]

Bitcoin.org 解释，开发者无法强迫用户接受规则修改，因为人们可以选择运行什么软件。要相互协作，参与者的规则必须保持兼容。Andresen 可以写提案、准备代码、说服别人，却不能单方面替所有人改写 Bitcoin。因此，应逐项评价他的贡献：服务让人们做到了什么，代码执行了什么，网络又采纳了什么。过去的贡献并不能自动证明后来每个说法都正确。 [5]