Schnorr Signature

爱丽丝想向鲍勃发送比特币。钱包是接收和发送比特币的应用程序或设备。钱包构造交易，再用私钥对所选签名模式要求的数据签名。节点随后检查签名及其他全部花费条件。节点是验证交易和区块、并与其他网络参与者通信的软件。签名有效本身并不能证明爱丽丝的法定身份、收款人是否符合她的本意，或是否存在足够的未花费资金；这些是不同的问题。已经签名的付款仍可能是她无意犯下的错误。 [5] [3] [10] [11]

Pieter Wuille、Jonas Nick 和 Tim Ruffing 编写的 BIP340 精确定义了比特币的 Schnorr 签名。BIP341 将其用于 Taproot 的花费规则，这些规则于 2021 年在比特币主网（Mainnet）的区块 709632 激活。区块把交易组成一批，加入共同历史记录。这里有两个层次：签名算法与花费条件。较早的输出类型和 SegWit v0 仍使用 ECDSA，也就是此前采用的签名算法，升级并没有追溯替换它们的签名。 [1] [2] [11]

字节是衡量数据大小的常用单位。比特币版本采用 secp256k1 椭圆曲线，这是一种用于密钥和签名计算的数学结构。BIP340 规定签名采用固定的 64 字节格式。公钥用 x 坐标的 32 字节表示；x-only 并不意味着省略安全检查。规则也明确规定验证者应使用曲线上哪一种点表示。更小且定义精确的格式便于软件处理，但仅凭这两个数字无法得出整笔交易的大小。 [1] [12]

钱包签下的不是一句含糊的“我同意”。sighash 模式决定哪些交易数据组成被签名的消息。SIGHASH_DEFAULT 与 SIGHASH_ALL 类似，保护所有输入和输出的相关信息：花费的是哪些此前收到的币，以及创建哪些带有花费条件的新金额。修改被覆盖的数据会使签名失效。但这不等于对每个字节签名，例如其他签名本身。其他允许的模式保护范围不同。签名本身为 64 字节；使用非默认模式时增加一个类型字节，使该项变成 65 字节。这仍不是整个输入或整笔交易的大小。 [2]

签名过程中会生成秘密 nonce 值。同一密钥对不同消息重复使用该值，可能泄露私钥。因此，BIP340 精确定义了 nonce 的派生方法，并建议加入辅助随机数据，为实现提供额外保护。用户不需要自己编造 nonce，也不应将它抄入备份。它由经过检验的签名库管理；在这里自行发挥，可能破坏原本正确的密码学方案。 [1] [9]

Schnorr 签名的数学结构允许构建这样的协议：多人就同一消息达成一致，然后生成共同签名。BIP327 定义的 MuSig2 就是一个例子。在该协议的基本形式中，选定群体的每名成员都必须参与。它需要协调、正确处理密钥，以及专门的安全 nonce 流程。不能随意把已经完成的签名相加。钱包支持 Schnorr Signature，也不代表它自然就支持这种协作。 [8]

Taproot 提供不同的花费路径。采用 key path 时，网络针对输出中记录的公钥验证签名；这把公钥背后可以是一个人，也可以是相互合作的群体。采用 script path 时，会公开所选脚本，也就是包含付款必须满足的条件的程序。Tapscript 是 Taproot 使用的脚本语言版本。它的 OP_CHECKSIGADD 指令验证一个签名，成功时将累计值加一。重复使用该指令，可以检查多个独立签名是否达到所需数量。这种基于脚本的 Multisig 与一个聚合签名不同。对于具体钱包，应了解哪些人必须合作、什么信息会公开，以及丢失密钥后还能如何恢复。 [7] [2]

在没有中央裁判的网络中，不能因为对字节的解释不同，一个节点接受签名，另一个却拒绝。因此，BIP340 详细规定了有效密钥、签名和验证流程。它还允许 batch verification，即同时验证多个签名来节省计算。这不会改写它们在区块链上的记录，也不等于将不同交易输入的签名合并。 [1]

共同的 key-path 签名在外观上可以与单个密钥的签名相同。因此，仅看签名不一定能知道有多少人同意了付款。不过，金额、输入输出之间的联系以及交易时间通常仍可观察。Schnorr Signature 不会加密付款。隐私效果还取决于 Taproot 的使用方式、钱包行为和付款场景。 [2] [3]

对普通用户而言，重要的是钱包能正确显示收款人、金额和手续费，并支持可靠恢复。开发者还要检查准确的 BIP340 支持情况、测试向量、nonce 管理及出错时的行为。算法名称并不是整个产品的保证。像 libsecp256k1 这样可靠的库负责密码学计算，却不能替用户决定是否真的应该批准屏幕上的付款。 [4] [9] [6]