Jeff Garzik

Jeff Garzik 在 GitHub 上使用 jgarzik 这个名字。通过各个代码仓库，可以查看他的工作及修改历史。比起笼统地把某个人说成“管理比特币的人”，这种了解方式更有帮助。对于程序，要看它能做什么、具体是哪一个版本；对于提案，要看它想改变什么。开发者的个人资料本身，并不能决定别人运行哪一版软件。 [1]

介绍 Garzik 的 cpuminer 的 README 文件说明，它是通过 CPU，也就是计算机处理器，进行比特币挖矿的程序。多线程意味着可以把计算分配给多个并发运行的执行线程。面向 Litecoin 和 Bitcoin 的 pooler/cpuminer 明确说明自己源自该程序。沿用已有代码并独立继续开发，称为项目的 fork。这本身不会使比特币网络分裂；衍生版本后来增加的功能，也不一定存在于 Garzik 的原版中。 [2] [3]

Picocoin 是另一个例子。它包含以 C 语言编写的 libccoin 库，开发者可以利用其中的功能构建比特币应用。但 README 将配套的 HD 钱包和 brd 节点标为 WIP，也就是尚在开发中。HD 钱包从共同的基础派生一组密钥；节点则用于与比特币网络通信。该仓库于 2024 年 2 月 15 日归档。它对研究历史很有价值，但代码可获取，并不证明它是已经完成、仍受维护、适合保管个人积蓄的安全产品。 [4]

设想一个节点想知道，对端知道哪些尚未确认的交易。Garzik 的 BIP 35 针对这一需求：mempool 消息请求列表，inv 响应返回交易标识符，也就是交易哈希，再通过 getdata 请求交易数据本身。Mempool 是交易确认前的本地“等候区”，并不是全世界共用的唯一名单。Bitcoin Core 文档中的 getrawmempool 命令同样返回某个节点的内容。在那里找到一笔交易，并不意味着它已经在区块中获得确认。 [5] [8]

区块大小既影响交易可用空间，也影响传输和验证所需的资源。Garzik、Tom Harding 和 Dagur Valberg Johannsson 在 BIP 100 中提出，根据矿工写入区块的投票调整上限。方案每 2016 个区块重新计算，要求区块中达到 75% 的支持，并限制每次调整的幅度。因此，它并不是按人数计票。登记表将该提案标为 Closed，即已关闭；文档描述本身不能证明整个比特币网络都采用了这一机制。 [6]

假设一个普通节点仍然检查最初的 1 MB 上限。收到更大的区块时，它会拒绝该区块，即便挖出它的矿工支持更高的上限。BIP 100 明确提醒了这种分裂的可能。区块里的投票是新软件可以解读的数据，不是改写旧程序的命令。允许旧规则拒绝的区块通过的改动，属于 Hard Fork。这里的 fork，与在 GitHub 上创建衍生项目，并不是同一个含义。 [6]

Garzik 的 BIP 102 提出了另一条路：一次性将上限提高到 2 MB。激活需要同时满足规定的时间条件，以及最近 1000 个区块中 95% 发出支持信号。即使条件都满足，也不会自动改好旧的验证程序；它们仍会拒绝更大的区块。该提案同样标为 Closed。它记录的是曾提出的改动，不能用来判断比特币今天适用的区块大小规则。 [7]

阅读每份 BIP 时，都要结合内容与状态。BIP 35 在 Peer Services 层被标为 Deployed，即已部署；这一层关注节点间的服务和通信。BIP 100 与 BIP 102 则在 Consensus (hard fork) 层标为 Closed，因为它们涉及节点将哪些区块判为有效。同一位作者可以参与两个领域，取得不同结果。某条网络消息成功部署，并不表示他提出的所有规则改动也一起获得采用。 [5] [6] [7]