Cashu

设想安娜通过私信把一个 Cashu 代币发给彼得。她并没有向区块链广播一笔 Bitcoin 交易，而是交给彼得一组可向相应铸币方兑换的数据。一个代币可以包含一条或多条凭证（Proof）。每条凭证是一个数据记录，其中包括金额、秘密值和铸币方签名等字段。Cashu 是共同协议，不是共用一份储备的单一服务。发行方、计价单位和签名密钥集都很重要。以 sats 表示的是比特币的小单位；同一个数字换了单位，含义就变了。一家铸币方的代币也不会自动被另一家接受。对格式感兴趣的读者可以进一步了解：V4 采用紧凑的 CBOR 二进制编码，只包含同一家铸币方的凭证。 [1] [2] [9]

对于没有额外花费条件的普通代币，安娜可以保留一份副本。彼得因此需要完成 swap：钱包把旧凭证交给铸币方，换取使用新秘密值的凭证，而安娜不知道这些新秘密值。铸币方同时使旧输入失效。只有交换成功，安娜才不能再次花费同一份副本。仅查询状态还不够。UNSPENT 表示铸币方没有处理或已花费的记录，并不是为彼得预留。PENDING 表示处理中，SPENT 表示凭证已经兑用。因此不要把代币当成付款收据公开展示：拿到可用副本的人可能抢先兑用。 [3] [5]

Blind Signature（盲签名）帮助切断代币发行与后续使用之间的对应关系。钱包先生成秘密值，隐藏其数学表示，请铸币方签名，再移除隐藏处理。铸币方不应仅凭后来兑用的代币，就识别出当初的发行请求。但这不是隐藏一切：不同面额使用不同密钥，发行方仍知道发行了哪些面额。这个方法的技术名称是 BDHKE，使用 secp256k1 曲线。理解支付不需要先学会计算曲线上的点，关键在于知道这套数学保护的是哪一种关联。 [1]

可选扩展 NUT-12 增加了 DLEQ，即证明签名所用私钥与铸币方公钥对应的数学证明。有了必要的附带数据，彼得无需联系铸币方，也能验证签名。但这不能告诉他其他副本是否已被花费、服务是否在线，或比特币储备是否足够。规范要求：代币附带 DLEQ 时，钱包必须验证。即使如此，签名验证仍不能代替完成 swap。Counterparty risk，也就是运营方不能履约的风险，并未消失。 [7]

彼得可能想支付一笔 Lightning Network 请求，而不是继续持有代币。这种兑换称为 melt。钱包先请求报价，确认需要多少代币、使用什么单位、报价何时到期，以及是否需要预留手续费。还可能另外收取输入费。之后钱包提交凭证，由铸币方执行外部支付。HTTP 200 说明网页请求得到成功处理，却不一定表示付款完成。PENDING 仍是“处理中”，PAID 才报告支付成功。钱包需要跟踪最终结果，以及该支付方式对应的确认信息。 [4]

铸币方可以轮换签名密钥集。active=false 表示旧密钥集不再发行新代币；这一状态本身并不禁止把旧凭证作为输入使用。可选字段 final_expiry 则不同：超过这个最终期限，规范便不再要求铸币方履行相应兑付承诺。不要混淆两者。此外，input_fee_ppk 是按每个输入收取的费率，并非简单按转账金额抽取百分比。先把所用凭证的费率相加，再将总和除以 1000，最后才把费用向上取整。例如，对于以 sat 为单位的密钥集，3 个输入的费率各为 100 ppk，总和为 300；除法和取整之后，费用为 1 sat。因此，两笔同额支付如果使用的凭证数量或密钥集不同，费用也可能不同。 [2]

盲签名不会抹去支付时间、金额或网络连接数据。钱包请求新面额的方式本身就可能提供线索。NUT-03 建议把请求的面额从小到大排序，避免排列顺序不必要地暴露“付款部分”和“找零部分”的分界。发送者反复查询已交出代币的状态，也可能帮助铸币方把发送者与接收者关联起来。Cashu 提供更私密的资金流转工具，但不意味着每个应用、每种情境都会自动隐藏所有关系。 [3] [5]

恢复流程必须匹配所使用的钱包和铸币方。NUT-13 描述了如何由 seed（起始秘密值）、密钥集和计数器重新推导代币秘密值与盲化因子。密钥集版本 01 使用 HMAC-SHA256，较早的 00 使用 BIP32。seed 无法自行生成的签名，需要通过 NUT-09 向铸币方取回，之后还要检查哪些凭证已被花费。因此，“我有 Seed Phrase，随便找个钱包就能全部恢复”并不可靠。依赖钱包之前，应核实备份和恢复流程，并尝试小额提现。备份不能让消失的铸币方重新回应，也不能补足其储备。 [8] [6]