普通のライトニングユーザーはライトニングノードの実装がいくつもあることをご存知ないかもしれません。代表的なものではLnd、c-lightning、Eclair、Electrum、Ptarmiganなどそれぞれの実装に特徴があり、共通点はライトニングのプロトコル(BOLT)への対応のみです。
共通規格以外の部分については各実装に委ねられているため、同じ実装間でしか使えない機能があったり、複数の実装に対応するアプリケーションの開発が難しかったり、不可能なことがあるという弊害があります。
今回の記事はその例として、LNURL-authの普及が阻まれていること、細かい違いがロックインに繋がっていることを解説します。
LNURL-AUTHとは
LNURL-authとはライトニングノードが公開鍵認証によってパスワードレスにウェブサイト等にログインするための規格です。LNURL-authに対応したウォレットにLNURLをコピーペーストするか、QRコードを読み取ることでワンボタンでログインすることができます。
裏ではサイト(URL)ごとに異なるキーペアが導出され、そのキーペアもログインにしか使用されないため匿名性の高いものとなっています。
スマートコントラクト界隈でのMetamaskサインインとほぼ同様のものですが、URLによってサインインに使用する鍵が違うため異なるサイトのアカウントを結びつけることができず、プライバシー面でのメリットがあります。
BIP39とAEZEEDという違い
一般的なビットコインウォレットはシードフレーズを元にたくさんの秘密鍵を生成することで大量のアドレスを扱うことができます。典型的なビットコインウォレットはBIP32階層的決定性ウォレット (HD Wallet)という規格を使っており、BIP39のシードフレーズ12/24単語から生成される「マスター秘密鍵」というものからBIP44に沿ってm/<用途>'/<チェーン番号>'/<ウォレット番号>'/<お釣り用or入金用>/<アドレス番号>という書式のパスを指定することで鍵を導出する具体的な方法を定めています。合わせて使うとシードとパスを控えれば同じアドレスが導出できる共通規格です。
さて、ライトニングノードにもビットコインウォレットの機能が付属しており、チャネルを開く際などにオンチェーンのアドレスを発行する必要があります。ところがライトニングノードの中でもLndはBIP39ではなく、BIP39にバージョン情報とシード誕生日という概念を加えたaezeedという方式を使用しているのでBIP39と互換性がありません。
LNURL-authはURLごとに異なる鍵を生成する方法として、URLから値a,b,c,dを算出し、BIP32・44に従ってm/138'/<a>'/<b>'/<c>/<d>という形式で導出します。したがって、元は同じシードを使用していても、Lndとそれ以外の実装ではシードの形式が異なるため生成される鍵が一致しません。ずっと同じ実装を使用する場合は実用上問題がなくても、移行したい場合などにポータビリティが担保されません。
さらに問題は続きます。
署名方法とLNURL-AUTH
Lndはメッセージへの署名機能で与えられたメッセージのSHA256ハッシュの結果に対して署名するのに対して、LNURL-authではメッセージ自体への署名を求めています。その上、Lnd自体にノード秘密鍵による署名機能はあれど、BIP32で導出した鍵を使って署名する機能はありません。これらのことからネイティブでのLNURL-authへの対応が不可能となっています。
署名を活用したユースケースはログイン以外にも多数考えられますが、実装による署名方法の違いは悩みの種です。後述のようにアプリケーション層の設計などで吸収するしかないように思われます。
アプリケーション層で吸収を試みたケース
有名なノード管理ツールのうち、ThunderHubは独自にLNURL-authに対応しています。下層で動いているノードがLndであっても、トップ画面→Quick Actions→LNURLから貼り付けることで使用可能です。これはThunderHub内からLndとEphemeral Diffie Hellman鍵交換で共通鍵を生成し、それをBIP39シードとして扱ってBIP32とLNURL-authの規格に沿って個別の鍵を生成しています。
あるいはその横のLNMarkets Loginというボタンも、裏ではLNURL-authを使用してLNMarketsに登録・ログインします。