Payjoin 的核心操作只有一步：把收款方给你的完整支付请求（BIP21 URI）粘进钱包的发送框，而不是只复制里面的地址。那串 URI 里包含了 pj= 参数，钱包靠它找到收款方的协作端点，双方一起把交易拼出来。
如果你已经熟悉普通比特币转账，Payjoin 用起来几乎一样，区别在于收款方会额外贡献一个输入，最终广播的交易里，输入不再全部来自付款方。
发送 Payjoin：你实际要做什么
目前直接支持 Payjoin 发送的主流移动端钱包包括 Cake Wallet（v4.28 及以上）和 Bull Bitcoin Mobile，桌面端 Wasabi Wallet 也支持，但 Wasabi 要求启用 Tor。
以 Cake Wallet 为例，发送流程没有额外的"Payjoin 模式"开关，正常发就行：
在发送页面粘贴或扫描收款方的完整 Payjoin 链接。如果你只复制了 bitcoin: 开头的地址部分，Payjoin 不会触发，会变成普通转账。
核对金额和收款方标签，确认手续费。Payjoin 不会额外加价，双方付的都是正常网络费。
确认发送后，钱包在后台跟收款方的 Payjoin 端点协商。你不需要在发送后做什么额外操作，等待广播即可。
Wasabi Wallet 的操作路径略有不同：把收款方提供的含 pj= 的 BIP21 URI 粘贴到发送对话框的 "To" 字段，后续确认流程跟普通支付一致。
这里有一个容易误解的地方：点击"发送"不等于 Payjoin 一定成功。如果收款方暂时没有可用的 UTXO 来贡献输入、双方地址格式不兼容，或者 Payjoin 服务器连不上，钱包会回退成普通交易，钱照样到账，但隐私效果没有了。
回退是设计好的行为，不是故障。但如果你明确需要 Payjoin 的隐私效果，就不能依赖这个回退——它意味着"尝试了但没成功"，而不是"失败了钱没发出去"。付款前最好跟收款方确认对方也在用支持 Payjoin 的钱包。
接收 Payjoin：先有币才能参与
收款方的操作取决于钱包。以 Cake Wallet 为例：
进入 Settings → Wallet settings → Privacy，打开 Use Payjoin。
回到接收页面，二维码下方会显示 Payjoin enabled 标记。把这个二维码或链接正常分享出去。
付款方用支持 Payjoin 的钱包扫描后，协作自动进行。你在应用里能看到状态变化（等待付款方交易、进行中），不需要手动确认什么。
一个硬性条件：你的钱包里得有币。Payjoin 要求收款方贡献一个输入，空钱包没有 UTXO 可以贡献，所以新钱包刚创建、余额为零时，收款页面即使显示 Payjoin 标记，实际也会按普通交易收钱。
如果你用的是不运营接收服务器的钱包（比如 Ginger Wallet 的当前版本），你无法作为 Payjoin 收款方，只能在发送时跟支持 Payjoin 的收款方协作。
隐私到底好了多少：核验标准
Payjoin 要打破的是区块链分析里最基础的假设：一笔交易的所有输入属于同一个人。这个假设叫 Common Input Ownership Heuristic（CIOH），链上分析公司靠它把地址聚类。
普通转账里，Alice 付 Bob 0.1 BTC，Alice 拿一个 0.19 BTC 的 UTXO 当输入，输出是两个：0.1 给 Bob，0.08999 找零给自己。分析师一眼能看出哪个是付款、哪个是找零。
Payjoin 里，Bob 也塞了一个自己的 UTXO 进去，比如 0.07341 BTC。输出就变成了 Bob 拿 0.17341（0.1 付款 + 自己那 0.07341 回来），Alice 拿 0.08999 找零。两个输出都不是整数，金额也对不上实际付款额。分析师看到两个输入、两个输出，既不能确定哪个输出是付款，也不能把两个输入归到同一个人头上。
但"Payjoin 一定成功隐藏了信息"这个判断需要加条件。Payjoin 官方博客分析了真实案例，发现钱包指纹可能把隐私重新拆掉。
指纹来自不同钱包在构造交易时的习惯差异。一个例子是签名格式：有的钱包总是产生低 r 值签名，有的随机产生。如果一笔 Payjoin 交易里，一个输入是低 r、另一个是高 r，分析师就有理由怀疑是两个不同钱包贡献的输入，进而尝试把输入和输出做归属划分。另一个例子是 nSequence 字段的默认值不一致，或者 sighash 字节有的显式写出、有的省略。
这意味着：如果双方用不同钱包，Payjoin 的隐私效果可能打折。交易看起来仍然不像普通转账，但分析师有可能把"付款方"和"收款方"重新分开。双方用同一款钱包、同样版本，指纹信号会弱很多，但这不是用户能完全控制的事。
你作为用户能做的核验有限。广播后去区块链浏览器查这笔交易，你能看到的是：输入数量、输出数量、金额。你无法从链上直接判断它是否成功隐藏了归属关系——那需要分析工具和对手方信息。能做的是确认交易已广播、金额正确，以及如果隐私是硬需求，跟收款方对齐双方使用的钱包类型。
什么时候不适合用 Payjoin
Payjoin 对普通转账的隐私有帮助，但有几个场景它解决不了：
收款方已经知道你的身份。 如果你是在一个实名订单里付款，收款方本来就清楚你是谁、买了什么。Payjoin 改变的是链上观察者看到的结构，不改变收款方已经知道的交易信息。
你用的硬件钱包。 Ginger Wallet 的文档明确说，当前版本拒绝硬件钱包发起的 Payjoin 请求。Cake Wallet 的支持列表里也没有提到硬件钱包的 Payjoin 支持。
你在用 Tor 且收款方只提供 onion 端点。 Ginger 的实现会拒绝在 Tor 开启时使用 onion-only 端点，需要收款方提供兼容的 HTTPS 替代地址。这个限制是否适用于其他钱包，取决于具体实现版本。
你需要"一定成功"的隐私保证。 Payjoin 的回退机制意味着协商失败时你会发出一笔普通交易。如果普通交易会暴露你不想暴露的信息，那就在发起前先跟收款方确认对方确实在用兼容钱包和当前版本。
版本和实现现状
Payjoin 的当前推荐协议是 BIP 77（v2），核心改进是异步：发送方和接收方不需要同时在线，也不需要任何一方自己跑服务器。通信通过一个"Payjoin Directory"中转，消息端到端加密，目录服务器看不到交易内容，IP 元数据用 Oblivious HTTP（OHTTP）保护。
v1（BIP 78）仍然被 Wasabi 等钱包使用，要求收款方运行服务器且双方在线。如果你在文档里看到两种版本的操作差异，先确认你的钱包用的是哪一版。
Payjoin Dev Kit 1.0 在 2026 年 8 月发布，核心状态机 API 已经稳定，但 BIP 77 规范本身仍处于 Draft 状态，尚未最终定稿。这意味着钱包实现之间可能存在兼容性差异，跨钱包的 Payjoin 协商不一定每次都能成功。
参考资料
- Payjoin·Payjoin Dev Kit 1.0，页面发布或更新日期：2026-08-11；核查日期：2026-10-12。
- Wasabi Wallet·WalletWasabi v2.8.3 Release，页面发布或更新日期：2026-09-13；核查日期：2026-10-12。
- Cake Wallet Blog·Bitcoin Privacy Takes a Leap Forward: Cake Wallet Introduces Payjoin v2，页面发布或更新日期：2025-05-18；核查日期：2026-10-12。
- Cake Wallet Docs·Payjoin，页面未标明更新日期；核查日期：2026-10-12。
- Wasabi Wallet·PayJoin，页面发布或更新日期：2026-01-09；核查日期：2026-10-12。
- Ginger Wallet·PayJoin and Message Signing，页面未标明更新日期；核查日期：2026-10-12。
- Coldcard·What is PayJoin?，页面发布或更新日期：2026-06-04；核查日期：2026-10-12。
- Payjoin·Wallet Fingerprints Damage Payjoin Privacy，页面发布或更新日期：2026-03-24；核查日期：2026-10-12。
- Payjoin·Async Payjoin (BIP 77, V2)，页面未标明更新日期；核查日期：2026-10-12。
- Payjoin·The Evolution of Payjoin: From Two-Party Protocol to Multiparty Framework，页面发布或更新日期：2025-03-17；核查日期：2026-10-12。
