LN async payment
LN 送金は相手がオンラインでないと完了しない。これは L1 との違いである。
モバイル LN wallet は、電池が切れたり、インターネットに接続できない状態に成る可能性があるため、モバイル LN wallet への送金はいつも成功するとは限らないことになってしまう。
この問題をある程度解消するのが async payment。オンラインでないと LN 送金が完了しない事実はかわらないので、送金先がオフラインでも送金を開始でき、送金先がオンラインに復帰したときに送金を完了できる仕組みが async payment である。
PTLC ではなくて keysend を保持しておけばいいだけではという話も keysend では proof of payment はない
keysend を使う場合のフロー図
LN で offline の相手にどうやっておくるか mobile client はオフラインになりうる
BOLT12 でアドレスを貼り付けることが可能になっても、オフラインの相手には送れないままである いまのinvoiceの仕様を拡張すればいいのでBOLT12を待つ必要性はない
Phoenix はまずは BOLT11 で実装を進めている
sender がオフラインでも trustless にリトライする仕組みが必要
update_add_htlc の onion_routing_packet には、それ以降の Hop の情報がすべて入っている
payee がオンラインに復帰する間に Hop の情報が変わってしまうと、onion_routing_packet の情報をつかってルーティングできなくなってしまう
onion_routing_packet の中身を変更できればよいが、レイヤーごとに復号できるノードは決まっているのでそうはいかない
trampoline node 以降のパスは trampoline ノードが決めるというアプローチ
最初の Hop には大きな CLTV が必要
ロックされて困るのは送信者だが、送るつもりで手放している資金だからそんなに問題にはならないだろう
その後ろの CLTV は小さくする仕組みが必要？いまはできない？
pending HTLC がある状態で channel 閉じるときはどうなる？
各実装の対応状況は？
probably the best case scenario would be delivering a working demonstration of phase 1 in Q3 2023 and phase 2 in Q4 2023.
LSP 同士が合意して、送り先が offline だったら、送り元の LSP で止めておく仕様が考えられる
invoice を事前に複数発行しておいて、LSP にそれを使ってもらう
ただし invoice を使いまわすと LSP が盗むことができてしまうので、LSP を信用する必要がある
ある preimageAから作成された invoice で一度支払いをうけると、LSP は preimageA を知ることになる
次の async payment 時に、同じ invoice を使うと、すでに preimageA を知っているため、edge への送金をして preimage を手に入れなくても、HTLC を解除することができてしまう
いまの HTLC でも、payee が生成する preimage に加えて payer がランダムに生成する値を HTLC の unlock 条件にすればいいのでは by ZmnSCPxj そうだけど、結局プロトコルレベルでの変更が必要だから PTLC すればいいよね
Proof of Payment
PTLC では Proof-of-Payment ができないという話があった
payee が生成する preimage を知っていることが PoP であるが、PTLC では秘密鍵 s にあたり、これは毎回同じ。これが毎回同じでも盗むことができないのが PTLC のいいところではあるが、s は毎回同じなので PoP にはならな
解決策として提示されている案
adoptor を作成する input として、payer が作成するメッセージを使うことで、adoptor に対応する署名がすなわちメッセージへの署名となり、payer が受け取った証明となる
BIP47 的な考えを適用できないのだろうか？