本文へスキップ
buybitcoinsmart

用語集 / ライトニングとレイヤー2

Keysend

Keysendとは?
Keysendは請求書なしでライトニングの支払いを送ります。支払者が32バイトのプリイメージを生成し、それをハッシュ化して支払いハッシュとし、その秘密をオニオンの中に載せて送ります。

Keysendは、受取側が秘密を選んでそのハッシュを請求書で公開する、通常のライトニングの流れを逆にします。送信者の秘密はカスタムTLVレコード5482373484(偶数)に載り、BOLT 1はkeysendを知らないノードに対して、これを無視するのではなく拒否するよう定めています。往復なしでノードの公開鍵だけを相手に支払うことができ、その代わりに請求書が残したはずの暗号学的な受領証を失います。

仕組み

Keysendは、BOLT 1の1つの規則のより厳しい側に依拠しています。読み手は未知のTLVレコードの型が奇数であればそれを破棄して処理を続けますが、未知の偶数であればストリーム全体を失敗させなければなりません。

2^16未満の型識別子はBOLT用に予約されており、2^16以降はすべてカスタムレコード用に自由です。そしてBOLT 1は、通常のノードがデータを無視すべき場合は奇数を、拒否すべき場合は偶数を選ぶよう定めています。bLIP-3は、5482373484が元のlnd実装によって無作為に選ばれたと記録しており、その末尾は4なので、keysendは拒否する側に落ち着きました。だからこそ機能ビットが必要です。受け入れるノードは54/55を告知し、これはkeysendと名付けられてvar_onion_optinに依存しており、bLIP-3は、送信者は盲目的に送って失敗を見るのではなく、これを探すべきだと述べています。

bLIP-3に示された送信者の作業は短いものです。暗号学的に安全なランダムな32バイトの値を生成し、それをそのレコードに入れ、update_add_htlcのpayment_hashをそのSHA-256に設定します。プリイメージを再利用してはならず、すでに支払った請求書のプリイメージも再利用してはなりません。パケットは各ホップで難読化されるため、あるホップが復元できるのは次のホップのアドレスだけであり、途中の誰もレコードを見ません。最終ノードは見つけた値をハッシュ化し、受け入れるよう求められたハッシュと照合して決済します。

拒否は意図的に静かに行われます。BOLT 4には、ノードが理解しなかったペイロードに対する文字どおりの応答PERM|22 invalid_onion_payloadがあり、問題のTLV型を名指しすることさえあります。bLIP-3は、受取側が代わりにPERM|15 incorrect_or_unknown_payment_detailsを返すよう求めており、拒否されたkeysendは、ノードが一度も発行していない支払いハッシュと区別がつきません。

使われる場面

Keysendはポッドキャストのブーストを支える基盤です。

bLIP-10は2つ目のレコード、型7629169を定義しており、これは元々Breezが選んだもので、keysendの支払いに添える平坦なJSONの塊を運びます。ポッドキャストのタイトル、エピソード、再生位置を秒で示すts、boostまたはstreamを設定するaction、そして省略可能なmessageであり、これがブーストグラムを成立させます。分単位のストリーミングではseconds_backを60に設定します。このレコードは奇数であり、だからこそbLIP-10は後方互換性を気にしません。メタデータを無視するホストもサトシはそのまま受け取れるからです。これが存在するのは、keysendだけでは受取側に何も伝わらないため、アプリが番組名を自ら示さなければならないからです。

同じ欠落が、keysendを購入の流れから遠ざけています。取引所の出金は、請求書を渡すか、こちらに請求書を求めるかのどちらかです。プラットフォームは支払いをあなたの口座に結び付ける必要があるからです。そして当サイトの63件の取引所の記録にも41件のウォレットのレビューにも、この語は一切現れません。bLIP-3はそのトレードオフを正直に述べています。keysendは、よりよく設計された自発的な支払いに道を譲ると想定しており、offersとAMPを挙げ、その間失うものとして支払いの証明と、最終的なCLTV有効期限に対する受取人のいかなる発言権も列挙しています。

Keysend vsライトニングアドレス

Keysendもライトニングアドレスも、請求書を一度も渡してこなかった相手に支払えるようにしますが、請求書を本当に省くのはそのうち片方だけです。user@example.comと入力すると、ウォレットはHTTPSによる照会を行い、新しいBOLT11の請求書を受け取ります。つまりプリイメージは依然として受取側が選んでおり、あなたは相手の署名で裏付けられた受領証を手にすることになります。Keysendはウェブリクエストもサーバーも必要とせず、33バイトのノード公開鍵とそこへの経路だけを必要とし、後から支払いを証明するものは何も残りません。秘密は最初からあなたのものだったからです。支払ったことを示す必要が生じうるなら、請求書を選んでください。

混同しやすい用語

よくある質問

keysendはライトニングの仕様の一部ですか?

いいえ、keysendはbLIP-3にあり、これは2021年12月8日に、実装がすでに提供していた内容を文書化するために作られたライトニングの改善提案です。2^16以降のTLV型識別子はカスタムレコード用に自由であるため、BOLTの変更は必要ありませんでしたが、keysendの型5482373484は偶数なので、BOLT 1は、これに対応していないノードに対して、ペイロードを無視するのではなく拒否するよう定めています。

keysendの支払いは私が支払ったことを証明しますか?

いいえ、プリイメージは受取側ではなくあなたが生成したものであり、支払いを相手に結び付ける請求書の署名が存在しないからです。bLIP-3は、失われる支払いの証明をkeysendの主な欠点の1つとして挙げています。ですから受領証が重要な場合は必ず請求書を使用してください。

keysendの支払いはなぜ失敗したのですか?

最も多いのは、宛先がkeysendを受け付けないためですが、それはエラーからは分かりません。自発的な支払いを拒否するノードはPERM|15 incorrect_or_unknown_payment_detailsを返します。これは、プリイメージが誤っている場合や、ノードが一度も発行していない支払いハッシュの場合と同じ失敗であり、そのためbLIP-3は、bLIP-2で54/55として登録されているkeysendの機能ビットを告知しているノードにのみ送るよう指示しています。

次に読む

関連用語

ライトニングとレイヤー2のその他の用語

このページを英語で読む