Wei Dai

程序员要加密消息或验证数字签名，不必从头编写所有步骤。他们可以使用密码库，也就是处理受保护数据的一组现成功能。Wei Dai 最初用 C++ 编写的 Crypto++ 就是这样的库。这是可以集成到应用程序中的实际软件。b-money 则是另一类贡献：一份货币系统的书面提案。某个密码库能够运行，并不能证明按照该提案构建的网络也曾运行。理解他的贡献，需要把这两条工作线索分开来看。 [3]

1998 年 11 月，Wei Dai 提出了一个在网上购物时也会遇到的问题：人们怎样在不透露身份的情况下合作？他在 b-money 中提出了两种协议，即共同记账和订立合约的两套规则。公钥充当化名，消息带有数字签名。不过，无法追踪参与者的网络是提案预先假定存在的条件，并不是提案本身实现的结果。由于对消息广播的要求很高，作者把第一种方案称为不切实际。因此，我们读到的是经过思考的设计，而非一个已经运行的匿名服务的使用说明。 [1]

假设安娜有 5 单位 b-money，要给汤姆转 2 单位。在第一种方案中，每位参与者都保留账户记录的副本。安娜签名的消息通知大家从她的账户扣款、向汤姆的账户入账，她还剩 3 单位。会导致余额为负的消息被忽略。数字签名可以验证发出指令的权限，但共同记账还需要消息传递规则。Bitcoin 后来采用 UTXO 模型，跟踪尚可花费的具体交易输出。因此，目标相近，不等于记账方式相同。 [1]

第二种 b-money 方案把记账交给部分参与者，也就是服务器。其他人的工作减少了，但如何监督记账者成为新的问题。服务器须缴纳可用于处罚的保证金，定期公开数据库，并对公开记录的内容作出承诺。用户检查自己的余额，以及所有账户余额之和是否超过已发行的钱。收款人还要向随机选出的服务器核实付款是否已被处理。因此，保证金并不会神奇地消除信任。它只是提案中监督那些管理账户的人和机器的一部分。 [1]

最初的 b-money 通过解决计算问题来创造单位，数量依据计算成本确定，并用标准商品篮子衡量。这一篮子提供统一的成本尺度，并不决定别人愿意在市场上花多少钱购买一个单位。然而，计算机不断进步，真实成本也不是人人都知道。Dai 承认这一困难，并在附录中提出拍卖方案：记账者协商新增货币数量，有意发行者用计算报价竞争。这不是 BTC 的发行时间表。坦承难题并尝试另一条道路，也是这篇文字的价值所在。 [1]

提案还讨论了付款以外的事情。以翻译委托为例，签名可以证明当事人同意合约，却不能证明交付文本的质量。因此，b-money 合约包括保证金、违约时约定的赔偿，以及仲裁者的帮助。如果各方仍无法达成一致，他们提交论据，每个记账参与者再各自作出判断。这说明，把人的争议搬进数字系统有多困难。相比之下，Bitcoin Script 是描述交易输出花费条件的语言，检查的是明确规定的技术条件。它本身无法判断一份承诺交付的翻译是否出色。 [1]

Satoshi Nakamoto 在解释 Bitcoin 设计的白皮书中，把 1998 年的 b-money 列为参考文献 1。这让读者能够追踪一条具体的思想联系：没有共同管理者的数字货币，在 Bitcoin 之前就已有人研究。不过，引用并不意味着 Bitcoin 采用了提案中的所有机制。b-money 的账户、发行和争议处理方式都与 Bitcoin 不同。引用也不能揭示 Satoshi Nakamoto 这个名字背后是谁。研究历史时，比较有据可查的文本，比根据一条引用推断作者身份更有帮助。 [2]

Crypto++ 的故事通过修复、测试和其他开发者的工作继续。项目历史记载，Wei Dai 在 2015 年 6 月把日常管理交给了社区。对使用者而言，重要的不只是最初作者，还包括具体版本和功能的正确用法。一个库可以提供签名或加密工具，却不会独自解决密钥的安全存储或整个钱包的设计。基于它开发应用的人需要阅读文档、跟进修复并验证自己的使用方式。认可作者的贡献，与检查今天的软件并不矛盾。 [3]