硬件钱包屏幕上显示商家名字而不是地址：SLIP-0024 签名支付请求防替换

硬件钱包防得住电脑中毒，防不住假地址

剪贴板劫持、恶意浏览器扩展、中间人改单——扫码转账安全吗？收款二维码里的地址、金额和跳转怎么读 里那类收款二维码攻击的共同点是：改在你把地址交给钱包之前。设备再安全，也只是忠实显示拿到的那串字符，逐位核对四十几个字符对人是不可靠的防线。SLIP-0024（状态 Draft，2021 年由 Trezor 工程师 Andrew Kozlik 起草）换了一条路：与其让人看地址，不如让一个受信任的签名方替地址背书，硬件钱包验签通过后，屏幕上给你看的是商家名字和金额，不是十六进制串。

从 BIP-70 借来的骨架，砍掉的部分更关键

这套格式明显师承 比特币放弃的支付协议：BIP70 与 Core 0.20 的删除记录 里讲过的 BIP-70 支付协议，但针对硬件钱包做了三处手术。硬件钱包没有可靠时钟，所以不设创建与过期时间，改用一个由付款方钱包生成的 nonce 挑战来保证新鲜度，防止同一份请求被重放给这台或那台设备；内存受限，所以请求数据的哈希方式按省内存设计；证书体系 X.509 复杂度对嵌入式设备过重，直接划出规范范围，但签名本身从可选变成必填——没有签名的请求在这套格式里不成立。

收件人名与四种备忘字段

请求包的核心字段是收件人名 recipientName：付款人屏幕上显示它，地址可以折叠进二级查看，但必须保留检查原始地址的出口。备忘 memo 字段则把更多信息打包给付款方或其钱包校验，规范定了四种：纯文本说明必须完整显示；退款地址备忘要求钱包验证这个地址确实归自己控制，付款才成立；带标题的文本详情备忘视设备能力可展开可不显示；购币备忘供交易所告知用户付款后将收到什么币和送到哪个地址，钱包同样必须校验那个地址归自己、且必须显示在屏幕上。同一类型的多条备忘，显示顺序必须与请求中列出的顺序一致。

nonce 从哪来，重放在哪被挡住

nonce 不是随机装饰：在有备忘字段的请求里它应当出现，由付款方钱包先生成并记进设备易失内存的 nonce 缓存，商家把请求原样带回来时，设备核对 nonce 与自己刚发过的一致且未被用过，才继续验签。这条小设计同时挡住两类攻击：同一份请求被反复投喂给这台设备（重放），以及把请求转手给另一台不认识这个 nonce 的设备（挪用）。带退款备忘的流程里顺序更有意思——钱包先出示退款地址归属凭证和 nonce，商家拿着这两样去签名服务器换请求，相当于把退货地址也焊进了签名里，事后改单在密码学层面就不成立。

塞进 BIP-0021 链接的 slip24sig

传输层没有新发明：请求最终编码成 BIP-0021 支付链接，规范只加了一个查询键 slip24sig，值是支付请求签名的 base64 编码，其中的等号必须百分号编码成 %3D；一旦带上 slip24sig，amount 与 label 字段就必须同时存在，算请求哈希时收件人名直接取 URI 的 label。地址列表本身压进 outputsHash——每个输出按金额加脚本的二进制编码拼接取哈希，币种编号用 SLIP-0044 的 coinType 小端序，多链场景各归各账。对账时任何一位对不上，验签就失败。

信任从哪来，边界在哪

规范刻意不回答谁是受信任方：可能由固件里钉死的一批公钥定义，可能由用户自己导入商家公钥，也可能是厂商运营的签名服务；某受信任方还可以被限定只能为特定商家名签单。典型流程是商家向签名服务器证明身份、换回签好名的请求，再拼进 BIP-0021 链接发给顾客，顾客点开后硬件钱包验签、弹框显示商家名与金额。要记住的边界有两条：签名证明的是这个地址被签名方背书过，不证明商家本身值得信任；而验证地址归属那一步依赖设备当前种子，换钱包恢复、passphrase 认错都会让校验失败——先核路径再下结论。

风险提示

本文为支付安全机制科普，不构成投资建议或产品推荐。付款前无论屏幕显示什么，金额与收款对象仍需逐项确认；任何跳过设备验签、直接广播的支付请求都应视为高危操作。具体钱包对 SLIP-0024 的支持情况以厂商官方文档为准。