チャネルバックアップなしでLNの資金をオンチェーンへ回収する方法 [Umbrel対応]

Lightning Networkのノードを運用していて、ディスク障害などでサーバーの復旧をする際、オンチェーン資金はシード（秘密鍵）から復旧できますが、オフチェーン資金はチャネルバックアップなどを使って復旧する必要があることは以前の記事で何度か紹介しました。チャネルバックアップ（LNDの場合、Static Channel Backup、SCBと呼ばれるもの）がない場合は、相手ノードへチャネルの強制閉鎖を要求してチャネルを閉じることで資金を復旧できます。ただし、チャネルの強制閉鎖後に、こちら側でもある手順を踏む必要がり、その手順はあまり知られていません。今回はその手順を紹介したいと思います。 今回使うツールは以下で、LNDのみ対応しています。c-lightningでの復旧方法はこちらを参照ください。 ・・・ 最初にチャネルの相手方へチャネルの強制閉鎖を依頼します。その後、自身のUmbrelの復旧をしましょう。復旧手順はUmbrelを再構築してセットアップ時にバックアップしていた24個のシードを入力することで復旧できます。 次にUmbrelへSSHログインをします（<a href="detail?article_id=zvxudpp25

流れ星を眺めながらジョギングをする

ここ１、２か月、心身ともに調子が良くなかった（というよりはどちらかというと老年になってきた？）のですが、最近涼しくなってきたので、今日久しぶりに20キロジョグをしてみました。ハーフを走るのは今年３月に走った名古屋シティマラソン以来でしたが、夜中ということもあって、快調に走ることができました。これまで10キロでもバテバテだったけど、やっぱり涼しくなるだけで身体への影響は違います。 走るコースは地元の河川敷を走るのですが、名古屋の街中でも星は結構見えます。最近は月を見ながら走っていましたが、だんだん月の出が遅くなってきて、今日は走っていた23時30分ごろでもまだ月が出ていませんでした。星は綺麗に見えるけど、月が見えないのはちょっと寂しいなと思いつつ走っていた時でした。なんと、自分が走っている前方上空を、橙色に光る星が夜空を駆けていき、颯爽と僕を追い越し消えていったのです。一瞬の出来事でしたが、流れ星の余韻が残るほど、まぎれもない流れ星でした。流れ星を眺めながらジョギングができ風情な一日となりました。 実は今年の１１月末に人生初となるフルマラソンを走る予定で、出場するのは「富士山マラソン」です。富士山の絶景を見渡しながら走れるということでとても楽しみ。サブ4は切れると思うので、サブ3.5を目標にしたいと思います。

秘密鍵の保存だけで👌 ElectrumのRecoverable channelsとは

以前の記事で、LNノードを運用する上でのバックアップについて紹介しました。そこでは、オンチェーン資金のバックアップは秘密鍵の保管を、オフチェーン資金のバックアップでは、UmbrelやmyNodeなどLNDを使ってる場合はStatic Channel Backupと呼ばれるファイルをチャネルの開設ごとにバックアップする必要がありました。オンチェーン資金のバックアップは一度限りで良いですが、LNのチャネル上にあるオフチェーン資金は秘密鍵とは別にチャネル開設ごとに取得する必要があるので、結構手間がかかります。できれば秘密鍵に集約したいですよね。そんな悩みを解消してくれるのがElectrumのRecoverable channelsです。 Electrumはビットコインウォレットの老舗ですが、去年ごろからライトニングネットワークをサポートしました。そのElectrumが実装したRecoverable channelsとは、チャネルバックアップをチャネル開設時のトランザクションに書き込むというものです。こうすることで、ユーザーはチャネルバックアップをする必要はなく、秘密鍵さえ保管しておけばいいのです。もしLNノードやウォレットが壊れたりしたら、秘密鍵からオンチェーン資金を復旧し、また、オフチェーン資金の復旧に必要なチャネルバックアップは、ブロックチェーンから読み取り、その情報を使って復旧することができます。 Recoverable channelsの欠点は、チャネル開設時のデータサイズが大きくなるので手数料が通常以上にかかるります。また、ブロックチェーンに書き込んでいるのでチャネル開設時の相手にチャネルバックアップをしていることが知られてしまいます（バックアップデータ自体は暗号化されているので内容は分からない）。以前の記事でも触れましたが、このStatic Channel Backupはある一定の信頼があるので、もし相手にSCBから復旧しようしていることが知られると不正をされる場合があります。とは言え、実践的にはこのような不正はほぼありえないと思いますし、ユーザーは秘密鍵の保管だけで良いので、よりLNが使いやすくなりそうです。 ElectrumのRecoverable channelsについては以下のリリースノートおよびコードベースを参照してみください。 <iframe allowfullscreen="allowfullscreen" allow="autoplay *; encrypted-media *" src="//cdn.iframe.ly/

LNノードのルーティングエラーによる機会損失について

チャネル、ホップ、オニオン、ゴシップ！

ライトニングネットワークはビットコインの上で動くセカンドレイヤー技術で、低手数料、高速送金を実現することができます。ライトニングネットワーク（以下、LNと称す）では大きく分けて以下の二つの技術で構成されています。 ペイメントチャネル マルチホップペイメント ペイメントチャネル ペイメントチャネルでは、2者間でマルチシグアドレスを生成し、そのアドレス上でお互いの残高を管理していきます。残高の更新があるたびに署名をしますが、この署名されたデータはブロックチェーンへ送信せず、お互いのウォレット内で保管します。こうすることで、2者間で送金があってもブロックチェーンへ送信しないので、ゼロ承認かつゼロ手数料での送金ができるわけです。このマルチシグアドレス上での残高管理・送受信を仮想的なトンネルと見立てたものをペイメントチャネルと呼びます。 ペイメントチャネルは2者間での送金を可能にする技術ですが、もし第3者へ送金したい場合、その第3者ともチャネルを作らないといけないのでしょうか。送金したい相手ごとに作成する必要があるととても不便です。その問題を解決する技術がマルチホップペイメントと呼ばれるものです。 マルチホップペイメント マルチホップペイメントでは、ビットコインのスマートコントラクトを活用することで、中継者を経由して第3者へ、トラストレスに送金をすることができます。例えばアリスとボブ、ボブとキャロルの間にペイメントチャネルがある場合を見てみます（下記の図を参照）。この時、アリスはボブを経由してキャロルへ送金をすることができるのですが、ここでアリスがボブへ送金してもボブはキャロルへその送金を中継しない場合が考えられます。これだと既存の銀行間送金のような第三者への信頼モデルになってしまいます。そこでアリスはボブへの送金時に「キャロルしか知りえないシークレットがあれば受け取れる」という制約をつけて送金をします。ボブはこの送金を受け取るにはキャロルへシークレットを貰わないといけないので、同様な制約をつけてキャロルへ送金をします。キャロルはこの送金を受け取るためにシークレットをボブへ渡します。そしてボブはアリスからの送金を受け取るためにこのシークレットをアリスへ渡し、送金を受け取ります。 こ

永遠の門 ゴッホの見た未来

永遠の門見てるけど、めちゃくちゃ面白い！ 画家についての映画だと「セザンヌと過ごした時間」も有名だけど、これはまだ見ていない。内容は小説「居酒屋」などの代表作をもつ作家のゾラと近代絵画の父セザンヌにまつわる友情の話だったと思うけど、こちらもぜひ見てみたい一作です。

ライフゲームの平面性と時限性

カミーユ・ピサロ

52756e6e696e6720626974636f696e

ビットコインのブロックチェーンに任意文字を書き込めるのは意外と知られていると思います。送金データにOP_RETURNというOPコードを付与することで、任意文字をブロックチェーンへ書き込むことができます。 実はライトニングネットワークでも送金データに任意文字を付与できるのをご存知でしょうか？LN上のP2Pチャットアプリ「SphinxChat」はこの仕組みを応用して送金データに文字列を付与して少額送金することで、チャットを実現させています。任意文字を埋め込むために使われる仕組みはTLV（Type Length Value）と呼ばれるデータフォーマットで、このフォーマットでオニオンメッセージ（データのカプセル化）を作って通信相手に送信することで、予め指定された型番号（Type）をデコードすることでメッセージを読み取ることができます。任意メッセージのTypeは34349334となっています（c-lightning, LND）。 LNノードのログを解析していたら本日付で以下のようなデータが送金データと一緒に送られていたことに気付きました。メッセージを書き込むためのTypeは34349334でした。そのTypeに対するValueを変換することでメッセージが読めるようになりますが、、、 "custom_records": { "34349334": "52756e6e696e6720626974636f696e", "34349337": "72797270376464756b39786d6b6334336a63396a6e6338676833706f6d6a6b74347966753778726a39356763746534387368737a6363756e347471636965626d77736237347839707231703735653674726a336a6e396139367333646768636b35357374636a3939", "34349339": "0387be05e3549387cc3bc546def54d4fe1630358528316826c301853a67355fa14", "34349340": "4879706572426974636f696e697a6174696f6e", "34349345": "74657874", "34349347": "74657874", "5482373484": "af5d8c79f58a5912dfc8372d7b9d1efa

LNDの備忘録

以下の内容はあまり読んで欲しくないので、絶対に購入しないでください。

SSHトンネルでリモート接続

LNDのニュートリノモードはビットコインフルノードなしに手軽にライトニングを始めるには便利です。しかしニュートリノだと欲しいデータ、具体的にはlncli describegraphによるネットワーク上の全てのチャンネルやノード情報が取得できません。そこで、今回はVPSサービスのbitcloudsでbitcoindのインスタンスを購入し、LNDからbitcoindへリモート接続することで、ニュートリノモードからフルノードモードへ切り替えてみました。フルノードモードでLNDを稼動することで、上記のネットワーク情報がすべて取得できるようになります。 bitcoindへリモート接続する場合、RPCポートを公開すればリモート接続が可能ですが、そのままでは暗号化されておらず安全性にかけます。また今回接続するbitcoindはVPS内のローカルエリアにあるため、ちょっとした工夫が必要です。 そこで今回はSSHトンネル（ローカルポートフォワード）でLNDからVPS上のbitcoindへリモート接続してブロックデータなどを取得してみました。以下は簡単な環境図です SSHトンネル接続 まずはbitcloudsでbitcoindインスタンスを購入し、SSHでログインします。インスタンス購入からSSHログインまではこちらの記事を参照してください。SSHログインできたら、$ bitcoin-cli stopでデーモンを停止します。停止したら、bitcoin.confを以下のように修正して、再度$ bitcoindで起動します。rpcconnectはデフォルトでIPが指定されているので、そのままで。ユーザー名・パスワードもデフォルト値のままで大丈夫です。 mainnet=1 server=1 daemon=1 rpcconnect=192.168.3.7 // local ip address rpcuser=hogehoge // username rpcpassword=gehogeho // password [main] rpcallowip=0.0.0.0/0 rpcbind=0.0.0.0 その後、ログアウトして、LNDのマシン上からSSHトンネルのコマンドを以下のようにして実行します。-Lはローカルへの通信をリモートにバインドするためのオプションです。8332:192.168.3.7:8332はロ

LNDのWatchTowerを検証してみた