一个地址说两句话
静默支付（Silent Payments，BIP-352）的公开形式是一个 sp1q 开头的长地址。它其实捆着两把公钥：一把扫描钥，只用来发现”有没有钱付给我”；一把花费钥，只用来产生化约后的花费密钥。这个拆分是协议的心脏：此后任何付款人都可以不联系你，直接用自己的交易造出一个一次性 Taproot 输出，链上看不到你的静默支付地址的任何字节，也看不到”同一收款人”的聚类线索。
付款侧发生的事
与 BIP-47 需要先做一笔”通知交易”在链上公开配对关系不同，BIP-352 让付款人直接利用即将广播的交易：取该交易全部符合条件输入的私钥，对每把私钥与你的扫描钥做椭圆曲线 Diffie-Hellman 共享秘密求和，把求和结果当作扰动量，叠加到由花费钥推出的点上，得到一次性公钥，再按 BIP-341 规则编成 P2TR 输出。付款人不新增输出结构、不加体积，输出的形状与网络里其他普通 Taproot 输出无法区分。整个推导只用已上链或即将上链的公开信息，既不需要交互，也不留下”这个地址收过款”的锚点。
收款侧的代价
隐私不是免费的：付款人推导是”一次算一个”，收款人发现却要反过来扫。钱包必须从交易输入提取私钥的公钥，用扫描钥对每一笔可能相关的交易求共享秘密，再拿化约后的花费钥去比对输出。这带来两个实际约束：其一，静默支付钱包必须持续扫描它见过的全部交易，新导入或新换地址后要回放一段历史，扫描成本随链增长；其二，任何一笔交易若被静默支付钱包漏扫——例如只依赖不含输入的过滤器——对应到账就会被永久错过，所以主流做法是配合完整区块扫描或含输入的过滤器（钱包侧配套还有 BIP-375 与 BIP-376，分别处理用 PSBT 发送静默支付和花费静默支付输出）。部署侧，BIP-352 的规范状态已是 Complete，但支持它收发与恢复的钱包仍是生态里的一小部分，能不能用要看你钱包版本说明是否明确写了 silent payments，而不是”支持 Taproot”。
与 BIP-47 的分道扬镳
BIP-47（可复用支付码）解决同一个需求：一份长期凭据收多次款。它的路径是链上握手——双方先做一笔所有人可见的通知交易，之后的付款带一个公开的种子公开钥。代价是三样：多花一笔手续费、通知交易本身成了长期聚类标记、握手前无法收款。静默支付把这三样全部消掉，代价换成了收款侧的扫描负担与更长的地址（规范示例约 117 字符）。选型上不必争优劣：需要一次性握手、且双方软件都只支持老协议的场合，支付码仍有位置；新集成项目里，不接触链、不冒头的静默支付更符合隐私默认值。
能防什么、防不住什么
协议能挡住的是”链上观察者把同一静默支付地址下的多笔收款归并”以及”把你的地址与链上任何输出直接对应”。挡不住的是链下信息的泄露：如果你把静默支付地址挂在一个能反推身份的域名上公开收款，聚类压力就从链上移到链下；对方若同时掌握你的消费习惯、时间戳与 IP，统计层面的关联仍可能存在。另一个反直觉之处：给”本来就会广播的交易”加派生输出会让付款人稍微复杂，但不会抬高任何费用，因此它没有理由成为拒收借口——需要扫描的是收款侧，而扫描是可以用时间换的。
使用清单
给收款人的三条底线：把静默支付地址当成”可以公开长期用”的凭据，同时把它挂出去的位置也当成隐私声明；钱包同步或换机后，确认它从正确区块高度开始补扫；涉及硬件签名时确认设备固件与配套 BIP 支持到位，避免半程兼容。本文只做机制说明，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。