比特币静默支付（Silent Payments，BIP-352）解决的是一个具体问题：你公开一个不变的地址收钱，但每笔付款在链上落在不同的地址上，外部观察者无法把这些付款关联到你。这个地址以sp1开头，可以放在网站、社交媒体或捐赠页上反复使用，不需要每次收钱都生成新地址。
但这个便利有代价：收款方必须主动扫描区块链才能发现付款。付款不落在你已知的地址上，钱包需要检查区块中的候选交易，用自己的私钥推导出可能的输出，判断哪一笔是给你的。发送方相对简单——粘贴sp1地址到发送界面即可，和普通地址没有区别。
收款：扫描是必须的，但可以控制成本
收款方需要开启扫描功能。以 Cake Wallet 为例，路径是 Settings → Privacy → Silent Payments，启用"Set Silent Payments always scanning"。钱包会逐块检查候选交易，扫描时主屏幕的链标签旁边会显示一个琥珀色小点表示正在进行。
扫描耗费电量和数据流量。如果你很少收到静默支付，可以不开启常驻扫描，只在预期有付款时手动开启。付款不会丢失，只是在你扫描之前不会显示在钱包里。
一个关键限制是：扫描需要支持 tweak 数据的 Electrum 服务器。Cake Wallet 在你连接的自定义节点无法提供扫描所需数据时，会回退到它自己的服务器 electrs.cakewallet.com:50001 进行扫描。如果你运行自己的节点是为了隐私，需要确认你的 electrs 构建支持静默支付的 tweak 索引，否则扫描流量会经过 Cake Wallet 的基础设施。
Sparrow Wallet 的收款路径更成熟。它通过连接一个支持 SP 的 Electrum 服务器（如公开的 frigate.2140.dev）来获取 tweak 数据，客户端检测本地完成，但服务器能看到你的 IP 和查询模式。最私密的配置是自己运行一个 Frigate 实例，这样扫描查询不经过任何第三方。
备份：助记词之外，还有专门的密钥
静默支付钱包的恢复比普通钱包多一层。你的助记词仍然可以恢复整个钱包，包括静默支付的扫描和花费密钥。但在 Cake Wallet 中，密钥是按币种分开显示的——比特币标签下有一个单独的"Silent Payments (Bitcoin)"标签页，里面包含静默支付专用的扫描私钥和花费公钥信息。
备份时你需要抄写所有标签页的内容，不只是主助记词。恢复时如果只导入助记词，某些钱包可能不会自动恢复静默支付的扫描能力，需要确认恢复后的钱包是否具备 sp() 描述符或等效的密钥导入方式。
BIP-392 定义了静默支付的输出脚本描述符格式 sp()，支持用 spscan（仅扫描密钥，可观察）或 spspend（扫描+花费密钥，完整钱包）来备份。如果你的钱包支持导出描述符，导出并保存这个字符串是比手抄密钥更可靠的备份方式。派生路径是 m/352'/0'/0'，不要修改。
发送：简单，但有协作交易的风险
发送静默支付不需要学习新操作。粘贴 sp1 地址，钱包自动处理。大多数主流钱包已经支持发送——Sparrow、Cake Wallet、BlueWallet、Wasabi、Nunchuk、BitBox02 都可以。
但协作交易（如 CoinJoin）中的静默支付有已知问题。2026 年 8 月，一个硬件钱包厂商披露了恶意主机可以在协作交易中把静默支付资金锁到非预期地址，只有在攻击者配合下才能恢复。这个故障类别是 BIP-375 要求强制使用 DLEQ 证明的原因——如果你通过协作交易发送静默支付，确认钱包实现了 BIP-375 的验证。
硬件钱包的现实
BitBox02 支持发送到 sp1 地址，但它无法独立接收静默支付——硬件设备不能持续扫描区块。要接收，你需要把 BitBox02 和一个软件钱包（如 Sparrow）配对，软件钱包负责扫描，硬件设备负责签名。
实际建议
如果你只是想接收捐赠或定期收款，Cake Wallet 移动端是最快的起步方式。开启常驻扫描，接受扫描流量经过 Cake Wallet 服务器的权衡，或者确认你连接的节点支持 tweak 索引。
如果你对隐私要求较高，Sparrow 桌面端加上自己运行的 Frigate 服务端是当前最完整的方案。牺牲的是需要维护一个索引服务器，换来的是扫描查询不经过任何第三方。
如果你只用硬件钱包，静默支付的收款路径还不完整。发送可以走 BitBox02，接收需要额外的软件层。现阶段用硬件钱包做静默支付的"冷存储"概念还不成立，因为收款检测依赖联网设备。
