LNURL

アンナが、作者を支援するコード、引換券を使うコード、そしてサイトにログインするコードを順に読み取る場面を想像してください。スマートフォンの操作は似ていますが、そのたびに承認する内容は違います。LNURLでは、payRequestが支払い、withdrawRequestが出金、loginがログインを表します。各手順はLUDという文書に記載されています。これはアプリ同士が任意に採用する取り決めで、Bitcoinのルール変更ではありません。ある手順に対応するウォレットでも、ほかのすべてに対応するとは限りません。 [1] [7]

payRequestでは、サービスから説明と指定可能な金額の範囲が返されます。アンナはドメイン、つまりサービスのウェブアドレスを確認し、説明を読んで支援額を選びます。条件に同意すると、ウォレットが具体的なBOLT 11 Lightning請求書を取得し、支払う前に選んだ金額との一致を確認します。内部ではcallbackアドレス、minSendableとmaxSendableの下限・上限、metadataの説明を使います。金額はamountで送り、請求書はprで受け取ります。単位はsatoshiの千分の一であるmsatです：1000 msat = 1 sat。同じ公開QRをほかの人も使えますが、読み取りは支払い完了を意味しません。 [3]

withdrawRequestではお金の向きが逆になります。アンナはサービスに払うのではなく、そこにある残高を引き出したいのです。そこで自分のウォレットが受け取り用の請求書を作り、サービスに支払ってもらいます。サービスは識別子k1、callbackアドレス、msat単位のminWithdrawableとmaxWithdrawableを提示し、承認後にウォレットがprで請求書を送ります。OKは依頼を受け付けたという意味で、アンナへの入金完了ではありません。ウォレットは引き続き着金を待ちます。出金コードは持っている人が使える引換券のように働く場合があるため、通常の受け取り先のように公開しないでください。 [4]

別のサイトでアンナはLNURL-authを選びます。ウォレットはドメインと、tag loginが付いた要求の目的を表示します。同意すると、そのドメイン専用の秘密鍵linkingPrivKeyで、一度限りの確認要求k1に署名します。サービスには署名と対応する公開鍵linkingKeyを送り、公開鍵で署名を検証してもらいます。秘密鍵は渡しません。サービスは同じ鍵の持ち主が戻ってきたと分かりますが、この確認だけで現実の身元まで分かるわけではありません。ウォレットは、鍵を導出する出発点となる秘密値seedも、復元用の単語であるSeed Phraseもサービスに送りません。技術的にはsecp256k1上のECDSA署名です。actionは登録、ログイン、アカウントの関連付け、または別の許可を表すため、確認画面は最後まで読む必要があります。この要求への署名自体はBitcoinの支払いではありません。 [5]

要求を送ること、サービスから返事をもらうこと、実際にお金が移ることは別々の段階です。通信が切れたら、アンナはまずウォレットで元の支払いを確認します。新しい請求書でやり直すと、もう一度支払うことになりかねません。任意のLUD-21は特定の請求書を調べるverifyアドレスを追加します。settled trueは決済済みという報告、settled falseは未決済という報告です。OKだけでは不十分です。返答にはpreimageという、支払いに対応する元の秘密値が含まれることもあります。ウォレットはその値から照合用の値であるハッシュを計算し、正しい請求書に記載された支払いハッシュと比較します。何らかの秘密値を受け取ればよいのではなく、その支払いに対応している必要があります。結果確認によって、サービスの稼働や受け取り側への経路容量であるインバウンド流動性が確保されるわけではありません。 [6] [3] [4]

HTTPSはウォレットとサービスの間の通信を保護しますが、サービス自身から情報を隠すものではありません。サービスは要求、その時刻、繰り返しの利用を観測できます。ログインでは完全なドメイン名も重要です。サブドメインが変わるとlinkingKeyが変わり、サイトからは別の利用者に見える場合があります。アプリごとに鍵の導出方法が異なるため、ほかのウォレットに移しても同じログインを復元できるとは限りません。大きな変更の前に、そのアカウントへのアクセスをどう復元するか確認しましょう。LNURL自体はbitcoinの鍵を誰が持つかを決めません。それはウォレットとサービスの仕組みによります。 [2] [5]

基本となるLUD-01は、HTTPSまたはonion URLをBech32で表します。これは符号化であり、アドレスの暗号化でもBOLT 11請求書でもありません。ウォレットはリンクから直接tagを読むか、データを取得するGETウェブ要求を送り、JSONの返答から操作を判断します。JSONはアプリが読み取れるようにデータへ名前と構造を与える形式です。したがってQRの画像だけで受取人の身元は確認できません。リンクの中身と、その後に表示されるドメイン、操作、条件が重要です。 [2]

支払い手順のmetadataは、JSON配列を含む文字列です。text/plainの説明が必須で、それ以外の種類は任意です。何に同意するか分かるよう、ウォレットは説明をドメインや金額と一緒に表示する必要があります。基本のLNURLが解釈するのはJSONの応答本文で、HTTPステータスコードだけではありません。サーバーにつながっても要求が成功したとは限らず、本文にERRORが入ることがあります。同じように、prで請求書を受け取っても支払い済みではありません。アプリはこれらの異なる情報を、一つの緑色のチェックにまとめるべきではありません。 [2] [3]