PaymentRequest

PaymentRequestは、ウォレットが文字の羅列ではなく企業名を表示できるようにしたメッセージでした。フィールドは5つあり、重要なのは2つで、1つはnone、x509+sha256、x509+sha1のいずれかをとるpki_type、もう1つはシリアライズされた詳細に対するsignatureでした。今日支払いをする人にとって、この教訓はプロトコルを超えて残っています。支払い画面に表示される名前は、それを保証した相手と同じだけしか信頼できないということです。

仕組み

状態：廃止。Bitcoin Coreは0.9.0からPaymentRequestの処理を搭載していましたが、0.20.0が2020年6月3日に削除したため、現在このメッセージを解析する保守中のウォレットはありません。

5つのフィールドを順に示します。

• payment_details_version。32ビットの整数で、既定値は1です。一度もインクリメントされませんでした。
• pki_type。既定値は「none」の文字列です。代替は「x509+sha256」と「x509+sha1」でした。
• pki_data。加盟店のリーフ証明書を先頭に、中間証明書があればその後ろに並べたX509Certificates構造を保持していました。
• serialized_payment_details。必須で、この用語集の別の項目で説明している不透明なバイト列です。
• signature。全体が証明書の保有者から来たことを証明するバイト列です。

署名の手順には小さな工夫があります。加盟店はすべてのフィールドを埋め、signatureを空にし、メッセージ全体をシリアライズし、そのハッシュを計算し、リーフ証明書に対応する秘密鍵でハッシュに署名し、その署名を直前に空にしておいたフィールドに書き込みます。検証側はそのフィールドを再び空にし、再シリアライズして検証します。単純で自己完結しており、証明書以外の何にも依存しません。

その依存が問題でした。証明書チェーンを検証するには、ウォレットがルート証明書ストアを保持する必要があり、デスクトップソフトウェアはそれをオペレーティングシステムから引き継ぎ、モバイルソフトウェアはしばしば誤って扱いました。正しく実装しても、何らかの認証局がドメイン名を証明したことしか示せず、ルートストアには数百の認証局が含まれ、そのどれもが任意の名前に対して証明書を発行できます。用意された選択肢の中で最も弱いx509+sha1は、特に悪い形で古びました。BIP70が書かれてから4年後の2017年2月23日に、実際に成立するSHA-1の衝突が公表されたのです。

目にする場面

PaymentRequestという名前は今も2か所で使われており、ビットコインと関係するのはそのうち1つだけです。

1つはアーカイブされたコードとドキュメントで、BIP71のMIMEタイプapplication/bitcoin-paymentrequestが、加盟店のサーバーが返す応答に付けられていました。もう1つは現代のウェブプラットフォームで、PaymentRequestはカードや保存済みの支払い方法によるチェックアウト向けのブラウザAPIを指し、このプロトコルとは何の関係もありません。今日この語を使う開発者はほぼ確実にブラウザの方を指しており、両者を混同することが、古いビットコインのドキュメントを検索する際の最もよくある誤りです。

ビットコインを購入する人にとっての要点は、身元が支払いにどう結び付くかです。取引所は口座と本人確認（KYC）でこれを解決するため、プラットフォームはあなたが誰かを把握し、あなたはプラットフォームの評判に依拠します。自己管理は、あなた自身がアドレスを確認することで解決します。BIP70はウェブの証明書システムを借りるという第3の道を試みましたが、その道は閉ざされています。

PaymentRequest vs PaymentDetails

PaymentRequestは封筒で、PaymentDetailsはその中の手紙です。封筒を読めば誰が署名し、どの証明書を使ったかが分かりますが、何が要求されているかは分かりません。金額、スクリプト、有効期限、メモはすべて内側のメッセージにあり、再エンコードによって署名が無効にならないよう、まさにそのために未解析のバイト列として封筒に入っています。ウォレットは、内側の内容を何か信頼する前に、まず外側を検証する必要がありました。