ライトニングでは原則的に送金を受け取る側が先に一度限りしか使えないインボイスを発行して送金者に送る必要があり、これがユーザー体験を複雑にしていると言われがちです。そこでLNURL-payという仕組みができ、ウェブサーバーを立ち上げて特定のパスへのアクセスをさばくことで「オンデマンドでインボイスを発行できる」ようになりました。

LNURL自体も人間には読めない長い文字列であったため、LNURLへと「変換」できるLightning Addressというものが生まれました。メールアドレスのようにuser@domain.comという形式のLightning Addressに対して支払いたいユーザーのウォレットは、domain.com/.well-known/lnurlp/userというURLにインボイスを取得しに行きます。

詳細は下記の記事からどうぞ。

Lightning Addressと乱立するインボイス請求方法
ライトニングネットワークを用いたペイメントにはインボイスという1回1回の支払いごとに異なる情報が用いられます。そのため、非推奨ながらも固定のアドレスを使い回せるオンチェーンの送金と異なり、ライトニングで送金を受け取るにはインボイスの発行という手順が最初に必要になります。 送金を送金者から開始したい場合に、宛先のノードにインボイスの発行を依頼する方法は前からいくつかありましたが、最近このあたりを考えている人が多いように感じます。今日は8/20にリリースされたLightning Addressを紹介し、他の方法との類似点や違いを見ていった後に、将来的にどうなるのか予想してみます。 https://lightningaddress.com/ 既存のインボイス請求方法 既存のインボイス請求方法で一番有名なのは圧倒的にLNURL-Payだと思われます。これはLNURLという仕様群の1つで、ノードの運営者がLNURLのリクエストを捌くサーバーを動かすことで、「インボイスをくれ」「はい、どうぞ」という流れなどを自動化することができます。 毎回異なるインボイスと違い、LNURLは変更せず使

Lightning Address / LNURLの最大のネックはサーバーを立てる必要があること、そして自分のライトニングノードが必要なこととされてきました。このあたりを解決すべく登場したいくつかのプロダクトも本稿で取り上げています:

独自ドメインでLightning Addressを設定する方法、どれがいい?
最近ツイッター(X)に対して思うところがあり、将来的なことを見据えてNostrに力を入れることにしました。というわけで、週に1回つぶやく程度だったアカウントをちゃんと整備して、クライアントもちゃんと選んで、1日数回見ています。 きっかけは以下のポッドキャストにおけるMatt Odell氏の「XはKYCを半強制してくる」という予想でした。広告モデルとしてもユーザーデータが多いことに越したことはありませんし、スパムやボット対策にもなりますから全然ありえる話だと思います。 イーロン・マスクがトルコ政府の圧力に負けて選挙期間中に野党候補のアカウントを凍結したこと、Twitter Blue認証やスパム対策・ボット対策、そして広告ビジネスとデータ収集の相性を考えたときに、1.ツイッターがユーザーのKYCを進めるインセンティブがあること、2.そのKYC情報を元に不利益な扱いを受ける可能性が決して小さくないこと、というOdell氏の見立てが印象的でした。 さて、TwitterになくてNostrにある神機能の1つが“Zap”です。過去にも何回か触れているように、ZapとはLNURL規格を応用した投

前置きが長くなりましたが、最近BOLT12が使えるウォレットが増えてきました。例えばPhoenix Wallet、Core Lightningなどが対応しており、Lndが年末~来年にかけて対応すれば来年にも一般的な技術となるかもしれません。今日は、BOLT12の導入によってLightning Addressと同じようなことを、サーバーを立てる必要なしに実現するための方法BIP-353を解説します。

BOLT12についてはこちらをご覧ください:

BOLT12の新しいインボイス形式がライトニングをよりEコマース向けに進化
エンドユーザーでもライトニングネットワークの利用時に必ず目にするインボイス。現行の形式のかゆいところに手が届く、新しいインボイスの仕様が提案されています。今日はライトニングの新しいインボイスの仕様として提案されているBOLT12について見ていきます。 BOLTとは Basis of Lightning Technology (BOLT)とは、ライトニングネットワークの仕様を定めた仕様集です。現時点ではBOLT0~5と7~11が定められています。(6番は7番に置き換えられて欠番です)現在のインボイスの形式を定めたBOLT11の欠点を改善するものとして、今回紹介するBOLT12が提案されています。 現在のインボイスの不自由な点 BOLT11に定められている現在のインボイス形式は、送金を受け取りたい方がインボイスを発行して、送金する側がそのインボイスに従って送金し、送金が完了するとインボイスの作成に使用されたプリイメージというデータを受け取って確認できるというものです。本コラムでもおなじみですね。まず、このインボイスの形式には使っているうちにわかってきた不自由な点がいくつかあります。

・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についての記事はこちらです:

第三者からプライバシーを守る新しい支払い方法、Silent Payments
ビットコインで寄付を受け付けたいとき、ウェブサイトなどにビットコインアドレスを公開することが一般的です。この方法のメリットはどのウォレットでも必ず使えること、送金する際に相手との通信等が不要なこと(新しいアドレスを発行してもらう必要がない)、アドレスを生成して貼り付けるだけというシンプルさです。また、場合によっては集まった金額を見てもらいたいという場合もあるでしょう。 一方で、集まった金額の透明性はそのアドレスに対する送金がすべて見れてしまうことの裏返しです。このため、特定の団体に寄付したユーザーのトランザクションを辿って本人を特定したり、逆にその団体の資金の流れを追って取引所等の口座を凍結することができてしまいます。 この問題の解決方法はBIP47、寄付の両側でのミキシング等いくつかありますが、今日はそれらと比較してシンプルさが際立つ“Silent Payments”という新しいものを解説します。 仕組み 送金を受け付けたい者は32バイトの公開鍵X = x*Gを「サイレントアドレス」として公開します。 送金したい者はサイレントアドレスを見て、自身の持つUTXOから送金に使

プライバシー面で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の再利用可能性を活用しながら、送金者のプライバシーが守られやすいという機能性自体には価値があると思います。

それにしてもビットコインマークの入力しにくさ、どうにかならないですかね…。