PP merchant data

匹配付款与订单，是每个结账环节都必须解决的枯燥问题，而比特币让它更难，因为一笔交易不携带发票编号。BIP70 的解决办法是把一个 cookie 交给客户的钱包，并要求它再传回来。如今的商家用每笔订单一个一次性地址来解决同一问题，这既更简单，也更私密。

运作方式

状态：已成历史。商家数据是 PaymentDetails 的字段7，也是随后返回的 Payment 消息的字段1，在 Bitcoin Core 0.20.0于2020年6月3日发布时，它连同 BIP70 的其余部分一并消失。

不透明正是其用意。钱包被告知将这些字节视为没有含义，并原样返回，这让每个商家都能自行设计方案，而无需其他任何人理解。

当时常见的方案有两种。一种是简短的查找键，例如16字节的订单标识符，它使请求保持精简，并把工作交给商家的数据库。另一种是自包含的数据块，装下整个购物车，使服务器无需保存状态，代价是体积更大。

第二种方案有一个漏洞，规范中已有警告。这些字节是从商家无法控制的软件那里返回的，因此从中读取的任何内容都是攻击者提供的输入。如果某家商店把价格或折扣码存放在其中，并信任返回的副本，就等于为自己做了一个优惠券生成器。补救办法是往返状态的常规做法：附上消息认证码，并在读取任何字段之前先加以校验。

体积比看上去更重要。整个已签名的请求必须送达客户，而将其渲染为二维码会带来严格的上限：最大的符号，即版本40、最低纠错等级，可容纳2,953字节的二进制数据。正是这一上限，使 BIP72 定义了 r= 参数，让一个短链接可以指向通过 HTTPS 提供的请求，而不必把请求本身带在链接里。

在哪里会遇到它

商家数据过去承担的工作，如今由地址本身完成。

BTCPay Server 等结账软件会为每张发票派生一个全新的地址，因此到账的付款自己就能标明所属订单，无需往返，也无需回传状态。这在两方面胜过 BIP70：付款方没有任何可篡改的内容，也避免了地址重复使用，否则任何查看区块链的人都能看到商家的全部收入。托管型平台的做法相同，这也是充币能进入您的账户而不是别人账户的原因。

从这一切中值得记住一条警告。其他一些网络要求在充币时附带备注或目的地标签，漏填会使您的资金进入一个汇集账户，且没有任何信息将其与您关联。比特币没有这样的字段。如果充币页面要求您为比特币交易附上标签、备注或参考码，那么该表单要么配置有误，要么是假的，而追回真正误转的充币既缓慢，又往往无法做到。

PP merchant data vs PP memo

商家数据是写给机器的，备注是写给人的。前者从不展示给客户，后者的存在就是为了展示。两者的失效方式也相应不同：未经检查的备注会误导正在查看确认界面的人，而未经检查的商家数据会误导商家自己的会计软件。在返回环节，两者都没有签名，这正是两者都必须被视为不可信的原因。