LNDのWatchTowerを検証してみた

Bitcoin Sign Guy は実在していた

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日）となります。

UmbrelをBitcloudsでお試しする

HTLCで送金できる最小金額の考察

安全な送金 Lightning Networkでは1円以下の送金も可能ですが、ある金額以下の送金は実は安全ではないのをご存知でしょうか。ここでは安全の定義をHTLC（Hash Time Lock Contract）と呼ばれるスマートコントラクトを使った送金とします。このコントラクトを使うと、複数のノードを経由し、ブロックチェーンへの書き込みをせずにビットコインの送金が可能となります。 しかし、このHTLCを使った送金には最低金額があり、この金額以下ではHTLCを使った送金はできません。そもそもHTLCはコインをロックしたスクリプトで、LN上での送金中に問題が生じた時、このHTLCをブロックチェーン上へ展開して資金の回収をします。ビットコインにはdust limitという送金可能な最小金額があり、この値は（Native Segwitの場合）294satsとなっています。そのため、LN上でHTLCを使った送金もこの金額以上である必要があります。 LN上でこのdust limit以下で送金する場合、HTLCは使えないのでどうするかと言うと、この金額以下はマイナーのトランザクション手数料とみなして送金されます。LN上での送金が正常に完了すれば、dust limit以下の金額は自身の残高に反映されます。もし、送金が失敗してブロックチェーン上へ展開されると、このコインはマイナーへの手数料として勘定されます。これについてはこちらの記事で紹介しているので読んでみてください。HTLCはdust limit以下では使えませんが、これ以上の金額であれば問題ないのでしょうか。実は、dust limit以上の送金でもHTLCが使えない場合があります。 HTLCの最小金額 LNではcommitment_txと呼ばれるビットコインの取引データを2者間で署名・交換することでブロックチェーン外で送金を行います。commitment_txのアウトプットには自身へのアドレスを指すto_localと相手のアドレスを指すto_remoteがあり、この各アウトプットへのコインの量を更新していくことで、お互いの残高を管理しています。例えばアリスからボブを経由してキャロルへ送金する場合、commitment_txのアウトプットにHTLCを追加することになります。この時、dust limit以下の送金であれば、HTLCが追加されることはなく、その金額はcommitment_txがブロックチェーンへ展開される場合、マイナー手数料となります。 以下では送受信が同時に4つ行われている状態のcommitment_txを例にとって解説していきます（参考例元は<a href="https://github.com/lightningnetwork/lightning-rfc/blo

ライトニングネットワークは少額決済には向かない！？

はじめに ライトニングネットワーク（以下、LNと略す）発案者の１人であるDryja氏がツイッターで呟いたこの言葉、 （訳）1つのチャネル間での1サトシ決済は問題ないけど、（トランザクション手数料レベル以下での）ホップ付きHTLCは少額決済として機能しない。なんちゃって1サトシHTLCは皆を失望さてているね。 え？LNって少額決済のためじゃないの？と思ってたのですが、ど

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

Clearnet上のLNノードでTor上のノードへ接続する

最近はUmbrelによるビットコインのフルノードとライトニングノードを建てるのが流行っていてますが、Umbrelは大人の事情でTorでの運用が基本となっています。ライトニングネットワークはもともとClearnet上のIP4/6が主流でしたが、Umbrelの台頭でTor上のオニオンアドレス（.onionで終わるアドレス）ノードが頻出しています。ここで問題になるのは、ClearnetノードからTorノードへの通信ができないため、チャネル開設ができないことです。そこで、今回はClearnet上ノードからでもTorノードへチャネル開設する方法があるか調べてみました。 c-lightningのTorサポート状況 c-lightningのTorサポートは以下の表が分かりやすいです（参照元はここ）。Case #1にあるようにIPアドレスだけの場合でも、Socks Proxyを通してTor上のノードへ通信が可能です。Socks Proxyを通しての通信ができるLNノードは重要で、ClearnetとTorのゲートウェイ的な存在になります。 LNDのTorサポート状況 LNDはClearnetかTorのどちらか一方にしか現状対応していない感じでした。c-lightningのようにSocks Proxyを通してTorへ接続するハイブリッドモードは現在開発中のようです。 おまけ LNBIG.comのインバウンドチャネル開設がうまくいかないユーザーがいますが、たぶんこれもUmbrelなどのTorノードが原因だと思われます。そのため、UmbrelユーザーはLNBIGへ一度自身のノード情報を教える（というより、通信させる）ことで、Clearnet上のLNBIGがTorノードへのチャネル開設を可能にしています。

LoopによるBTC取引量

以前の記事でLoopというサービスを活用するとルーティング手数料を稼げる（！？）ことについて触れました。Loopとは、ライトニングネットワークにおけるチャネルの流動性を調整するためのサービスで、オンチェーンとオフチェーンのコインをノンカストディアルにスワップすることができます。 Loopのメリットは、自身で開設したチャネルを閉じることなくLN上のBTCをオンチェーンへ移動させることができます。LNではチャネルと呼ばれる仮想的な送金経路があり、このチャネルには容量があります。例えば、0.1BTCでチャネルを開設した場合、最大で0.1BTCしかこのチャネル間では送受信ができません。あるオンラインショップがこのチャネルを使って支払いを受け付けていると、最大で0.1BTC受け取った時点で受取ができなくなります。そこでLoopを使ってLN上のBTCをオンチェーンへ移動させることで、LN上での受取が再度可能になります。 このLoopの宣伝文句はLN決済に対応する業者への流動性調整なのですが、巷では闇があるという噂があります（笑）。それでもサービスとしては結構需要があるのですが、どれだけ需要があるか調べている人がいました。それがこちらのサイトです。調べ方としては、オンチェーンデータを解析するだけですが、これである程度Loopによる取引量が分かります。以下が上記サイトから取得したデータをグラフ化したものです。 平均して1.5BTC／日といった感じですね。LoopはLightning Labsが開発・運営するサービスなので手数料が0.5%～となります。ビットコインのオンチェーンとオフチェーンのトレードは今後需要が増えてくると思うので、そうなると手数料も自由市場に任せたほうが良さそうですね。現状だとChainmarketというカストディアルな方法によるスワップサービスでは、手数料は自由に決めることができます。今後はノンカストディアルかつ市場による手数料の決定ができるスワップサービスに期待したいですね。

正義はどこにあるか

Utreexoは中央集権的にならないか？

ビットコインの分散性を維持するためには、取引データを最小限に維持することが重要です。現在ビットコインの取引データは400GBを越え、UTXOだけでも4GBあります。 ビットコインにはフルノードとSPVと呼ばれる軽量クライアントがあります。フルノードは、さらにPrunedモードと呼ばれるUTXOだけを保持する運用も可能です。また軽量クライアントでは、フルノードと違い、全データを検証せずにブロックヘッダーのみをダウンロードし、自身に必要な取引データだけを検証することでストレージ容量を節約しています。 これまで軽量クライアントはBIP37で定義されているBloom Filterを使って各ウォレットを実装してきましたが、プライバシーが損なわれることからBitcoin Core v0.19.0以降ではBloom Filterはデフォルトでは無効となっています。Bloom Filterのデメリットは、クライアントごとにフィルターが異なるので検閲が可能となる点です。これを解決するために登場したのがBIP157,BIP158のCompact Block Filterで、これはBloom Filterとは異なり、フィルターがブロックごとに作成されるためビットコイン・ネットワークで全て同じものとなります。ただし、どちらにしても軽量クライアントはあくまでブロックヘッダーのみを保持し自身に必要な取引データのみを検証するので、全データを検証するフルノード／Prunedノードほどトラストレスではありません。 さて、ビットコインのフルノードは全データを保持するフルノードと検証したデータは捨てUTXOのみを保持するPrunedノードの2種類がありますが、これとは別なアプローチをするフルノードの提案としてUtreexoがあります。技術的な説明は割愛しますが、UtreexoはUTXOの管理・保持をマークル木ハッシュを使ったアキュムレーターで行います。これにより保持するデータ容量の大幅な削減だけでなくいくつかのメリットが生まれます。 メリット Utreexoノードは数キロバイトのデータ保持のみでよい IBDの並列処理が可能 コンセンサスアルゴリズムをデーターベースから独立できる ソフトフォークなしで実現できる デメリット IBDではネットワーク帯域が20％増加 Utreexoアーカイブノードは通常のフルノード以上のストレージが必要 ※IBDとはInitial Block Downloadの略で、最初の同期処理で行うブロックデータのダウンロードのこと Utreexoはソフトフォークなしで実現可能ですが、そのトリックはブリッジノードとよばれるノードの存在です。このブリッジノード（上記デメリットのUtreexo

祝 Taproot Locked-in

ビットコインのソフトフォークTaprootが見事ロックインされました！ taproot.watch 実際にアクティベーションされるのは11月中旬なので、ユーザーはビットコインノードのアップグレードをするのに約5ヶ月間の猶予期間があります。もちろん、ソフトフォークなので下位互換があり、現状のノードのままでも問題なく動作します。 今回のバージョンアップによるメリットと追加される技術は以下となります。 ■Taprootによるメリット - プライバシー向上- データサイズ削減 ■追加される技術 - シュノア署名- MAST- Tapscript プライバシー向上の為には多くのユーザーがTaprootアドレス（P2TR）を使ったほうが良いとされているので、各ウォレットや取引所、ライトニングネットワーク等でサポートされることが望ましいと思います。 何はともあれ、ロックインおめでとう！