ThinkITにて、Lightning Networkについての短期連載を行いました。

• 第1回：Lightning Networkが動作する仕組み
• 第2回：Lightning Networkの送金処理で使用されている技術【前編】
• 第3回：Lightning Networkの送金処理で使用されている技術【後編】

わかりやすいかどうかは別として、イメージをつかんでいただければ幸いです。

第3回の図がわかりづらいようだったので、補足しておきます。

これは、transactionの名称とoutputの名称を図で表そうとしたものです。

funding transactionは、同意してチャネルを閉じる場合にはclosing transactionへ、そうではない場合はcommitment transactionにつながります。
closing transactionは、チャネルを開いたそれぞれが送金先を指定するので、そこから先は自由です。
問題は、commitment transaction。

チャネルに送金できる額が残っていれば、to_local outputとto_remote outputがあります。
dust以下しか残っていなければ、そのoutputはありません。
もしHTLCが残っていて、それも送金できる額が残っていれば、offered HTLC outputsやreceived HTLC outputがあります。

で、この名称は「output」なので、transaction名ではありません。
連載の図ではtransactionと同じ色にしてしまったので、わかりづらかったのだと思います。

to_local outputは、スクリプトへの送金です。
スクリプトに名称はないので、to_local outputという名前のスクリプトだと思っていいんじゃないでしょうか。
この送金は、スクリプトだけが指定されていて、そこから先のoutputは自由です。
なので、BOLTとしてはこの部分にtransactionとしての名称を付けていません。

to_remote outputは、相手のアドレスへの送金です。

offered HTLC outputsとreceived HTLC outputsは、スクリプトへの送金です。
ただし、この送金先についてはさらに次のoutputまでBOLTで指定されています。
そのため、HTLC Timeout transactionやHTLC Success transactionという名称が付けられています。

という図でした。

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

LN#020, LN#021とLightning Network BOLTで使われているHTLCについて書きましたが、読んだ方から「スクリプトのどこでロックしているの？」という質問を受けました。
確かに、スクリプトの内容ばかり書いていて、どう制限がかかっているかについては、OP_CHECKLOCKTIMEVERIFYやOP_CHECKSEQUENCEVERIFYという命令名を書いただけになっていました。

今回は、HTLCとトランザクションについて、実データを例にしながら書いていきます。

regtestで行った例になります。
amountの単位として書いているmsatは msatoshi(ミリsatoshi)です。

• Aさんが持つamount：300000000 msat
• Bさんが持つamount : 300000000 msat

ここで、送金を行います。

• Aさん→Bさん：200000000 msat

送金は、大ざっぱに書くと以下のような通信を行います。

送金する額のHTLCをcommitment transactionに追加する工程と、それを反映してcommitment transactionからHTLCを削除する工程です。
commitment transactionの構成が変わるのでそのたびに署名を交換します。

今回は、HTLCの追加に焦点を当てます。

Aさん：送金元(payer)

HTLC追加後の、Aさんが持つcommitment transactionはこうなりました。

ptarmiganが持っているトランザクション出力を使っているため、”bitcoin-cli decoderawtransaction” などとは構成が違うと思いますが、だいたいの雰囲気は伝わるかと思います。

HTLCへの送金になるのは、commitment transactionの出力が3つあるうちの真ん中になります。
Aさん＝送金元なので、HTLCは「Offered HTLC output」になります。

Offered HTLC outputは、相手への送金を目的としているので、基本的にはBさん宛になるはずです。
Bさん宛＝Bさんが署名してどこかに送金する、ということになります。
そのために必要になるのは、送金前に相手からもらったinvoiceに含まれている情報「payment_hash」のハッシュ計算をする前の値である「payment_preimage」という値です。

Aさんの立場からすると、

• Bさんがpayment_preimageを使ってOffered HTLC outputをどこかに送金すれば、それでよし
• もしそうしないまま放置するようだったら、送金はなかったものとして、Aさんがどこかに送金する

ということになっています。

この「放置するようだったら」の期限は、commitment transactionを見ても分からず、かといってOffered HTLCのスクリプトを見てもわかりません。
実は、BOLT仕様によって「時間切れになった場合のトランザクション」というものが決められています(2人の署名がいる)。
そして、HTLCを追加した後に署名交換を行いますが、そのときにHTLCの署名も交換するようになっています。

事前に署名をする以上、トランザクションの内容は仕様できっちり決められています。
そのため、Aさんは決められたトランザクション以外をブロックチェーンに展開することができません。

Aさんの時間切れになったときに取り戻すトランザクション(HTLC Timeout Transaction)は、このような形になりました。
(witnessは省略)

一番下の、locktimeに値が指定されているところに注目してください。

commitment transactionにもlocktimeは指定しますが、タイプは日時になっていて、それは既に過ぎ去った時間になっているためいつでも展開できますが、Timeout Transactionはブロック高になっています。

そのため、このトランザクションをブロックチェーンに展開するには、現在のブロック高がlocktime以上になるまで待たなくてはなりません(regtestなので、値は小さめになっています)。

Bさんの立場からすると、もしAさんがcommitment transactionをブロックチェーンに展開したとしても、送金をAさんが取り戻すまでにlocktimeまでの余裕があることになります。
その間にpayment_preimageを使って、下図の赤枠の経路を通って取り戻します。

Bさん：送金先(payee)

Bさんのcommitment transactionはこうなりました。

こちらも、真ん中のoutputがHTLCです。
なお、commitment transactionはBIP69に従ってソートします。

Bさんはお金を受け取る方なので、

• payment_preimageを使ったトランザクションを期限までに展開する

という動作を行います。

payment_preimageを使って取り戻すトランザクション(HTLC Success Transaction)は、こうなりました。

構成はHTLC Timeout Transactionとほぼ同じで、違いはlocktimeの有無になります。
Success Transactionはlocktimeが0なので、payment_preimageを持っていればすぐに展開できます。

Aさんの立場からすると、もしBさんがcommitment transactionを展開したままpayment_preimageを使わずに放置したままになっていても、実はそれほど困りません。
それは、Aさんがpayerだからです。

しかし、Aさんが単に送金を中継している場合、それでは困ります。
Aさんが転送する元になった入金を手に入れるためには、payment_preimageが必要になるからです。

放置したままにならないよう、Bさんがcommitment transactionを展開した場合は、payment_preimageを持たなくても一定時間が経過したら取り戻せるようになっています。
それが、下図の赤枠で囲んだ命令です。

<cltv_expiry>というのはブロック高で、そのブロック高以上の時間になればその経路が有効になります。
Bさんにとってみれば、その経路をAさんが使う＝自分の手に入れられない、ということになり、それまでの間にpayment_preimageを使ってしまおう、と考えることになります。

今回はトランザクションを含めて、Offered/Received HTLCの説明をしました。

今回の話が出てくるのは、HTLCを追加して、そのまま反映されずに残って、チャネルを閉じたくなった場合です。
通常は、HTLCを追加した後、すぐにHTLCを反映するので、commitment transactionにHTLCが残ったままになることはあまりないでしょうが、そういう場合も考慮されているということは知っておいてよいと思います。

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

今回は、送金を転送する際のfee計算についてです。

Lightning Network BOLTには、送金を転送するという仕様があります。
だいたいの場合、Lightning Networkで送金をする際には、このような流れになります(図の数字と連番は関係ありません)。

1. 送金する人(payer)が、送金先の人(payee)からinvoiceの文字列をもらう
2. payerは、Lightning Networkのノードアプリにinvoiceを伝える
3. payerのノードアプリが、今まで通知されたchannelの情報を使って、payeeまでのルートを作る
4. payerは、ルートの最初の人に暗号化されたルート情報と送金額を通知
5. 受け取った人は、暗号化されたルートから次の送金先と送金額をデコードし、それに従って通知
6. 手順5を繰り返していき、payeeまでたどり着くと、payeeはinvoiceを解く鍵を送り返す
7. 鍵を受け取った人はinvoiceを解いて自分への送金を受け取り、送金したルートと逆順に鍵を送っていく

中継する人は、経路を使った見返りとして、送金したfeeを受け取ることができます。

feeは、「受け取った送金額」と「次に渡す送金額」の差になります。
たとえばこの図では、中継Aさんがfeeとして10、中継Bさんが20を要求した場合、payeeへ100送りたいならば、payerは130送金します。

手数料はpayerが勝手に決めるわけではなく、各ノードがchannel情報をアナウンスするメッセージの中に入っています。

BOLTメッセージで言えば、channel_updateになります。
feeに関係するパラメータは、この2つです。

fee_base_msatは、ベースとなるfeeで、固定です(単位はmsatoshi)。
fee_proportional_millionthsは、100万satoshi＝10mBTC辺りのfeeです。

なお、単に相手に送金するだけであればfeeは発生しません。

feeは、経由するチャネルごとにかかるため、経路のチャネルが増えると、feeが多くなっていきます。
しかし、feeはチャネルごとに異なるため、あまり高いfeeを設定しているとpayerがルート計算する際に除外されることでしょう。

2018年2月にTESTNETで値を見たときは、各ノードのデフォルト値はこのようになっていました。
https://github.com/nayutaco/lightning-memo/wiki/%E6%8E%A5%E7%B6%9A%E3%83%86%E3%82%B9%E3%83%88#table

TESTNETなので値が高い低いというのはあまり意味がありません(MAINNETでの値は調べていません)。

パラメータはノードアプリで設定できると思いますので、確認されると面白いでしょう。

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

前回の続きで、Lightning Networkで使われているHTLCの説明をしていきます。
なお、今の最新BOLTはcommit: f608c33です。

BOLTでは、2種類のHTLCがあります。

• Offered HTLC
• Received HTLC

Offered HTLCは送金側、Received HTLCは着金側になります。

今回はBOLTメッセージのシーケンスは関係ありませんが、HTLCの追加と反映はこのような流れになっています。

HTLCはスクリプトで、commitment transactionでは送金先として使われます。
私は、送金するamountを箱に入れて、送金先の人が渡した鍵で封印するようなイメージを描いてます。
送金元が自分のamountの一部を箱に入れ、封をして、送金先に渡してチェックされ、OKだったら封印を解く鍵をもらって、箱から取り出して送金先のamountに追加する、というところです。
封が解かれると、箱は消滅します。

実際には、これをスクリプトで行うことになります。

送金する人からすると、以下のような状況が発生すると困ります。

• 相手がReceived HTLCをもらってない、と言い張る
• HTLCは渡したが、着金を認めてくれない
• HTLCは渡して、相手は着金を認めたが、鍵を渡してくれない

前回のto_localスクリプトでは、OP_CSV(OP_CHECKSEQUENCEVERIFY)を使うことで、取り戻すまでに時間がかかるようにしていました。
ここでは、OP_CLTV(OP_CHECKLOCKTIMEVERIFY)という命令を使うことで、スクリプトがタイムアウトできるようにします。
送金先の人が一定期間内に鍵を渡さなかった(＝スクリプトを解かない)場合、そのHTLCは送金元の人が取り戻すことができる、という条件を付けることで、放置したままになったり、相手との連絡が取れなくなった場合でも取り戻せるようにしているのです。

文字で書くと、なるほど、というところですが、これをスクリプトで表さなくてはなりません。
あまり深入りすると説明が終わらなくなるので、ざっと流したいと思います。

Offered HTLC

BOLTのドキュメントでは”Offered HTLC Outputs”となっていますが、commitment transactionの送金先として説明されているためです。
なお、仕様上のHTLC最大数は483となっています。

これが本体(?)で、to_localスクリプトと同じく、この前にデータを置くことで、OP_IFのルートを変えたり、チェックするデータを変えたりします。

OP_IFを通るのは、<revocationpubkey>などの結果がTRUEだった場合です。
to_localと同様で、「revocation」という単語が入っている場合は、古いcommitment transactionをブロックチェーンに展開した場合の対策になります。
古いcommitment transactionはスクリプト秘密鍵を相手に渡しているので、相手はそのルートを通すことができます(展開した人は通すことができない)。
そうすると、OP_CSVやOP_CLTVなどを通らないルートになるため、即座に相手は取り戻すことができる、というわけです。

OP_ELSEのルートが、タイムアウトなどの制限を付けたルートになります。
中のOP_NOTIFルートがタイムアウトして取り戻す場合のルート、OP_ELSEルートが鍵(preimage)を使って解くルートです。

通常、送金をした場合は、着金を確認した人がupdate_fulfill_htlcというメッセージを使ってpreimageを通知します。
preimageをもらった人は、HTLCの鍵であることをチェックして、問題なければHTLCをそのまま反映して、HTLCを消します。

HTLCが残ったままcommitment transactionになるのは、

• HTLCを追加して、
• preimageをもらわずに、
• commitment transactionをブロックチェーンに展開した

という場合だけです(unilateral close: local remote)。

commitment transactionが展開されたということは、Lightning Networkのチャネルはクローズされたことになります。
bitcoindのJSON-RPCでgettxoutするとfunding transactionがunspentかどうかチェックできます。
funding transactionがunspentでなくなった＝クローズになった、でもあります。

それ以降は、1st Layerでの処理になります。
ブロックチェーンを見て、preimageがあればスクリプトを解くもよいし、タイムアウトまで待って取り戻すもよし、です。
どうしないといけないか、ということについて今のところBOLTでは既定がありません。

Received HTLC

説明したかったことはOffered HTLCのところで書いたので、Received HTLCは簡単に済ませます。

相手がOffered HTLCを追加すると、自分はReceived HTLCを追加することになります。

最初のOP_IFがペナルティーのルート。
OP_ELSE以下の、OP_IFがpreimageを持っている場合のルート、OP_ELSEがタイムアウトのルートになります。

Offered HTLCスクリプトも、Received HTLCスクリプトも、終わりがOP_CHECKSIGになっているルートと、OP_CHECKMULTISIGになっているルートがあります。

OP_CHECKSIGは署名が1つで、その署名は自分で作成することができます。
しかし、OP_CHECKMULTISIGは署名が複数必要で、このスクリプトでは2ついるようになっています。

複数必要になるのは、以下のルートです。

• Offered HTLC : タイムアウトして自分に取り戻す
• Received HTLC : preimageを使って自分に取り戻す

相手の署名も必要になりますが、それをどこで取得するかというと、commitment_signedメッセージです。
commitment_signedのhtlc_signatureがその署名になります。

あらかじめ署名ができるということは、送金先も決めておかなくてはなりません。
どこに送金するかというと、to_localスクリプトと同じ形のスクリプトになります。
タイムアウトする場合はHTLC Timeout output、preimageで取り戻す場合はHTLC Success outputと呼びます。

to_localと同じ形のため、そこから取り戻すためにはto_self_delayブロック待たなくてはなりません。

HTLCについては、以上になります。

なるべくゆっくり説明したつもりですが、それでも非常に難解だと思います。
きっちり理解されたい場合は、BOLTの#02, #03, #05あたりを読むことをおすすめします。