LN technical details

Such as architecture of commitment transaction.

LN のメッセージの形式

type は奇数

取引の流れ

チャネルをつくって state を update する。これはかんたん

どうやって前の state を無効にするか

すべての to_self output はタイムロック OR remote が revocation key ですぐに unlock できる。

relay するにはどうするか

HTLC を連鎖させる

Commitment transaction

funding tx を unlock する

channel open 時には funding tx と最初の commitment tx(refund tx とも呼ぶ) が作られる

6種類の lock の方法がある

to_local(P2WPKH)

unlock 条件

to_self_delay

revoc key, remote_sig

to_remote(P2WPKH)

remote sig

anchor tx 2種類

HTLC は多段

The reason for the separate transaction stage for HTLC outputs is so that HTLCs can timeout or be fulfilled even though they are within the to_self_delay delay. Otherwise, the required minimum timeout on HTLCs is lengthened by this delay, causing longer timeouts for HTLCs traversing the network.

あまりよくわかっていない、、、

local への支払いは常に to_self 分の delay が必要で、timeout した HTLC を取り戻す場合にも to_self delay が必要。

そうでなければ、HTLC output は CLTV 後はいつでも使える状態になり、仮に HTLC が fullfied であったとしても、すぐに取り返すことができてしまう

なので、to_local の HTLC は CLTV による HTLC の expire 時間の設定に加えて、to_self delay が必要

つまり、HTLC は CLTV により expire しているのにも関わらず、それを自分に取り戻す場合はそれ以上に時間がかかることを意味する。つまり実質的な CLTV は CLTV + CSV。

もし CTLV delta がこの実質的な CLTV よりも小さい場合(delta < CLTV)、資金を失う可能性があるので、CLTV delta を 実質の CLTV よりも大きくする必要がある。

なぜ資金を失う可能性があるか

Received HTLC は Offerd HTLC よりも早く expire してはいけない

Received HTLC の CLTV > Offerd HTLC の CLTV でないといけない

Received が先に expire すると、その資金は相手に戻る。でも自分の Offerd はまだ expire していないので、送金相手に送金される。自分は送ったのに、その分は受け取れない状況になっている

実質的な CLTV が CLTV + CSV である場合、CLTV delta は当然 CSV も含めて考える必要がある

delta が 5 block、Received CLTV が 105 block とすると、Offerd CLTV は 100 block。CSV は 10 block とする。

この時、Offerd の HTLC を回収するには minimum block 110 まで待つ必要がある(expire が block 100 で、プラス CSV 10 block 分)

received は 105 + 10 block で 115 block

問題なくない？

問題があるとすれば、receive を取り返せる前に、offerd が timeout するのでそちらの取り返し作業も始まってしまってレースになる？

しかしこの場合、次の Hop もこの timeout 時間の影響を受けることになる???

commitment tx の to_local には to_self_delay 分の timelock をかける。to_self_delay は割と長いので HTLCの timeout はこれよりも短い時間に設定できないと、ルーティングで資金がロックされる時間が長くなってしまう？

多段にする理由

There is still a problem: Making the output to Alice encumbered by both these timelocks could in the worst case extend the HTLC’s timeout by to_self_delay. In other words, Bob could have an extra to_self_delay blocks in order to sweep the hash-locked output even though the HTLC is technically expired.

From here, one can imagine a scenario where we have an HTLC that can be timed out (absolute block height passed), but we can't spend it (timing it out) until our CSV period has also expired. Therefore, one needs to set their CSV values taking into account the absolute timelock (CLTV) value as well. Critically, before a user can cancel their incoming off-chain HTLC (timing out the outgoing on-chain), they need to wait for this CSV period. However, if the CSV is greater than the time lock delta (diff between incoming and outgoing HTLCs), they've created a race and could possibly lose money.

Offered HTLC output

自分から送金する HTLC

unlock 条件

revoc key, remote sig

preimage, remote sig

HTLC-timeout tx

HTLC の expire 時間を指定するので絶対時間での timelock が必要

Received HTLC output

受け取る HTLC

unlock 条件

revoc key, remote sig

HTLC-success tx

HTLC-timeout tx

CLTV で timelock

HTLC-Timeout and HTLC-Success Transactions

These HTLC transactions are almost identical, except the HTLC-timeout transaction is timelocked.

HTLC-timeout tx は input になる HTLC tx の script で CLTV による timelock がかけられる

Offerd HTLC tx か Received HTLC tx を input にする

署名

success tx: マルチシグ, preimage

timeout tx: マルチシグ

unlock 条件

revoc key, remote sig

CSV timelock, local sig

cltv_expiry_delta

CLTV は HTLC-timeout tx にかかる timelock

delta は、offerd が timeout したにも関わらず、received を fullfil しないといけない状況になった場合に、十分な時間を与える必要がある？

Received HTLC と Offerd HTLC の CLTV の差が小さいと、Offerd HTCL が success して自分は送金できたのに、Receive HTLC が timeout して自分は受け取れなかった、ということが生じる可能性が高まる

自分の timeout は前の timeout よりも短くないといけない

Offered HTLC からのが取り戻しが完了するまでは、Received HTLC の取り戻しは開始されないでほしい？

なぜなら、offerd から取りっぱぐれたのに、receive も相手にとられる、とういことがありえる

送金はどのように行われるか

HTLC を追加

流れ

リレーを atomic に行うため

A - B - C と送金する場合(A が B を経由して C に送金したい)

B は C に渡したけど、A から受け取れない可能性がある

A は B に渡したけど、B が C に渡さない可能性がある

A は C しか知らない値(preimage)で、 B への送金をロックする(hash(preimage)が unlock には必要) + 取り戻す用の timelock

これが HTLC

B は自分は送ったのに、先に A に取り戻されると困る

そのため、B-C の HTLC の timelock は A-C の HTLC の timelock よりも短くないといけない

A-B timelock < B-C timelock だと、C が preimage を明かしたタイミング(つまり B-C の timelock よりも前)で、すでに A が取り戻せる可能性がある(こちらの方が timelock が開けるのが早いので)

C が preimage を明かしたあとに、B がそれを使って A-B の HTLC から資金を受け取れるのに十分な時間差が必要

まて

The reason for the separate transaction stage for HTLC outputs is so that HTLCs can timeout or be fulfilled even though they are within the to_self_delay delay. Otherwise, the required minimum timeout on HTLCs is lengthened by this delay, causing longer timeouts for HTLCs traversing the network.