ペイメントハッシュ

ライトニングのルート上の各ホップは同じペイメントハッシュを見ます。これが各ホップに対して支払いを識別するものです。BOLT 11は、インボイスごとにちょうど1つを要求し、256ビットを運ぶ52文字のbech32として書きます。対応する秘密を示すことが資金を請求する唯一の方法であり、その後その秘密を保持していることがあなたの領収書になります。

仕組み

ペイメントハッシュはその反対物として生まれます。受取人は32バイトのランダムな値を選び、これをペイメントプリイメージと呼びますが、そのSHA-256だけを公開します。

その値はタグpの下でインボイスに入ります。BOLT 11はこのタグをdata_lengthの52に定め、ちょうど1回だけ要求します。そこから値はupdate_add_htlcの中でルートを下っていきます。メッセージタイプ128で、そのフィールドはチャネルID、64ビットのカウンター、ミリサトシ単位の金額、payment_hashそのもの、CLTV有効期限、1366バイトのオニオンです。このメッセージの中で二重の役割を果たします。関連データとしてオニオンの構築にも渡されるため、各ホップのHMACがこの値にコミットします。したがって、古いオニオンパケットを異なるペイメントハッシュに対して再生すると、チェックする最初のノードで失敗します。

決済はハッシュを逆方向にたどります。受取人はupdate_fulfill_htlc、メッセージタイプ130の中で、32バイトの生の値としてプリイメージを返し、上流の各ノードは同じチャネルを通じてそれを戻します。保持しているハッシュにSHA-256が一致しないプリイメージを渡されたノードは、それを単に無視するのではありません。BOLT 2は、警告を送って接続を閉じるか、エラーを送ってチャネルを失敗させるかのどちらかでなければならないと述べています。無邪気な説明が存在しないからです。

オンチェーンではハッシュは切り詰められます。HTLC出力スクリプトは32バイトの値を一切含みません。RIPEMD160(payment_hash)、すなわち20バイトのコミットメントに対するOP_HASH160の比較を実行し、支払う側がウィットネスの中でプリイメージを提供します。同じ丸めた金額と同じペイメントハッシュを持つ2つのオファーされたHTLCは、有効期限が異なっていてもバイト単位で同一の出力を生成します。そのためBOLT 3はそれらの順序付け規則を指定しなければなりません。

1つの要件は、その背後にある攻撃を見るまで奇妙に見えます。ノードは同じペイメントハッシュを持つ複数のHTLCを受け入れなければならず、BOLT 2がその理由を示しています。重複が拒否されれば、攻撃者は既知のハッシュで探りを入れ、そのノードがすでにその支払いを保持しているかどうかを知ることができてしまうからです。重複を見分けるために、別個の64ビットのIDが存在します。

ビットコインを購入するときにこれが重要な理由

当サイトでレビューしている63社の取引所のうち2社は、手数料に関する注記でライトニングによる支払いについて記載しています。Strikeは出金に関する注記で、ウォレットへの出金はライトニングとオンチェーンで対応していると述べており、Coinbaseは手数料表でライトニング送金を送金額の0.2%としています。

これらの支払いの1つが止まったとき、ブロックチェーンには何も届いていないため、調べるべきトランザクションIDはありません。ペイメントハッシュは、あなたのウォレットのログと取引所のバックオフィスの両方が保持する唯一の文字列です。そのため、画面を閉じる前に支払いの詳細画面からコピーしておいてください。ライトニング出金の「トランザクションID」を求めるサポート窓口は、この値を求めています。

返ってくるエラーから分かることは多くなく、それは意図的なものです。BOLT 4は5つの別個の問題を1つの失敗コードincorrect_or_unknown_payment_detailsにまとめており、番号はPERM|15です。ハッシュが最終ノードにとって未知である、ペイメントシークレットがそれと一致しない、そのハッシュに対する金額が低すぎる、有効期限が現在のブロック高に近すぎる、または必須の支払いメタデータが欠けている、という問題です。仕様はこの統合を説明しています。以前の分割されたコードでは、転送するノードが同じハッシュをはるかに低い値で先へ送り、その返答を読むことで支払いの行き先を推測できました。あなたのウォレットが理由を隠しているのではなく、ウォレットにその理由が伝えられたことがないのです。そのため、インボイスを再生成して再度支払うことが実用的な対応です。

同じ値はあなたのノードから受取人のノードまで同一のままであり、マルチパート支払いのすべての部分にわたっても同様です。BOLT 4はこれらが単一のペイメントハッシュを共有することを要求しています。これを2回見た者は、1つの支払いを見ていると分かります。当サイトのPhoenixのレビューは、ACINQ自身のFAQが、そのウォレットを通じて行われた支払いの最終的な宛先と金額を知っていると認めている箇所を引用しています。これは同じ露出の率直な表現であり、当サイトが推測したものではなくベンダー自身が述べたものです。

関連する理由から、インボイスの再利用は役に立たないどころか有害です。BOLT 4は、すでに支払われたハッシュを渡された最終ノードに、それを未知として扱うか資金を受け入れるかの自由を残しています。そのため、再公開されたQRコードの結果は、受取人がたまたまどの実装を動かしているかによって変わります。

BOLT 11の寄付テストベクターでペイメントハッシュをデコードする

BOLT 11の仕様には、解説付きの寄付用インボイスの例が含まれており、その中のペイメントハッシュは、どのウォレットも決して生成すべきでない固定のテスト値です。

その例は「Please make a donation of any amount using payment_hash 0001020304050607080900010203040506070809000102030405060708090102」という見出しが付いており、文字列はlnbc1pvjluezで始まります。lnbcの接頭辞とbech32の区切りの後に、pvjluezはタイムスタンプで、1970年の始まりから1496314658秒です。次にペイメントシークレットのフィールドが来て、その後にpタグ、次にp5が来ます。これが長さです。bech32ではpは1で、5は20なので、フィールドは1 * 32 + 20 = 52文字になります。これらの文字、qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqは、その見出しに引用されたハッシュにデコードされます。

これについて秘密なところは何もありません。仕様はその例の署名に使う秘密鍵e126f68f7eafcc8b74f54d269fe206be715000f94dac067d1c04a8ca3b2db734を公開しており、その節のすべてのインボイスは別段の注記がない限りペイメントシークレット1111111111111111111111111111111111111111111111111111111111111111を持つと述べています。したがって、これらの文字列は支払い要求ではなくパーサーのテストデータです。ウォレットや診断ツールがテストスイートの外でそのハッシュを表示することがあれば、何かがあなたの支払いを報告しているのではなく仕様をそのまま反映しているのです。

ペイメントハッシュvsトランザクションID

ペイメントハッシュはライトニングの支払いを指し、トランザクションIDはビットコインのブロックチェーン上に存在するトランザクションを指します。どちらも32バイトで、どちらも64桁の16進数として表示されます。それが両者が互いのサポートフォームに入り込む理由です。トランザクションIDは事後にトランザクション自身のバイトから計算され、任意のブロックエクスプローラーに貼り付けられます。ペイメントハッシュは支払いが存在する前に受取人が選ぶもので、支払いが通常どおり決済されるときにブロックに現れることはなく、エクスプローラーで何も返しません。検索結果が空であることは通常、正しい値と間違ったツールを持っていることを意味します。

ペイメントハッシュvsペイメントシークレット

ペイメントハッシュとペイメントシークレットは、同じインボイス内の2つの異なる256ビットの値であり、タグpとsで運ばれ、それぞれ52文字のbech32として符号化されます。ハッシュは必然的に公開されます。各ホップがHTLCを構築するためにそれを見る必要があるからです。シークレットはオニオンの中で最終ノードにのみ届けられ、BOLT 11はその役割を1行で述べています。すなわち、それが「prevents forwarding nodes from probing the payment recipient」ということです。sフィールドを見つけられない読み手は、支払いを直ちに失敗させなければなりません。ハッシュは錠であり、シークレットは、支払う者がそのインボイスを発行した人から受け取った証拠です。