PPマーチャントデータ

支払いを注文に照合することは、あらゆる決済画面が解決しなければならない地味な問題です。ビットコインでは、トランザクションに請求書番号が含まれないため、さらに難しくなります。BIP70は、顧客のウォレットにクッキーを渡し、それを返してくるよう求めることでこれを解決していました。現在の加盟店は、注文ごとに1回限りのアドレスを使うことで同じ問題を解決しており、こちらはより簡素で、プライバシー面でも優れています。

仕組み

状態：過去の仕様です。マーチャントデータはPaymentDetailsのフィールド7であり、返送されるPaymentメッセージのフィールド1でした。2020年6月3日にBitcoin Core 0.20.0が出荷された際に、BIP70のその他の部分とともに消えました。

不透明であることが要点でした。ウォレットはそのバイト列を意味のないものとして扱い、変更せずに返すよう指示されていました。これにより、各加盟店は他の誰かに理解してもらう必要なく、独自の方式を考案できました。

一般的だった方式は2つあります。短い照合キー、例えば16バイトの注文識別子を使う方式は、要求を小さく保ち、処理を加盟店のデータベースに任せました。自己完結型のバイト列はカート全体を保持し、サーバーをステートレスに保てましたが、その代わりにサイズが大きくなりました。

2つ目の方式には、仕様が警告していた欠陥があります。そのバイト列は加盟店が管理しないソフトウェアから返送されるため、そこから読み取るものはすべて攻撃者が提供した入力です。価格や割引コードをそこに保存し、返送されたコピーを信用していた店舗は、自らクーポン生成器を作ってしまっていたことになります。対処法は、往復する状態に対する通常の方法です。メッセージ認証コードを付加し、1つのフィールドを読む前にそれを検証します。

サイズは見た目以上に重要でした。署名済みの要求全体が顧客に届かなければならず、それをQRコードとして表現すると厳しい上限が生じます。最大のシンボルであるバージョン40を最も低い誤り訂正レベルで使うと、バイナリデータで2,953バイトを保持できます。この上限があるため、BIP72はr=パラメータを定義し、短いリンクが要求自体を運ぶのではなく、HTTPSで配信される要求を指せるようにしました。

使われていた場面

かつてマーチャントデータが担っていた役割は、現在はアドレス自体が担っています。

BTCPay Serverのような決済ソフトウェアは請求書ごとに新しいアドレスを導出するため、到着した支払いは往復も返送された状態もなしに、自ら注文を特定します。これはBIP70を二重に上回ります。支払者が改ざんできるものは何もなく、そうしなければ加盟店の収益全体をチェーンを読む誰にでも公開してしまうアドレスの再利用も避けられます。カストディ型のプラットフォームも同じ仕組みで、これにより入金が他の誰かの口座ではなくあなたの口座に届きます。

この話から持ち帰る価値のある警告が1つあります。他のいくつかのネットワークでは、入金の際にメモや宛先タグが必要であり、それを省略すると、あなたと結び付けるものが何もないまま、資金がプールされた口座に落ちてしまいます。ビットコインにはそのようなフィールドはありません。入金ページで、ビットコインのトランザクションにタグ、メモ、参照コードを付けるよう求められた場合、そのフォームは設定が誤っているか、偽物です。本当に宛先を誤った入金の回収は、時間がかかり、しばしば不可能です。

PPマーチャントデータvs PPメモ

マーチャントデータは機械のために書かれ、メモは人のために書かれました。一方は顧客に示されることはなく、他方は示されるためだけに存在しました。失敗の仕方もそれに応じて異なります。検証されていないメモは確認画面を読む人を誤らせ、検証されていないマーチャントデータは加盟店自身の会計ソフトウェアを誤らせます。どちらも返送の段階では署名されておらず、そのためどちらも信頼できないものとして扱う必要がありました。