Pieter Wuille

钱包提供一个新地址，或为付款生成签名，看起来只是按一下按钮，背后却凝聚着许多开发者的工作。Pieter Wuille 就是其中之一。他在 GitHub 使用 sipa 这个名字，个人资料将这个网名与他的开发工作联系起来。不过，要判断某项设计是谁提出的，还得查项目历史和文档，不能只凭一个网名。下面这些提案可以说明他解决了什么问题，以及与谁合作。 [1]

设想一家商店希望每笔订单都使用不同的收款地址。Wuille 的 BIP 32 描述了如何从一份 seed，也就是最初的秘密数据，派生出整棵密钥树。扩展公钥 xpub 可以生成相应分支的更多公钥，却不赋予花钱的权限；私钥则可以用于签名。但有一个重要例外：若 xpub 与泄露的、经非硬化路径派生的后代私钥同时落入他人手中，父级私钥就可能被推算出来。硬化派生 hardened 会切断这条路径。因此不能随意公开 xpub；它还会暴露付款之间的联系。 [2]

后续交易可能依赖前一笔交易，因此交易标识十分重要。BIP 141 的作者是 Eric Lombrozo、Johnson Lau 和 Pieter Wuille。它将签名等验证数据放入称为 witness 的结构，与决定原有标识 txid 的部分分开。新标识 wtxid 则也包含 witness。这样，签名数据发生变化时，不一定会改变后续交易所引用的 txid。签名仍然需要验证：区块第一笔交易，即 coinbase 交易中的密码学承诺，保护着 witness 数据。 [3]

抄写地址时，很容易写错一个字符。Wuille 与 Greg Maxwell 在 BIP 173 中为原生 SegWit 地址描述了 Bech32 格式。其中的校验和是一组帮助发现编码损坏的字符。但它检查的是编码，而不是预期收款人的身份。如果有人把地址替换成另一个格式正确的地址，校验和并不会替你识别这场骗局。 [4]

地址格式也需要改进。Wuille 的 BIP 350 修改了校验和，用来修正插入或删除字符时的一项特定弱点，由此得到 Bech32m。钱包必须核对 witness 版本与编码是否匹配：版本 0 继续使用 Bech32，版本 1 至 16 使用 Bech32m。用户不应需要手动挑选算法。生成和验证地址是软件的责任，不能只要某种校验和通过就接受。 [5]

数字签名让别人能够核验付款权限，而持有人不必公开私钥。BIP 340 的作者是 Pieter Wuille、Jonas Nick 和 Tim Ruffing。它规定的 Schnorr signatures 使用 64 字节的签名和 32 字节的公钥；字节是数据大小的单位。这种签名的数学性质可用于构建多人共同签名的系统。但简单地把密钥相加还不够，参与者之间还需要单独的协议来安全协调。 [6]

钱包可以设置通常的花费方式，也可以准备备用条件。Pieter Wuille、Jonas Nick 和 Anthony Towns 在 BIP 341 中描述了 Taproot。通过密钥路径 key path 花费时，可以仅用签名，甚至不暴露其他脚本的存在。脚本就是表达花费条件的程序。如果需要采用脚本路径 script path，就公开实际使用的脚本及其包含证明；没用到的其他方案不必完整公布。这能节省空间，也能少暴露一些钱包结构信息，但不会自动让所有付款匿名。 [7]

这些改进都围绕具体问题展开，其他人可以审查设计与代码。Bitcoin.org 解释，BIP 要接受公开讨论，是否采纳则取决于网络参与者。节点是按照自己运行的软件验证交易和区块的计算机。提案作者或代码仓库维护者，并没有单方面修改共识规则的权力。Wuille 的重要性来自贡献与合作，而不是担任比特币的老板。 [8]