-
@ tanakei
2025-04-29 04:04:19Umbrel Core-lightning(以下CLNと略す)を運用するにあたり役に立ちそうなノウハウやメモを随時投稿します。
・configファイルを用意する Umbrelのアプリとして必要な設定はdocker-compose.ymlで指定されている。 それ以外の設定をしたい場合configファイルに入れると便利。 configファイルの置き場所は /home/umbrel/umbrel/app-data/core-lightning/data/lightningd ここにtouch configとでもやってファイルをつくる。
cd /home/umbrel/umbrel/app-data/core-lightning/data/lightningd touch config以下内容をひな型として使ってみてください。 行頭に#があるとコメント行になります。つまり.iniフォーマット。 /home/umbrel/umbrel/app-data/core-lightning/data/lightningd/config ```[General options]
[Bitcoin control options]
[Lightning daemon options]
[Lightning node customization options]
[Lightning channel and HTLC options]
[Payment control options]
[Networking options]
[Lightning Plugins]
[Experimental Options]
``` configに設定できる内容は以下を参照 https://lightning.readthedocs.io/lightningd-config.5.html セクションを意味する[]があるけれどもこれは私(tanakei)が意図的に見やすく区別しやすくするために付けただけ。これら行の＃は外さない。
・configの設定をCLNに反映させる appスクリプトでCLNを再起動すると反映することができる。 configを書き換えただけでは反映されない。
cd /home/umbrel/umbrel/scripts ./app restart core-lightning・ログをファイルに出力させる
以下の場所でtouch log.txtとしてlog.txtファイルを作る。 /home/umbrel/umbrel/app-data/core-lightning/data/lightningd
cd /home/umbrel/umbrel/app-data/core-lightning/data/lightningd touch log.txt次にconfigの[Lightning daemon options]セクションにlog-fileを追加する。 ```[Lightning daemon options]
log-file=/data/.lightning/log.txt ``` ※Dockerによって/home/umbrel/umbrel/app-data/core-lightning/data/lightningd は /data/.lightning として使われている。
・addrとbind-addrの違い どちらも着信用のインターフェースとポートの設定。addrは指定したホストIPアドレス:ポート番号をノードURIに含めて公開する(node_announcementのuris)。bind-addrは公開しない。
・実験的機能のLN Offerを有効にする configの[Experimental Options]セクションに以下を追加する。 ```
[Experimental Options]
experimental-onion-messages experimental-offers ``` ※ v24.08でexperimental-onion-messageは廃止されデフォルト有効であり、上記設定の追加は不要になりました。 ※ v21.11.1 では experimental-offersは廃止されデフォルト有効であり、上記設定の追加は不要になりました。 もう実験扱いじゃなくなったのね...
・完全にTorでの発信オンリーにする UmbrelはなぜかCLNの発信をClearnetとTorのハイブリッドを許している。それは always-use-proxy=true の設定がないから。(LNDは発着信Torのみなのに) なのでこの設定をconfigに追加してCLNも発着進Torのみにする。 ```
[Networking options]
always-use-proxy=true ```
・任意のニーモニックからhsm_secretを作る CLNのhsm_secretはLNDのwallet.dbのようなもの。ノードで使う様々な鍵のマスター鍵となる。Umbrel CLNはこのhsm_secretファイルを自動生成したものを使い、これをバックアップするためのニーモニックを表示するとかそういう機能はない。自分で作って控えてあるニーモニックでhsm_secretを作ってしまえばこのファイルが壊れてもオンチェーン資金は復旧はできる。
1.CLNインストール後、dockerコンテナに入る
docker exec -it core-lightning_lightningd_1 bash2.lightning-hsmtoolコマンドを使って独自hsm_secretを作る ``` cd data/.lightning/bitcoin lightning-hsmtool generatehsm my-hsm_secret・上記コマンドを実行するとニーモニックの言語、ニーモニック、パスフレーズの入力を催促される。 Select your language: 0) English (en) 1) Spanish (es) 2) French (fr) 3) Italian (it) 4) Japanese (jp) 5) Chinese Simplified (zhs) 6) Chinese Traditional (zht) Select [0-7]: 0 ※定番の英単語なら0を入力 Introduce your BIP39 word list separated by space (at least 12 words): <ニーモニックを入力する> Warning: remember that different passphrases yield different bitcoin wallets. If left empty, no password is used (echo is disabled). Enter your passphrase: <パスフレーズを入力する> ※パスフレーズ不要ならそのままエンターキーを押す。 New hsm_secret file created at my-hsm_secret Use the
encryptcommand to encrypt the BIP32 seed if neededコンテナから抜ける exit
3.appスクリプトでCLNを止めて、独自hsm_secret以外を削除 ※【重要】いままで使っていたhsm_secretを削除する。もしチャネル残高、ウォレット残高があるならチャネルを閉じて資金を退避すること。自己責任！cd ~/umbrel/scripts/ ./app stop core-lightningcd ~/umbrel/app-data/core-lightning/data/lightningd/bitcoin rm gossip_store hsm_secret lightningd.sqlite3 lightning-rpc mv my-hsm_secret hsm_secret
4.appスクリプトでCLNを再開するcd ~/umbrel/scripts/ ./app start core-lightning ```【補記】 hsm_secret作成につかうニーモニックはBIP39で、LNDのAezeedと違って自分が作成されたブロック高さというものを含んでいない。新規でなくて復元して使う場合は作成されたブロック高さからブロックチェーンをrescanする必要がある。 configの１行目にrescanオプションを付けてCLNをリスタートする。 ``` // 特定のブロック高さを指定する場合はマイナス記号をつける rescan=-756000
// 現在のブロック高さから指定ブロック分さかのぼった高さからrescanする rescan=10000 ※現在の高さが760,000なら10000指定だと750,000からrescan ```
・clnrestについて core-lightningでREST APIを利用したい場合、別途c-lightning-restを用意する必要があった。v23.8から標準でclnrestというプラグインがついてくる。pythonで書かれていて、ソースからビルドした場合はビルド完了後にpip installでインストールする。elementsproject/lightningdのDockerイメージではインストール済みになっている。 (v25.02からgithubからバイナリをダウンロードしてきた場合はpip install不要になったようだ) このclnrestを使うにはcreaterunesコマンドでruneというLNDのマカロンのようなものを作成する必要がある。アプリ側でこのruneとREST APIを叩いてcore-lightningへアクセスすることになる。 自分が良く使っているLNbitsやスマホアプリZeus walletはclnrestを使う。まだclnrestに対応していないアプリもあるので留意されたし。
・Emergency recoverについて LNDのSCBのようなもの。ファイル名はemergency.recover チャネルを開くと更新される。 hsm_secretとこのファイルだけを置いてCLNを開始すると自動でこのファイルから強制クローズするための情報が読み出されてDLPで相手から強制クローズするような仕組み。この機能はv0.12から使える。
動作確認してみた所、LNDのSCBに比べるとかなり使いづらい。 1. CLNがTor発信だとチャネルパートナーと接続できない。 Clearnet発信できても相手がTorのみノードならTor発信せざるを得ない。 相手と通信できなければ資金回収できない。 2. 相手がLNDだとなぜか強制クローズされない。相手がCLNならできる。
つまり、自分と相手がClearnetノードでかつ相手もCLNならば Emergency recoverで強制クローズして資金回収できる。こんな条件の厳しい復旧方法がマジで役に立つのか？
v0.11以降ならばLNDのchannel.dbに相当するlightningd.sqlite3をプライマリ・セカンダリDBと冗長化できるので、セカンダリDBをNFSで保存すればUmbrelのストレージが壊れてもセカンダリDBで復旧できる。そのためemergerncy.recoverを使う必要がないと思われる。
・LN offer(BOLT#12)ついて 使いたいなら 1.publicチャネルを開く publicチャネルを開けばチャネルとノードの情報(channel_announcement, node_announcement)が他ノードに伝わる。送金したい相手がこの情報を元に経路探索する。 2.その後しばらく待つ CLNノードを立てたばかりだと経路探索するに十分なチャネルとノードの情報が揃ってない。せめて1日は待つ。
LNURLの場合インボイスをhttpsで取得するが、OfferはLN経由で取得する。そのためにチャネルとノードの情報が必要。privateチャネルばかりのノードはチャネル情報もそうだがノード情報も出さない。 Offerで使えるBlind pathという機能なら中間ノードIDを宛先ノードとすることが可能で、これならチャネルとノード情報を公開しなくても受けとれるのだがCLNは対応してない模様(2025年1月現在) CLNでOfferで受け取るにはチャネルとノード情報を公開する必要がある。そのためpublicチャネルを開く。公開されていれば良いのでTorでもOK。クリアネットで待ち受けは必須ではない。
・hsm_sercretとニーモニック lightning-hsmtoolを使うとニーモニックからhsm_secretを作れる。ニーモニックからシードを作ると64バイト。これはニーモニックおよびソルトにパスフレーズをPBKDF2(HMAC-SHA512を2048回)にかけると512ビット(64バイト)のシードができる。しかしhsm_secretは32バイト。CLNでは64バイトの最初の32バイトをhsm_secretとして利用しているみたい。 このhsm_secretにHMAC-SHA512をかけて512ビットとした値がウォレットのマスター鍵となる。なのでhsm_secret自体がBIP-32でいうマスターシードそのものではない。 sparrow walletにCLNのウォレットを復元したい場合は lightning-hsmtool dumponchaindescriptors --show-secrets
とやってディスクリプターウォレットを出力。出力内容にマスター鍵(xprv～)があるので、これをインポートする。導出パス設定はm/0とする。sparrowが残りを補完してm/0/0/0, m/0/0/1とやってくれる。 <おまけ> configファイルのサンプル。Umbrelを使わない場合は以下のサンプルが役に立つはず。上記のelementsproject/lightningdならば/root/.lightningに任意のディレクトリをマウントしてそのディレクトリにconfigを置く。 ```
[General options]
不可逆なDBアップグレードを許可しない
database-upgrade=false
[Bitcoin control options]
network=bitcoin bitcoin-rpcconnect=
bitcoin-rpcport= bitcoin-rpcuser= bitcoin-rpcpassword= [Lightning daemon options]
postgresを使う場合
wallet=postgres://USER:PASSWORD@HOST:PORT/DB_NAME
bookkeeper-db=postgres://USER:PASSWORD@HOST:PORT/DB_NAME
sqlite3を使う場合。デフォルトはこちらで以下の設定が無くても~/.lightning/bitconに自動で作成される。
wallet=sqlite3:///home/USERNAME/.lightning/bitcoin/lightningd.sqlite3
bookkeeper-db=sqlite3:///home/USERNAME/.lightning/bitcoin/accounts.sqlite3
ログファイルは自動で作成されない
log-file=/home/USERNAME/.lightning/lightningd-log
log-level=debug
[Lightning node customization options]
alias=
rgb= 固定手数料。ミリサトシで指定。
fee-base=1000000
変動手数料。ppmで指定。
fee-per-satoshi=0
最小チャネルキャパシティ(sats)
min-capacity-sat=100000
HTLC最少額。ミリサトシで指定。
htlc-minimum-msat=1000
[Lightning channel and HTLC options]
large-channels # v23.11よりデフォルトでラージチャネルが有効。
チャネル開設まで6承認
funding-confirms=6
着信できるHTLCの数。開いたら変更できない。1～483 (デフォルトは 30) の範囲にする必要があります
max-concurrent-htlcs=INTEGER
アンカーチャネルを閉じるためにウォレットに保持しておく資金。デフォルトは 25,000sat
チャネルを"忘れる(forget)"するまではリザーブされる模様。forgetはチャネル閉じてから100ブロック後
min-emergency-msat=10000000
[Cleanup control options]
autoclean-cycle=3600 autoclean-succeededforwards-age=0 autoclean-failedforwards-age=0 autoclean-succeededpays-age=0 autoclean-failedpays-age=0 autoclean-paidinvoices-age=0 autoclean-expiredinvoices-age=0
[Payment control options]
disable-mpp
[Networking options]
bind-addrだとアナウンスしない。
bind-addr=0.0.0.0:9375
tor
proxy=
: always-use-proxy=true Torの制御ポート。addr=statictor だとhidden serviceをノードURIとして公開する。
addr=statictor:
: tor-service-password= experimental-websocket-portは廃止された。bind-addr=ws:が代替。
bind-addr=ws:
:2106 clnrestプラグイン, REST API
clnrest-host=0.0.0.0 clnrest-port=3010 clnrest-protocol=http
v24.11よりgrpcはデフォルト有効
grpc-host=0.0.0.0 grpc-port=9736
[Lightning Plugins]
[Experimental Options]
experimental-onion-messages # v24.08で廃止。デフォルト有効
experimental-offers # v24.11.1で廃止。デフォルト有効
流動性広告からチャネルを開くときにexperimental-dual-fundが必要らしい。
experimental-dual-fund
experimental-splicing
experimental-peer-storage
```