[LN#019]ptarmigan(2018/04/11)

Lightning Network BOLTの概要について、書いていくシリーズ。

今回は趣向を変えて、開発中のLightning Networkノードであるptarmiganの概要を説明します。

image


https://nayutaco.github.io/ptarmigan/

ptarmigan(たーみがん、と発音)は、日本名でいえば「雷鳥」になります。
Lightning Networkなので、雷に由来しています。

GitHubで見るとC++プロジェクトのように見えてしまいますが、実際はC言語です。
これは、単体テストでgtestsを使っていて、テストデータが大量にあるためにそうなってしまいました。

C言語で作っていますが、c-lightningをベースにしているわけではなく、ライブラリを使っている箇所以外はほとんど自作しています。

また、ptarmiganは弊社が作り始めましたが、オープンソースですので、issueを上げてくださったり、Pull Requestしてくださる方を歓迎しています。
日本語でも問題ありません!
(タイトルはなるべく英語で書いてますが、中身はほぼ日本語です)


gitのbranchは development で作業しています。

developmentで、簡単に他ノードとの動作確認したあとでリリースを行っています。
この時点の最新は、2018-04-11です。
https://github.com/nayutaco/ptarmigan/releases/tag/2018-04-11

他のノード(c-lightning / eclair / lnd)の使い方については、別のwikiにメモを作成しています。
https://github.com/nayutaco/lightning-memo/wiki

ptarmiganについてはdocsに書いています。
バージョンやcommit-idは記載当時のものになっていますが、だいたいは現在でも使えるようになっていると思います(動作しなかったら、issueくださると助かります)。


動作環境はUbuntuを想定していますが、Linuxであれば動作するのではないかと思います。
regtestでの動作はWindowsのWSL(Ubuntu)で行っています。

bitcoindの機能を使っていて、スクリプトではbitcoin-cliを呼び出し、ptarmiganのプロセス(ucoind)からはJSON-RPCを呼び出しています。

bitcoindのバージョンは、テスト環境ではv0.16を使っています。
おそらくv0.15でも動作するとは思いますが、今後のことを考えるとv0.16の方が無難かもしれません。
close後の送金アドレスは getnewaddress を使っているので、v0.15ではP2PKH、v0.16ではP2WPKH nested in BIP16 P2SHになります。

ptarmiganは、testnet/regtestでしか使用できません。


開発は、以下を中心に行っています。

  • BOLTを読んで、実装されていないところを追加、修正
  • 他ノードとやりとり
    • 認識が合わない動作があれば、BOLT再読やissueで確認
  • 操作性の向上やログ出力の見直し

BOLTの内容を読んで、それを実装レベルまでどう持っていくのか考えるのに時間がかかります。

まだまだ開発中ですので、ptarmiganに興味を持っていただけるとうれしいです。

[LN#018]announcement

Lightning Network BOLTの概要について、書いていくシリーズ。

今回は、announcementについて書きます。


転送(1)で簡単に紹介しましたが、BOLT#7でannouncement関連のメッセージが定義されています。

  • node_announcement
  • channel_announcement, channel_update

 

node_announcementは、alias名やIPアドレスなど、node自体の情報を展開しています。
相手nodeに接続したい場合は、このnodeからIPアドレスを調べ、接続させることでしょう。

 

1つのchannelには2つのnodeが関係するので、channel自体のannouncementメッセージ(channel_announcement)と、それぞれのnodeが持つchannel情報のannouncementメッセージ(channel_update)があります。
送金を転送するfeeなどは各nodeが主張できるので、通る方向によってfeeが異なる場合もあります。

 

 

このannouncementですが、Lightning Nodeをログ出力する状態にしてコマンドラインから実行するとわかりますが、相手nodeに接続すると、取りあえず大量に送信されてきます。
接続して最初に送信するinitメッセージで、相手nodeが持つchannel関連のannouncement情報を同期させるかどうか選べる(initial_routing_syncフラグ)のですが、だいたいは「同期する」にしているため、相手は持っている情報を送りつけるし、自分も持っている情報を送りつけます。

 

ならば、initial_routing_syncをオフにすればいいじゃないか、と思ってしまいますが、testnetではお金を掛けずにchannelを作ることができるためか、作って放置されるchannelが結構あります。
そういうchannelの情報しか持っていなかった場合、送金の転送をしたくても使用できないルートしか見つけることができなくなってしまうのです。

それを避けるため、取りあえず同期させようとしているのだと思います。

この辺りについては効率が悪いので、BOLTで解決していくのではないかと思われます。

[LN#017]2nd layer

Lightning Network BOLTの概要について、書いていくシリーズ。
LN#000~#016で大まかに行っていることを説明してきたので、これからは個々の部分について書いていきたいと思います。

今回は「大まかな2nd layerのイメージ」についてです。


Lightning Networkは、2nd layer技術の1つ、と呼ばれています。

2nd layerがあるということは、1st layerがあるということになります。
Bitcoinの場合、1st layerはBitcoinのブロックチェーンです。
パブリックなものとしてはmainnetとtestnetがありますが、ノードとして「mainnetのノード」「testnetのノード」という種別は作っていません。

では、どこでmainnet/testnetを分けるかというと、チャネルになります。
チャネルを開設するときのメッセージにgenesis block hashを載せるので、それを受け付けるかどうかで決まることになります。
もし、自分が対応しない種別のブロックチェーンであれば、チャネル開設を行わないようにできます。
また、チャネルの開設途中でfunding transactionという2nd layerの開始となるトランザクションを1st layerに展開するのですが、異なるブロックチェーンをINPUTにすることはできないので、そこで失敗するでしょう。

そのfunding transactionがブロックチェーンに展開されて、ある程度のconfirmationが経過すると、そこが2nd layerでのチャネル開設完了になります(正確には、完了したことを通知し合うメッセージを交換した後)。

以降は2nd layer上でいろいろやって、チャネルを閉じる処理をします。
閉じるときは、funding transactionの出力から送金することになります。
つまり、1st layerから見ると、funding transactionがspentになるとチャネルが閉じたことになります。


閉じ方は3つあります。

1つは、チャネルの双方が合意して閉じるパターン。
この方法は、その時のチャネルに入っている額がそれぞれのアドレスに送金されるので、一番早く1st layerで使えるようになります。
BOLT5で”The good way (mutual close)”と言われるやり方です。

image


その次は、”The bad way (unilateral close)”と呼ばれ、どちらかが現在の状況を使って閉じる方法です。
2nd layer上で送金が確定すると、毎回commitment transactionというトランザクションを作ります。
これは、funding transactionを入力としたもので、それをブロックチェーンに展開すると取りあえずクローズできるというトランザクションになります。
お互い、チャネルにある額は戻ってくるのですが、不正防止のために展開した人はアドレスでは無くスクリプトへ送金され、そこから自分で使えるようにするまでロックがかかっているため、その時間が経過するまでは使用することができません。

また、送金途中のHTLCもスクリプトに送金され、それを取り戻すにはさらに時間がかかります(図には描いていません)。

通常はやりたくないですが、チャネルの相手が行方不明になった場合など、「Good Way」でどうしても閉じられない場合に使用することになるでしょう。

image


最後が”The ugly way (revoked transaction close”と呼ばれる方法。
これは、最新のcommitment transactionをブロックチェーンに展開するのでは無く、過去のcommitment transactionを展開した場合です。

毎回、2nd layer上で取引が発生すると、commitment transactionを作成し、いつでも展開できるように署名をするので、展開しようと思えばできてしまうのです。
ただ、その展開は「取引を無かったことにしてしまおうという」ということに他ならないため、罰則が与えられます。

すなわち、すべての額が展開しなかった人が取り戻せるようなスクリプトに送金されている、ということです。

image

ただ、万能では無く、一定時間内に相手が取り戻す動作をしなくてはなりません。
その時間が、前の「bad way」で取り戻すのに時間がかかる理由にもなってきます。


このように、1st layerから見ると、2nd layerで行われている内容はfunding transactionとその出力しかありません。
その間の細かいやりとりはブロックチェーンには載らず、結果のみが残される形となります。
2nd layerはブロックチェーンに戻ってくることで確定される、という言い方もできると思います。

[LN#016]転送 (3)

引き続き、Lightning Network BOLTの送金転送について説明していく。
前回は、update_add_htlcで各チャネルでHTLCが追加されるところまでだったので、今回はHTLCの反映について説明する。


HTLCの反映は2点間の送金と同じで、update_fulfill_htlcメッセージを使用する。
必要となるのは、invoice作成元が持っているpayment_preimageという、invoiceに入っていたハッシュ値(このブログでは「請求書ID」と記載している)の元になる値である。
2点間であれば、送金した相手がpayment_preimageを持っているが、転送している場合は相手が持っているのかはわからない(送金元ノードと送金先ノードだけはわかる)。

以下のことは覚えておいてよいだろう。
・送金元は、送金先までのルート(どのノードを経由させるか)を作成する
・ルート情報は暗号化されている
・ルート情報を受け取ったチャネルは、1つ先までの転送情報を復号できる
・送金先は、次の送金先が無いということがわかるし、請求書IDの元データを自分が持っていることも確認できる。

update_fulfill_htlcに載っているpayment_preimageがHTLCの請求書IDの元データだとわかれば、HTLCを減らしてamountに反映することができる。
これは、通常の送金と同じである。
違うのは、update_add_htlcを別チャネルに転送したのと同じように、update_fulfill_htlcも同じルートで戻していくことになる点である。
update_add_htlcにはルート情報が載っているが、update_fulfill_htlcにはルート情報がないので、各自の責任で戻していくことになる。


送金の転送についての説明は、以上となる。
最後に、3者で転送した場合の簡単なシーケンスを図で示す。

image

BOLTではHTLCを、送金する方を「offered HTLC」、着金する方を「received HTLC」と呼んでいる。
図では、青い方がoffered HTLC、赤い方がreceived HTLCとしている。
反映の際には、offered HTLCは自分のamountから減らして相手のamountを増やし、received HTLCは自分のamountを増やして相手のamountを減らす。

[LN#015]転送 (2)

引き続き、Lightning Network BOLTの送金転送について説明していく。

今回は送金に関するメッセージについて見ていく。


送金の転送は、2ノード間の送金処理を送金元から行っていくことになる。
請求書の発行者が直接の相手ではないため、送金元から着金したノードは、別のノードに送金する。
これを繰り返すことで、送金先まで届くことになる。
BOLTメッセージで言えば、 update_add_htlcによってHTLCを追加する動作が行われることになる。

 

ここまでで、いろいろ疑問点が出てくる。
すぐ出てくるのは、こういうところだ。

  • 送金されたノードは、それをそのままもらったままにしないのか?
  • 送金されたノードは、次の転送先をどうやって決めるのか?

まず、もらったままにしないかどうかだが、update_add_htlcはHTLCを追加するだけのため、それだけでは自分の持ち分にすることができない。
HTLCは中に請求書IDのハッシュ値が入っていて、請求書IDそのものをもらうことによってスクリプトを解くことができ、自分の持ち分にすることができるのだ。
そして、請求書IDは送金先だけしか知らないので、それもまた遡るようにして転送してもらうことになる。

 

次に、次の転送先の決め方であるが、これはupdate_add_htlcのパラメータに入っている。
送金元から送金先までのルート情報は、送金元がすべて決定し、BOLT#4に沿って変換し、update_add_htlcに載せて送っている。
受け取ったノードはルート情報を自分が分かる鍵でデコードすると、次に転送するノードと、転送額がわかるようになっている(相手から送られてきた額と転送額の差が、転送する手数料として受け取る)。

転送するときは、デコードしたルート情報を載せて送る。
次に受けとった人も同じようにデコードすると、また次に転送する情報が載っているので、転送していく。
デコードして次に転送先がなかった場合、それが自分への送金ということがわかるようになっている。


送金の転送は、異なるチャネル間をノードが中継することになる。
チャネル内にfundingされている額は、チャネル外に出すことはできない。

例えば、よく送金に使われる経路があった場合、片方のチャネルは着金を受け付けるだけで、もう片方のチャネルは送金を行うだけ、ということがあるかもしれない。
そうすると、ノードとしては持っている額のトータルは変わらない(手数料によって増えることはあるが)ものの、チャネル内の額の偏りが生じてしまい、いつかは送金できる額がなくなってしまうだろう。

image

もちろん、経路の途中で送金ができなかった場合は、update_fail_htlcというメッセージがあり、HTLCを追加する前の状態に戻すことになっている。

額が足りなくなったチャネルは、今のところ一度closeして、またチャネルを作り直すしかないと考えられる。
次のBOLT仕様ではrefundという項目があるため、そこで解決される可能性もある。


このようにして、まずは送金元までの経路でHTLCを追加していく作業が行われる。

次回は、HTLCを反映させて自分の持ち分にするところを説明していく。

[LN#014]転送 (1)

BOLTでの、中継ノードを挟んだ送金の転送について説明していく。

基本は2ノード間の送金と同じで、送金の反映前と反映後の2動作になる。
ただ、いくつか前提があるため、そこから始めたい。


送金は、いくつかのノードを中継していくことになる。
各ノード間はチャネルでつながっているため、そのチャネルを使わせてもらうことになる。
そのため、ノードが要求する手数料を払いつつ転送することになる。

支払いには期限を指定するが、送金の真ん中で先に期限が切れるようなことが起きると、払い損が生じてしまう可能性がある。
そうならないよう、期限は送金先から順に長くなるように設定しなくてはならないし、各ノードごとに「最低限このくらいの期間はほしい」という要求があるので、それを満たす必要もある。

また、どのノード/チャネルを経由するかは送金するノードが送金時に決定して、update_add_htlcのonion_routing_packetに載せる。

 

よって、送金するノードは以下の情報を持っていなくてはならない。

  • 送金先までの各ノード(node_id)
  • ノード間のチャネル(short_channel_id)
  • 各ノードが要求する手数料
  • 各ノードが要求する期限

BOLTでは、この情報は各ノードが発信することになっている。
その発信方法もBOLTメッセージを使っていて、BOLT7で規定されている。


ノードの情報はnode_announcementメッセージによって、チャネルの情報はchannel_announcementchannel_updateメッセージによって通知される。

ノード名やアドレス(IPv4、IPv6など)、ノードの色などはnode_announcementで通知される。
ノード名やノードの色というのは直接BOLTの送金に関係があるものではなく、一覧などを作成した場合に見やすくするためのものと思われる(少なくとも、BOLTメッセージで出てくるのはここだけである)。

 

それ以外はチャネルの情報になる。
channel_announcementでは、short_channel_idと、そのチャネルの両端のノードのnode_id、およびそこで使われるブロックチェーンの種類(genesis block)が通知される。
channel_updateでは、それぞれのノードが要求する手数料や期限などの情報が通知される。


これらの情報から、送金元→送金先の経路を作ることになる。
経路の作り方については、最近になって推奨が追加されていた。

経路情報を作れば、そこからはBOLT4に従ってonion_routing_packetを作成し、update_add_htlcメッセージを送信する。

次回は、送金元がメッセージ送信するところから説明する。

[LN#013]現状(2017年12月前半)

ここまででChannel Establishment、Normal Operation、Channel Closeの主要な説明を行ってきた。

今回は、現状(2017/12前半)のBOLTについてまとめておく。
BOLTのコミットはこちらである。


2017/12/7に、以下の記事が掲載された。
Lightning Protocol 1.0: Compatibility Achieved ✅ – Lightning Developers – Medium

これを掲載した時点(2017/12/20)で、またBOLTとしてv1.0はリリースされていない。
記事で、c-lightningeclairlndの3ノードアプリ間で統合テストが通ったという内容であった。

基本的には、現在の内容からは大きく変更せずにv1.0として固めるのだろうと思われる。
issueもあるものの、現在はドキュメントとしての整備が行われているようで、最近のコミット内容は英語の文法や見栄えのような習性が多い。

 

v1.0には入れないが、次のv1.1に入れたいという内容は上がってきている。
https://github.com/lightningnetwork/lightning-rfc/milestone/1


現状のBOLT仕様ではいくつか数値の制限があるので、amountや期間に関係するものをいくつか挙げておく。

 

Channel Establishment

funding_satoshisは、チャネルにfundingする額である。
当初は、funding_satoshisなどの額については4byteで管理していたのだが、Litecoinではコーヒーも飲めないということで8byte管理になったようである。
なお、ブロックチェーンの種類はopen_channel/accept_channelにgenesis blockのハッシュを載せることで表している。

max_accepted_htlcsは、受入可能なHTLC数ということで、送金反映でHTLCが消える前に別の送金が行われるなどしてHTLCがたまっていった場合の上限と考えている。
この半端な数字は、違反した相手から取り戻すときのことを考慮しているようである。

minimum_depthは、相手がチャネル開設を要求してきた(open_channelを送信)とき、自分はfunding transactionを認めるのにconfirmationがこれだけ必要になる、という下限である。
表現として「大きすぎる(unreasonably large)」は曖昧だが、ノードを立てた人の感覚を重視しているのかもしれない。

 

Normal Operation

ホップ数は最大で20もあるため、update_add_htlcメッセージは1,366byteと固定のBOLTメッセージで一番大きくなっている。
また、onion_routing_packetは送金経路を隠蔽するようにできているため、ホップ数にかかわらず1,366byte送信する必要がある。

[LN#012]Channel Close

Channel Establishで開設したチャネルは、通常、Channel Closeで閉鎖する。
お互いが同意しているので、Mutual Closeと呼んでいる。

 

使用するBOLTメッセージは2種類で、shutdownとclosing_signedである。
前提条件は、HTLCが残っていない(no pending charges)ことである。

まず、どちらかがshutdownメッセージに送金してほしいアドレス(正確にはscriptPubKey)を伝え、それに応じて相手もshutdownメッセージを返す。
後は、チャネル閉鎖時にfunding transactionから送金するトランザクションであるclosing transactionの署名とそのときの手数料をclosing_signedメッセージで交換し合い、相手の提示する手数料に納得したら同じ手数料でclosing_signedを返して終わりとなる。
(この連載中、open_channel/accept_channelメッセージにshutdown_scriptpubkeyが追加されたが、オプションのため今回は除外する。)

以下は、最短で閉じた場合のシーケンスである。

image

 

注意したいのは、一度でも署名を送信していると、そのトランザクションに相手が署名を追加してブロックチェーンに展開することが可能な点である。
自分がclosing_signedを送信した=その手数料で送信しても問題ない、ということになるため、困ることはないと思われるが、最後に交換したclosing_signedで必ずしも展開されるわけではないということは覚えておいた方がよいだろう。

[LN#011]送金 (5)

前回はcommitment transactionの構成と、その送金先に指定するoutput(to_local, to_remote, Offered HTLC, Received HTLC)について説明した。
今回は、その送金先について解説する。


to_local outputは、通常は以下のようなunlocking scriptを使って使用する(通常ではない=古いcommitment transaction)。

image

ここのto_self_delayは、open_channel/accept_channelで相手が指定したto_self_delayを使用する。
この値はOP_CSV(CHECKSEQUENCEVERIFY)の判定に使われ、このトランザクションを展開してからto_self_delay以上のブロックが経過しないと展開できない。

このスクリプトはunlockingのためにlocal delayedsecretkeyで署名する必要があるため、commitment transactionを展開した人(=delayedsecretkeyを知っている人)が使えるようになっている。


to_remote outputは、P2WPKHへの送金になる。
スクリプトではないため、何もせずに使用できる。

これは、commitment transactionを展開していない人への送金になっている。


Offered HTLC outputsは、commitment transactionをどちらが展開したかによってunlocking scriptが変わる。

 

自分が展開

この場合は、2-of-2になっていて、署名として自分と相手の両方が必要になる。
相手の署名は、commitment_signedのhtlc_signatureで受け取る。

image

自分が展開したOffered HTLC outputは、自分が相手に送金したHTLCになるため、通常は「相手が受け取らずにタイムアウトしたときに取り戻す」ときに解くことになる。

相手に署名してもらうためには、トランザクションが確定している必要がある。
そのトランザクションはHTLC-Timeout Transactionという名前になっている。

image

 

相手が展開

相手が展開したcommitment transactionに載っているOffered HTLC outputsは、自分が受け取る予定のため、payment_preimageを必要とする。

image

これは自分だけで処理できるため、解いた後の送金先を指定できる。

image


Received HTLC outputsも同様に、どちらがcommitment transactionを展開したかによって変わってくる。

 

自分が展開

この場合は2-of-2になっていて、署名はOffered HTLC outputsと同じくcommitment_signedメッセージで受け取っている。
また、自分が受け取る予定のため、payment_preimageも必要である。

image

相手に署名してもらうためには、トランザクションが確定している必要がある。
そのトランザクションはHTLC-Success Transactionという名前になっていて、構成はHTLC-Timeout Transactionとほぼ同じである。

image

 

相手が展開

相手が展開したReceived HTLC outputsは、自分の送金に対応している。
それを使用できるようになるのはタイムアウトした場合である。

image

こちらについては、送金先を自由に決めることができる。

image


commitment transactionをブロックチェーンに展開した後の送金先について説明した。
次回は、BOLTメッセージを使ってお互いが同意してチャネルを閉鎖する場合について解説する。

[LN#010]送金 (4)

今回はcommitment transactionの構成について説明する。
トランザクションの構成は、BOLT3に記載されている。

  • version : 2
  • locktime : obscured commitment transaction number
  • txin : 1
  • txout : n

トランザクションのINPUTは1つで、funding transactionである。
OUTPUTは、状況によって異なる。

自分が展開できるcommitment transactionを眺めた場合、fundingした資金のうちの自分の取り分と相手の取り分がある。
これがそれぞれ、to_local outputto_remote outputになる。
それ以外には、HTLCがある。
自分から相手に送金したOffered HTLC outputsと、相手から自分に送金されたReceived HTLC outputsである。


to_remote outputはP2WPKHへの送金なので、commitment transactionを展開するとすぐに相手が使用できるが、それ以外はスクリプトへの送金になるため、スクリプトを解けなくては使用できない。


to_local outputのスクリプトは自分が持つ鍵情報だけで解くことができるのだが、Establish Channel時に相手からもらった to_self_delay を組み込むことになっている。

image

例えば、to_self_delayが40だった場合、to_local outputを解くためにはcommitment transactionが展開されてから40ブロック以上待たなくてはならない。

もし、<revocationkey>(公開鍵)の秘密鍵revocationsecretkeyを持っているならば、それで署名してOP_IFのルートでスクリプトを解くことができ、その場合は待ち時間はない。
ただ、revocationsecretkeyの計算にはそのスクリプトを展開した人のper_commitment_secretという情報と、相手の人のrevocation_basepoint_secretという情報が必要になっている。
per_commitment_secretは、revoke_and_ackメッセージで過去の分を交換するが、revocation_basepoint_secretについては交換しない。
そのため、revocationsecretkeyはcommitment transactionを展開した人は作成できないが、その相手は作成できることになる(ただし、過去にrevoke_and_ackメッセージで交換したものに限る)。

こうすることで、過去のcommitment transactionを展開すると相手に奪い取られるようになっている。


Offered HTLC outputsは、支払った側が作るoutputである。
つまり、update_add_htlcメッセージを送信した人はcommitment transactionにOffered HTLC outputを追加していく。

image

スクリプトの作りが複雑だが、通常は5行目のOP_ELSE内の方が処理される(最初のOP_IFは、廃棄したcommitment transactionを展開されたときのルート)。

自分がcommitment transactionを展開した場合は7行目(A)のOP_NOTIFのルート、そうでない場合は10行目(B)のOP_ELSEのルートになる。
7行目(A)を通る場合はHTLC-Timeout transactionへの出力、10行目(B)を通る場合はpayment_preimageを持っている場合だけ解くことができる。

 

送金した人(=Offered HTLC outputsを持つ)がcommitment transactionを展開したとする。
そのHTLCは、通常は相手が受け取るはずで、受け取るときにはpayment preimageという領収書のIDが必要になる(送金(2)参照)。これはBのルート。
もし相手が受け取らないままタイムアウトを迎えた場合は、送金した人が取り戻す。こちらはAのルートである。

同じ”Offered HTLC outputs”という名称でも、どちらがcommitment transactionを展開したかによって見方が変わることに注意していただきたい。


Received HTLC outputsはその逆で、相手からupdate_add_htlcメッセージを受信した人が自分のcommitment transactionに追加することになる。

image

Offered HTLC outputsと似て、通常は5行目のOP_ELSE内を通る。
8行目(C)のOP_IF内は自分がcommitment transactionを展開し、payment preimageを持っている場合のルート。
12行目(D)のOP_ELSE内は相手がcomitment transactionを展開したときのルート。

 

着金した人(=Received HTLC outputsを持つ)がcommitment transactionを展開したとする。
そのHTLCは通常は自分が受け取るはずで、それにはpayment preimageが必要になる(Cのルート)。
もし自分がpreimageを取得できないままタイムアウトした場合は、相手が取り戻す(Dのルート)。


これらのoutputは、送金額が決められた値以下の場合は取り除かれることになっている。
https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#trimmed-outputs

通常のBitcoinであれば546satoshisだが、それとは別にopen_channelaccept_channelのdust_limit_satoshisで指定できる。
指定できるといっても、最終的にはBitcoinのブロックチェーンに展開することになるので、Bitcoinの制約を下回ることはできない。


commitment transactionについては、ここまでとする。
スクリプトが複雑なので、興味がある方は動きを確認することをお勧めする。

commitment transaction自体にはP2WPKH/P2WSHだけしか見えず、実際にスクリプトがトランザクションに現れるのは送金先トランザクションである。
次回は、その送金先トランザクションについて説明していく。