Yuya

Yuya

@ogw_yuya

ちょビットコイナー

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ノードのバックアップ&リストア考察

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

オリンピックに興味がない

新約・興味がないシリーズ 第1弾。 以前別のところで書いていたシリーズなんですがこの「興味がないシリーズ」、しばらく休眠状態だったシリーズを今回Spotlightで復活させることにしました。いつまで続くかは知りません。復活第1回目のテーマはオリンピックです。 そもそも興味がないシリーズの趣旨説明だけしますと、「人はだれしもブログ記事などを書く時には自分の興味のある事柄を書こうとするが、それではネタが限られてしまう。自分の興味のないことについて書けばネタは無尽蔵だ。なぜなら世の中は自分の興味のある事より興味のない事のほうが圧倒的に多いから」というアイデアのもとに始めたわけです。しかしめんどくさくなって途中で放棄しました。今でも文章自体は残ってると思うけど。 さて、本題のオリンピックですが、別にこのシリーズは本題に入っても入らなくてもいいんですけどね、なぜなら興味がないから。それはともかくSpotlightの皆さんの最近の記事一覧をざっと見る限りは、Spotlight民は誰もオリンピックに興味なさそうですね。オリンピックどころかコロナもワクチンも紀州のドンファンも全部興味なさそうな雰囲気すらしています。

Emanon purchased this article w1tst6g5o

10000

Purchased this article qw95rvz3l

-1980

森山 瞳 / Nayuta ⚡ purchased this article ioznupn2j

100

toshihr purchased this article p5bkaovrb

100

Purchased this article l6lqfauua

-300

Purchased this article 7guhcd2rx

-100

sutadonman purchased this article o38b3zme7

100

Ky purchased this article p5bkaovrb

100

Culi-zusi purchased this article p5bkaovrb

100

森山 瞳 / Nayuta ⚡ purchased this article p5bkaovrb

100

btc_dakara purchased this article p5bkaovrb

100

Tanakei purchased this article p5bkaovrb

100

まいたけにまいったけ purchased this article gfp1tn2fd

1000

Tanakei purchased this article ox4otb9tk

10000

Purchased this article nbous95u0

-1000

kan purchased this article ioznupn2j

100

ロクヨウ purchased this article ioznupn2j

100

katakoto purchased this article ioznupn2j

100

ひ゜ purchased this article vaal4lvtp

1000

ひ゜ purchased this article 3gt0psvnq

2000

Popular stories

LNノードの運用益はどれぐらい?パート1

1189

LNノードの運用益はどれぐらい?パート3

659

猫でも分かるLightning Network解説!

592

Archives

2021-08
1posts
2021-07
9posts
2021-06
2posts
2021-05
4posts
2021-04
9posts
2021-03
11posts
2021-02
5posts
2021-01
4posts
2020-12
8posts
2020-10
2posts
2020-09
20posts
2020-08
4posts
2020-07
5posts
2020-06
10posts
2020-05
7posts
2020-04
10posts
2020-03
3posts
2020-02
3posts
2020-01
6posts
2019-12
6posts
2019-11
5posts
2019-09
1posts
2019-08
1posts
2019-07
1posts
2019-05
4posts
2019-04
7posts
2019-03
4posts
2019-02
5posts