BIP-21 URIをDNSで解決する仕様の提案BIP-353

Bitcoinで支払いをする場合、その支払先はアドレスという形で提供され、それをURI形式にしたのがBIP-21↓

techmedia-think.hatenablog.com

BIP-21のURIは、bitcoin:の後にアドレスやその他の情報がエンコードされる。ただ、アドレスも人が読みやすい/覚えやすいようなデータではないので、メールアドレスのようにuser@domainのような形で支払先の情報を提供し、それをDNSで解決して最終的にBIP-21 URIを入手できるようにしようという提案がBIP-353↓

https://github.com/bitcoin/bips/blob/master/bip-0353.mediawiki

LNに限定していないライトニングアドレスみたいな感じ。

形式

上述したように、支払い情報はexample@example.comの形式になる。ただこれだとメールアドレスと混同されることもあるので、BIPではプレフィックスとして₿を付加することを（つまり₿example@example.com）推奨してる。

支払い情報の解決

↑の情報を受け取ったら、DNSに対して、example.user._bitcoin-payment.example.comのTXTレコードをクエリする。BIPの作者のMatt Coralloのサンプル（matt@mattcorallo.com）をクエリしてみると、

$ dig TXT matt.user._bitcoin-payment.mattcorallo.com
...
;; ANSWER SECTION:
matt.user._bitcoin-payment.mattcorallo.com. 2796 IN TXT "bitcoin:?lno=lno1qsgr30k45jhvkfqxjqheaetacu4guyxvqttftvqu0f5sneckep3lkwdut7mmhhpcyjmlmnjn4hze8ed7pq88xqkxt2dcw5mlxhz644fms82f7k4ymfxs2ehhpjtxwxly0w5k8xdtlvpqyd8xzdq4tq8lgupnueshgydr330lc3j5kdcqh54gt7jdg9n68j4eqqeu7ts8uh0qxamee6ndj37tc6mzgejthvvjqj96p8dz2h" "rsh5z5n27qfk6svjz5pmkh0smq26k0j2j4q36xgq3r5qzet9kuhq4lydpen5mskxgjdvs5faqgv8pmj7cfd7ny84djksqpqk9ky6juc7fpezecxvg7sjx05dckyypnv9tmvfp6tkpehmtaqmvuupetxuzqf4t0azddjdcpasgw6hxuz9g"
...

というレコードが返ってくる。このURIの場合、Bitcoinアドレスは空で、lno=と続くデータはBOLT12のLNオファーのデータになってる。送信者はこのオファーを使ってインボイスを要求して、LN支払いする流れになる。

※ ちなみにBIP-21の仕様自体は、アドレスがBase58checkエンコーディングされていることなどレガシーアドレスが前提となっているなどの問題もあって、この仕様自体の更新に関する議論もある。

アドレスの再利用

DNSにクエリすることで支払先のURIが得られるけど、オンチェーン支払いに使用する場合、同じアドレスを返すことでアドレスの再利用に伴うプライバシーの悪化が懸念される。BIPでは再利用を回避すべくなるべく、TXTレコードの内容をローテションすることが推奨されてる。

ローテーションの面倒臭さは、サイレントペイメントを利用することで回避することはできるけど、その場合、受信側でオンチェーンのスキャンが必要になる。

DNSSECの検証

DNSのクエリは現状暗号化されたりしないので、受け取ったデータが改ざんされていない正しいデータなのか検証する仕組みが必要になり、そのためにDNSSECを使用する。

DNSに登録される支払い情報はすべてのDNSSEC署名されている必要がある。一応、1024 bit以下の鍵を持つRSAやSHA-1の利用はNG。

リモートリゾルバによる検証をトラストするのもNGで、クライアントが必ず検証する必要があると。

DNSのメリット

ライトニングアドレスのようにHTTPSベースの解決ではなく、DNSベースの解決を採用した理由として以下が挙げられてる。

HTTPSベースのエンドポイントに対してクエリをすると送信者のIPが収集されてしまう。DNSのクエリであれば、ISPが提供するリゾルバなどを介してクエリがプロキシされるケースが多いので、送信者のIPを特定しにくい。
肥大化したTLSのインフラへの依存
ブロックチェーンベースの代替手段では、名前空間と公開鍵のマッピングに関する簡潔な証明の欠如

BLIP-32

BIP-353に関連する仕様として、LNのBLIP-32が定義されている↓

https://github.com/lightning/blips/blob/master/blip-0032.md

これは、LNでBIP-353ベースの支払いアドレス宛に支払いをする際、自身がそのDNSの解決をできない場合に、このDNSの解決をOnionメッセージを使って別のLNノードにアウトソースし、解決した結果をDNSSECの署名と共にOnionメッセージで返してもらうための仕様。

所感

DNSの利用に関してはプライバシーやコスト的な部分はメリットあるけど、ライトニングアドレスみたいにサイト上のエンドポイント参照するのに比べて、DNSSECの署名の作成とかは一般的にハードル高そう。BLIP-32も、アウトソースされた側のインセンティブはどうなるんだろう？

Develop with pleasure!

福岡でCloudとかBlockchainとか。