LNDのremote CSV delayのデフォルト値について
LNDでチャネルの強制閉鎖をした時の資金回収にかかる遅延時間のメモ。 自身でチャネルを強制閉鎖した場合、自身の資金回収にはある一定時間経過後にしか回収できません。その遅延時間の設定は、チャネル開設をした相手のLNDノードが指定するdefaultremotedelayという値で決まります。LNでは144ブロック（約1日）がデファクトスタンダードかなと思っていましたが、LNDの仕様を読むと、remotedelayの設定を明示的にしない場合、チャネルサイズに応じて遅延時間が調整されるとのことでした。 // We scale the remote CSV delay (the time the // remote have to claim funds in case of a unilateral // close) linearly from minRemoteDelay blocks // for small channels, to maxRemoteDelay blocks // for channels of size MaxFundingAmount. （引用元はこちら） その調整式は以下の通りです。 maxRemoteDelay * chanAmt / MaxFundingAmount maxRemoteDelayは2016、MaxFundingAmountは0.16777216なので、chanAmt（チャネルサイズ）が0.1BTCの場合、遅延時間は約1201ブロック（約8日）となります。
LNノードのバックアップ＆リストア考察
Lightning Networkのノード運用をする場合、特に重要なのがバックアップです。オンチェーン上のビットコインのバックアップは秘密鍵を保管しておくだけで良いですが、LNのノード運用をする場合は少し特殊です。LNノードのバックアップは大きく2つに区別することができます。それは①オンチェーン資金のバックアップと②オフチェーン資金のバックアップです。①のバックアップは秘密鍵の保管をするだけで問題ありません。②のオフチェーン資金のバックアップとは、チャネルのバックアップです。LN上のチャネルは送受信がある度にチャネル状態が更新されていくので、その都度バックアップをとる必要があります。もし古いチャネル状態で相手と通信をすると、不正な状態と見なされ、最悪の場合、資金を失うかもしれません。 data loss protection そのような場合を考慮して、LNの仕様書では data loss protection （DLP）と呼ばれる安全装置が付いています（02-peer-protocol）。これは、もしアリスのチャネル状態が5で、ボブのチャネル状態が6だった場合、アリスのチャネルは古い状態なので、ボブにチャネルを強制閉鎖することを依頼できる仕組みです。この依頼を受けたボブが取れる行動は、(a)最新のチャネル状態6で強制閉鎖するか、(b)古いチャネル状態、例えば自分の残高が多くなるようなチャネル状態まで遡り、そのチャネル状態で強制閉鎖することが考えられます。ボブが(b)の選択をしても、もしアリスが嘘を付いていて最新のチャネル状態までデータを保持していると、ボブはペナルティとして、アリスに全額没収されてしまいます。そのため、ボブは(a)の正直な選択を取ったほうが無難なのです。これが data loss protection と呼ばれる仕組みで、ゲーム理論的な側面があります。この仕様は各LNソフトウェアに実装されています。 またLNDでは、static channel backup（SCB）と呼ばれるチャネル開設がある度に取得するバックアップがあります。これは、最初のチャネル状態だけをバックアップして、リストア時にSCBからチャネル状態を復元しようとするとチャネル状態が古いので、DLPによってチャネルの強制閉鎖を相手に依頼するというものです。このSCBはLNDのみ実装されており、c-lightningやEclair coreには実装されていません。LNのバックアップでは秘密鍵以外にも②のチャネルのバックアップも必要でした。一見するとこのSCBは必須な気がしますが（実際コミュニティでも議論されている<a href="https://github.c
