BOLT12でLightning Addressのような機能をよりシンプルに実現するための提案BIP-353
ライトニングでは原則的に送金を受け取る側が先に一度限りしか使えないインボイスを発行して送金者に送る必要があり、これがユーザー体験を複雑にしていると言われがちです。そこでLNURL-payという仕組みができ、ウェブサーバーを立ち上げて特定のパスへのアクセスをさばくことで「オンデマンドでインボイスを発行できる」ようになりました。
LNURL自体も人間には読めない長い文字列であったため、LNURLへと「変換」できるLightning Addressというものが生まれました。メールアドレスのようにuser@domain.comという形式のLightning Addressに対して支払いたいユーザーのウォレットは、domain.com/.well-known/lnurlp/userというURLにインボイスを取得しに行きます。
詳細は下記の記事からどうぞ。

Lightning Address / LNURLの最大のネックはサーバーを立てる必要があること、そして自分のライトニングノードが必要なこととされてきました。このあたりを解決すべく登場したいくつかのプロダクトも本稿で取り上げています:
前置きが長くなりましたが、最近BOLT12が使えるウォレットが増えてきました。例えばPhoenix Wallet、Core Lightningなどが対応しており、Lndが年末~来年にかけて対応すれば来年にも一般的な技術となるかもしれません。今日は、BOLT12の導入によってLightning Addressと同じようなことを、サーバーを立てる必要なしに実現するための方法BIP-353を解説します。
BOLT12についてはこちらをご覧ください:
・DNSの設定+サーバーの立ち上げからDNSのみへ
・プライバシーを重視するには追加の工夫が必要
・普及への障害はDNS設定の馴染みの薄さとノード運用の負担か
DNSの設定+サーバーの立ち上げからDNSのみへ
冒頭で述べた通り、Lightning Addressを使おうと思うとサーバーを立て、自分のノードに接続し、ドメイン(DNS)を設定してサーバーに向ける必要があります。でもサーバーを立てて公開するのって面倒なんですよね。
BIP-353の仕組みではサーバーが不要になります。
BIP-353ではLightning Addressに非常によく似たalice@example.comという形式のアドレスを使います。(Lightning Addressと区別するために冒頭にビットコインマークをつけて₿alice@example.comにすることを提案者は推奨していますが、打ちにくいので採用されない気がします。)送金者のウォレットがDNSサーバーにalice.user._bitcoin-payment.example.comのTXTレコードを問い合わせると、そこにはBOLT12 Offerが記述されており、それを元に送金者のノードがインボイスを要求できる、というわけです。
ちなみにDNSとはドメイン名から実際のIPアドレスを逆引きすることでインターネットの通信を可能にしている技術の1つです。逆引きに使うレコードにはA/AAAAレコード(DNS→IPアドレス)、CNAMEレコード(ドメイン→ドメイン)などがあります。ほかにもたくさんの種類のレコードがあります。
BOLT12はライトニングノード同士の通信によってインボイスを取得してくる規格なので、送金者が宛先ノードから直接BOLT12 Offerさえ取得できればいいためこのようなシンプルな規格が実現できます。さらに都合のいいことに、インボイスと違ってOfferは何度でも使えます。
つまり、LNURL/Lightning Addressでいうサーバーの役割をライトニングノードが、インボイスの役割をDNS TXTレコードに記述されたOfferが担うわけですね。
ところで、「それならBIP-353のような仕組みを導入しなくても、いろんなところにOfferを張り付けておけば使えるのでは?」という疑問を抱いた方もいるかもしれません。実際、そのようにしてもOfferは使えますが、かなり長い文字列となってしまうため例えばツイートに収まりきらない、QRコードにすると想像を絶する巨大なQRコードになってしまう、といったような問題があります。(実際、TXTレコードも1文字列255文字までという制限があり、Offerも2つの文字列に分けて記述することになります)
それ以上に、Lightning Addressのシンプルさは実際にどこかからOfferをコピペしてくるより使いやすいという点がなにより大きい気がします。
プライバシーを重視するには追加の工夫が必要
Offerの1つの魅力はプライバシーでもあります。通常のライトニングのインボイスと同様に、非公開チャネル(いわゆるプライベートチャネル)しか持たない、大多数のノードに存在を認知されていないノードでも、自身のIPアドレスやチャネルを広く公開することなくOfferを公表しインボイスを配布することができます。
BIP-353はこのプライバシー機能を活用できるのでしょうか?答えはYESですが、Offerにビットコインアドレスを併記したい場合に関しては注意が必要です。
ビットコインアドレスをDNSレコードに追加すると、それが収集される可能性があります。仮に毎回アドレスを変える(DNSレコードを更新する)運用をしても、アドレスを使いまわししているのと実質的に変わらないと考えたほうが良さそうです。しかも、送金があるたびにDNSレコードを更新しようと思うとサーバーを立てる必要が出てきますよね。
仮にSilent Paymentsのような仕組みに対応した場合は固定の文字列を公開するだけで毎回違うアドレスを送金者に生成してもらえるので解決しますが、その代わり別の負担が生まれます。Silent Paymentsについての記事はこちらです:

プライバシー面でBIP-353のよくできている点としては、LNURLサーバーではなく任意のDNSサーバーへの問い合わせによってOfferを取得するため、送金者のプライバシーが保たれやすいというメリットがあります。(LNURLサーバーだと特定のインボイスとそれをリクエストしたIPが紐づけられてしまうため)
普及への障害はDNS設定の馴染みの薄さとノード運用の負担か
このように、工夫次第では割と出来が良いように見えるBIP-353ですが、運用面でLightning Addressと比べて本当に楽なのか?という議論があります。
まず、DNSレコードは既定では署名など全くされていないため、問い合わせたときに改ざんされたデータが返ってくる可能性があります。改ざんされたOfferを元に送金すると、攻撃者のノードに送金してしまいかねません。
そこでBIP-353の考案者たちはDNSSECというDNSのセキュリティ機能を利用してDNSレコードに電子署名を付与し、送金者のウォレットはこれを必ず検証するというステップを必須にしました。DNSSECとは公開鍵などをDNSレコードに追加し、さらに上位のDNSサーバーにその公開鍵を認証してもらうことで「この公開鍵は確かにこのドメインの所有者のものだから、これで署名が検証できれば改ざんされていないDNSレコードである」ことが保証できます。
DNSSECについては日本ネットワークインフォメーションセンターのサイトの説明をご覧ください。使っているドメインのレジストラによっては簡単に設定できるかもしれません。
このように、BIP-353の一番の問題は、DNSの設定自体あまり馴染みがないものなのに、さらにDNSSECというより高度な知識が要求される仕組みも利用しなければならないことでしょう。確かにサーバーを運用することも一般人にはなじみのないことですが、ライトニングノードを動かすついででできてしまいます。それが、DNSという別のレイヤーの知識が少し必要になることでハードルがかなり高くなってしまう気がします。
また前提の話になってしまいますが、BOLT12自体がまだ普及途上でほとんど機能していません。ライトニングネットワーク経由でインボイスを取得してくる都合上、自分のノードから宛先のノードまでメッセージを送信する必要がありますが、直接つながっていない場合は中間にある他のノードにメッセージを転送してもらう必要があります。しかし、ライトニングノードは「自分が理解できないメッセージは転送しない」設定になっているため、最大手のLndがBOLT12に対応するまではなかなかOfferが機能しないケースも考えられます。したがって、BOLT12の普及率が非常に高くなるまでBIP-353の出番自体あまりないかもしれません。
まとめ
このように少し馴染みの薄いDNS設定を上手に使っているBIP-353ですが、まだしばらくは触れる場面もあまりないでしょう。しかし、一般ユーザーからすると設定しにくかったとしても、Lightning Addressのユーザー体験を踏襲し、Offerの再利用可能性を活用しながら、送金者のプライバシーが守られやすいという機能性自体には価値があると思います。
それにしてもビットコインマークの入力しにくさ、どうにかならないですかね…。
次の記事
読者になる
一緒に新しい世界を探求していきましょう。

ディスカッション