Bitcoin Pizza Day 前夜祭〜Lightning Network決済を楽しむ会〜

こんにちは。ビットバンクのエンジニア、小渕です。

今回の記事は、Bitcoin Pizza DayでLightning Network決済の実証実験をしたという話をお送りします。

イベント内容

2022年5月21日(土)に六本木のTwo Dogs Taproomにて、Bitcoin Pizza Day⚡️前夜祭を行いました。

Pizza Dayは5月22日ですが、今年は日曜で、

会場のTwo Dogs Taproomは日曜定休
日曜よりも土曜の方が翌日を気にせず飲める(笑)

ということで、前夜祭(Eve Party)という形にしました。

クリスマスだってEve祝うし、Pizza DayもEve祝ってええやん、というノリですww

↓イベントの概要はこちらもご覧ください。
https://bitbank.cc/announcement/20220526_01/

イベントを行うきっかけ

練木照子さんとのTwitterのやりとりが発端で、Pizza Day Meetupをやることに。

練木照子さんは、「ビットコイン・スタンダードお金が変わると世界が変わる」の翻訳をされたり、Tokyo Bitcoin Hackers Meetupの共同オーガナイザーをされているビットコイナーです。

練木さんがお勤めのLightning Network専門のVenture Capitalフルグル合同会社と弊社ビットバンクに加え、Lightning Networkのプロトコル開発を推進しているテックスタートアップNayuta、日本のLightning Network技術コミュニティDiamond Handsの4団体の共催で行うことになりました。

店の紹介

Two Dogs Taproomは六本木にあるビアレストランです。

他店では飲めない日本と海外のクラフトビールを数多く揃えています。

また、店には煙突付きの石窯があり、アメリカンピザがとても美味しいです！

Bitcoin決済に対応しています。

筆者は東京Bitcoin Meetupで通っていた際に料理やクラフトビールの美味しさの虜になり、プライベートでもよく通っています。

食べログはこちら

以下の写真はイベントとは別のタイミングで行ったときの写真です。

クラフトビール Pintサイズ(473ml)

Pizza ローストチキンハラペーニョサワークリーム Mサイズ

イベント参加の流れ

イベント内容をPDFで作成後、参加募集フォームをGoogle Formで作成して、Diamond Hands Telegram Groupにて募集しました。

3,800円の飲み放題付きコースのピザをグレードアップ&量を増やしていただき、4,000円のコースとして提供してもらうことに。

参加者には事前に4,000円相当のBTCをLightning Networkにて支払ってもらう形にしました。

事前の参加費支払い

当初Umbrelでの受け取りを予定してましたが、Blue WalletやMuun Walletなどモバイルウォレットでの受け取りに切り替えて正常に受け取りができました。

後日、Umbrelでうまくいかなかった原因を検証。

その際、Blue Walletでもエラーが起きました。

うまくいかなかったことを中心にまとめました。

Umbrelとは

はじめに、Umbrelについては弊社エンジニアの宮本丈が書いた記事「Raspberry Pi 4 + Umbrel でビットコイン環境構築」によくまとまっているのでこちらもご覧ください。

Umbrelでの決済受付がうまくいかず

当初、私のUmbrelでInvoiceを発行して支払ってもらう予定でしたが、一人目の決済時にエラー。

自分でも試してみましたが、やはりエラー。

UmbrelのInvoiceをBlueで読み取って決済しようとしてエラー

UmbrelのInvoiceをMuunで読み取って決済しようとしてエラー

どちらもルーティングエラーのようです。

Blue WalletでInvoiceを発行して、決済を受け付けることにしました。

14件をBlueで受付、2件をMuunで受付し、いずれも正常に決済できました。

後からわかったUmbrel不調の原因としては、自宅のルーターで、Wi-Fiのルーティングがうまくいってなかったことです。

Umbrelのコンソール画面 ( http://umbrel.local/ )にもアクセスできないことが多々ありました。

支払い受付の1週間前ほどのテストではUmbrelで発行したInvoiceへの支払いが何回やってもうまく行けていたので、ルーティングがうまくできていたのでしょうが、Umbrelのようなセルフホスティングするシステムは要注意ですね。

UmbrelはWi-Fiで接続していたところ、LANケーブルを挿せば、Muunでは発行したInvoiceへの支払いができるようになりました。

ただし、Blueでは引き続き問題が。Umbrelで発行したInvoiceへの支払いをしようとすると、Payment is in transitというエラーが。

API errorも起こりました。

↑支払ったように見えるが、↓受け取り側のUmbrelでは成功していないんですよね。

このような成功したかわからない支払いは取引一覧画面で、Payment in transitionとして記録され、残高は引かれていました。

（※画面によって、Payment is in transit、Payment in transitionと表記が異なりますが、どちらも同じものだと思われます）

なお、支払いが成功した場合は、Invoice中にある場合はDescriptionが表示され、ない場合はLightning Paymentという表示になります。

数日後、Payment in transitionは消えていて、差し引かれていた残高は元に戻されました。

他にも、BlueでInvoiceを作成しようとしたときに、API failureのErrorが出たり。

Bitcoinは送金後、相手が受け取るまで安定していますが、Lightning Networkはウォレットによっては課題があります。送金時はこのリスクを承知の上で行う必要があると学びました。

なお、Payment is in transitionが発生した支払い／受取のウォレットの組み合わせは以下の通りです。

支払	受取	備考
Blue	Umbrel(LND)	筆者の試験送信時
Blue	Muun	筆者の試験送信時
Nayuta Core	Muun	イベント当日お店にて

Umbrelの中のLNDの操作

決済の不具合の調査などでLNDのログを見たり、コマンドを直接叩きたかったので、その時のTipsを共有しておきます。

Umbrelでの不具合を詳しく調べるには、Umbrelの中のLNDを調査する必要があります。

ssh umbrel@umbrel.local

Passwordはコンソール画面 ( http://umbrel.local/ )のものと同じです。

ログは~/umbrel/lnd/logs/bitcoin/mainnet/lnd.logにあります。

LNDのコマンドを操作するときは以下です。

docker exec lnd lncli listinvoices

ここでは、listinvoicesを使っています。

lncliのコマンドはlncli-commandsによくまとまっています。

上記、Umbrelで発行したInvoiceへBlue Walletで支払いをしたが、支払いがうまくいかなかった件で、Umbrelの中のLNDはやはり受け取っていないことを確認しました。

Payment is in transition

原因

P2PレイヤーのHTLCs(Hashed Timelock Contracts)上において、受取者のノード(Payee)から送信されたPreimageを支払者のノード(Payer)が受け取れていない状態です。

HTLCsの仕組みも交えて上記の図を用いて説明します。

アリスがデビットに支払いをする際、デビットはPreimage(Secret値R)のHash値をInvoiceに入れてアリスに提示します。

アリスはデビットのノードまでルーティングすると、中継ノードにHash(R)を渡して行きます。

Hash(R)がデビットまで到達すると、デビットはPreimageをアリスまでHash(R)が通って来たノードの逆に送っていきます。

Preimageがアリスまで到達すると、キャロル→デビット、ボブ→キャロル、アリス→ボブと残高が移るのですが、Preimageをアリスが受け取れていない状態がPayment is in transitionです。

対処法

支払いでLightning Networkで決済して、支払いに失敗してPayment is in transitionというエラーが表示された場合の対処法について記します。

BlueWallet help center に、そのエラーに対応するヘルプページがあります

このエラーが発生するということは、支払いに失敗したわけではなく、あくまでも「支払い処理が止まっている」という状態なので、支払いが成功する可能性があります。したがって、もう一回送金してしまうと二重支払いになる危険性があるので、Payment is in transitionという表示で留めておくLightning Networkの仕様になっています。

支払いがPayment is in transitionで止まって資金がロックされる最大の時間は、中間チャンネルのcltv_deltaというパラメータに依存します。デフォルト値はチャンネルごとに24時間ですが、それ以上の場合もあります。

つまり、チャンネルが3ホップある支払いの場合、72時間止まる可能性が高いということです。

支払いノードと受取ノード間全てのホップでタイムアウトが確認できれば、消費されていない残高のロックは解除されます。

この問題は、現在のLNのプロトコルが抱える大きな問題です。中間ノードがより安定したネットワークで運用されたり、Point Time Locked Contracts (PTLCs)という大幅なプロトコルアップデートによって改善される見込みですが、現在は支払者と受取者が協力して以下のどちらかの対処をする必要があります。

支払者は別の手段で決済を行い、Payment is in transitionとなっていた支払いが成功した場合は二重送金となるので、受取者に送り返し（キャンセル処理できる支払い方法であればキャンセル）をしてもらう
Payment is in transitionが成功するという前提で、一旦は支払い者からの再送は行わないが、タイムアウトしたら支払者は再送を行う。

個人的な感覚ですが、Payment is in transitionが発生して、数分以内に成功しなければ、タイムアウトする前提で上記1.の方法を取ることになるかと思います。

お店に導入してもらうウォレットの選定

当初はイベント1日限りでPOS機能付きでLightning Networkを含む暗号資産決済を受け付けられるBTCPay Serverの導入も考えましたが、Two Dogsさんへは継続してLN決済を導入すること、Two Dogsさんの運用上、自前のPOS端末があり、モバイルウォレットがいいのではないか、と考え、3つのウォレットの検証を行いました。

ウォレットの種類	カストディアルか？	メリット	デメリット
Muun	セルフカストディアル	・特別な操作なしでLightning Network上の残高をBTCオンチェーン上のアドレスに送れる・LN決済の手数料が安い	・Invoiceにメモを書けない
Blue	カストディアル	・Muunよりは操作が楽	・オンチェーンのBTC変換にZigZagというサービスを使う必要があり面倒
Breez	カストディアル	・UIは優れている	・TestFlightなので継続的に使うには微妙・ブロックチェーンデータをSPVで同期させる必要がある

お店では、受け取ったLightning Network上の残高がまとまってきたら、日本円に変えるため、取引所へオンチェーンで送金するオペレーションが発生します。

この際、Lightning Network上の残高を特別な操作なしでBTCオンチェーン上のアドレスに送れたらすごく楽です。

デメリットの「Invoiceにメモを書けない」という点に関しては、お店でのオペレーションでInvoiceにメモを書くのが不要なためTwo Dogsさんに使ってもらう分には問題となりませんでした。

このことから、Muunをお店で使うウォレットとして推薦することにしました。

Muunの取扱説明書を作成し、Two Dogs Taproomさんへ事前に説明しました。（以下のスライドは8ページ中の1枚）

説明の際の来店時に食事もしたので、実際に予行演習としてLN決済もして、受取の操作をお店の方に体験していただきました。

当日の様子

当日の様子は弊社広報記事もご覧いただくとして、参加者側で使用していたLNのモバイルウォレットは以下が確認できました。

Nayuta Core
Wallet of Satoshi
BlueWallet
Muun

サラダと前菜

Two Dogs名物のPizza！！

自分がLN決済で、Muunウォレットを使用して、自家製チョコレートブラウニーとアイスクリーム(600円)を買うところ。
当日のレートで16,068satsでした。

自家製チョコレートブラウニーはお店での手作りでとても美味しいです！

Diamond Handsが開発したLighting Networkでsatsがもらえるくじも参加者の皆さんに楽しんでいただけました。

レジェンドも初めましての方も交流でき、とても楽しい会になりました！

振り返り

イベント終了の後日、参加者とTwo Dogsさんにアンケートを書いていただきました。

アンケート

参加者

イベントにはどのくらい満足されましたか。(10段階で10が最も満足度が高い) (n=8)
- 8 : 3件
- 9 : 1件
- 10:4件
- 平均 : 9.125
事前の参加費をLNで支払った際のウォレットの種類をお聞かせください (n=6)
- Blue: 3件
- Breez: 1件
- Umbrel: 1件
- Wallet of satoshi: 1件
事前の参加費支払いはうまくいきましたか？ (n=6)
- はい: 6件(100%)
当日お店でLN決済をしましたか？ (n=8)
- はい: 1件
- いいえ: 7件
(LN決済した方)使用したウォレットの種類をお聞かせください (n=1)
- Nayuta Core
(LN決済した方)お店で何を買いましたか？ (n=1)
- ピクルスとデザート
(LN決済した方)覚えていれば購入金額を教えてください (n=1)
- 1200 JPY
(LN決済した方は)お店でのLN決済はうまくいきましたか？ (n=1)
- いいえ
「いいえ」とお答えいただいた場合、どのような問題が発生しましたか？
- Payment is in transitionエラーで成功したか失敗したかわからなかった。実際には成功していた。成功したら新しいInvoiceがアラートなしで発行される仕様だったらしく、二重送信された。
Lightningくじは引きましたか？ (n=2)
- はい : 2件
(LNくじを引いた方)くじの操作はうまくいきましたか？ (n=2)
- いいえ：2件
(いいえとお答えされた方)どんな問題が発生しましたか？ (n=2)
- LNURLに対応していないウォレットを使用した
- くじに当たった後のredeemができませんでした。
Lightningでの支払いを日常的にしてみたいと思いますか？ (n=2)
- はい (n=2)
その理由をお答えください (n=2)
- せっかくチャネルを持っているので。
- 自由でプライバシーがあり速いので
なぜイベントに参加されましたか？(複数選択可能) (n=8)
- 面白そうだったから: 7
- LN決済をしてみたかったから: 0
- 知り合いに誘われたから: 4
- ネットワーキング: 2
イベント全体で感想があればお書きください。(n=4)
- ビールとピザおいしかったです。
- 有意義でした
- Lightning決済を始めて経験でき、久しぶりの方々ともお話しでき有益でした。
- 楽しかったです。ぜひまた開催お願いします。同じ場所ならもう少し人数少ない方が嬉しいです。
セッションの内容で感想があればお聞かせください。(n=2)
- 主催者、スピーカー、スポンサーに感謝です
- Lightningエコシステムが着実に成長していることを実感できました。

Two Dogs Taproomさん

無回答の項目は省いています。

Lightning Networkでの決済受付はBitcoinでの決済に比べて面倒だったでしょうか？
- 面倒だった
(面倒だった場合)どのような点が面倒だったでしょうか？
- ライトニング決済をデフォルトにしてほしい。通貨をデフォルトにしてほしい。もしくは設定を保存できるようにしてほしい。
継続してLightning Network決済を受け付けたいと思いましたか？
- しばらく様子を見てから決めたい
Lightning Networkくじの操作方法はご理解いただけましたでしょうか？
- 理解できた
今後もLightningくじを設置したいと思いますか？
- しばらく様子を見てから考えたい

反省点

今回は技術検証も兼ねているので、くじを全員に引いてもらい、全員にLN決済をしてもらえばよかった
検証のため、アンケートには全員に回答してもらえるよう、答えた方へのインセンティブ(少額のsatsなど)を用意すればよかった
会場のキャパシティに対し、人数が多く狭かった
Two Dogsさんに使ってもらったMuunは操作が煩雑なようなので、UI/UXが優れたモバイルウォレットの発掘を行いたい
- 今後、弊社でLNをはじめとする最新技術を使ったプロダクトを開発する上でも気にしていきたい

得られた知見・課題

UmbrelなどセルフホスティングのシステムはLANケーブルを繋いで運用する
ユーザは支払いが成功したか失敗したかわからないPayment is in transitionの状態になるリスクを知っておき、発生した場合の対処は支払い者と受取者で合意する必要がある
開発時にはPayment is in transitionの状態になりにくく、なったとしても状態の解消が早くできるように実装する
Lightning NetworkシステムはLNそのものだけでなく、構築・使用するシステムの可用性を担保したり、わかりやすく手順の少ないUI/UXを提供する必要がある