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 を解除することができてしまう
以下の説明はたぶんあっていないと思う。PTLC ページを参照したほうがよい。 payer は invoice P を受け取るわけだが、P + (nonce*G) に払うようにする
これができるなら、payer が毎回 invoice を変えているというだから、前述の問題は解決している
しかし payee がこれを受け取れるのか？
two hop を考えてみる
A -- B -- C
A は a,bを作る
B は b を知る
C は s*G=P, (a+b)を知っている
A は B に対して a+(s+nonce) をもとめる
BはCに対して a+b+(s+nonce) をもとめる
B はa+b+(s+nonce) - b で a+(s+nonce) を知ることができる
C は nonce がわかればいい
オンラインになったときに onion message で A は C に nonce を伝えればこれが成立する
支払いが完了したあと、Bは a+b+c+(s+nonce) を知ることになるが、この値はnonce が変わってしまったら使うことはできない
そうすれば LSP を信用しなくても Ok
単にhopに渡す値を毎回変えるだけではだめなのだろうか？
two hop を考えてみる
(１)A - B -C
A は a,b を作る
B は b を知る
C は s*G=P, (a+b)を知っている
A は B に対して a+s をもとめる
BはCに対して a+b+s をもとめる
完了するとBは、b, a+s を知っていることになる
(2)このときに二回目の支払いをする
A は a',b' をつくる
B は b' を知る
C は s*G=P, (a'+b')を知っている
A は B に対して a'+s をもとめる
このとき、以前の情報(b, a+s) を使って、 a'+s を知ることができるか？
できるならだめ
できるの？？？？
いまの HTLC でも、payee が生成する preimage に加えて payer がランダムに生成する値を HTLC の unlock 条件にすればいいのでは by ZmnSCPxj そうだけど、結局プロトコルレベルでの変更が必要だから PTLC すればいいよね
PTLC では Proof-of-Payment ができない
payee が生成する preimage を知っていることが PoP であるが、PTLC では秘密鍵 s にあたり、これは毎回同じ。これが毎回同じでも盗むことができないのが PTLC のいいところではあるが、s は毎回同じなので PoP にはならない
client - LSP - LSP - client ではなくて、client - client server - client server - client にすればいいのでは？
LSP が invoice を発行する問題を解決できる方法が見つけられそう
不正を防ぎつつ、事前に invoice をサーバーに登録しておける方法はないか？
adoptor を作成する input として、payer が作成するメッセージを使うことで、adoptor に対応する署名がすなわちメッセージへの署名となり、payer が受け取った証明となる