LN async payment
LN で offline の相手にどうやっておくるか mobile client はしばしばオフラインになる
BOLT12 でアドレスを貼り付けることが可能になっても、オフラインの相手には送れないままである 必要なのか?いまの onion routing では不十分な理由は?
常にオンライン状態でいられる LSP や torampoline server が必要
最初の Hop には大きな CLTV が必要
ロックされて困るのは送信者だが、送るつもりで手放している資金だからそんなに問題にはならないだろう
その後ろの CLTV は小さくする仕組みが必要?いまはできない?
pending HTLC がある状態で channel 閉じるときはどうなる?
いまのinvoiceの仕様を拡張すればいいのでBOLT12を待つ必要性はない
アドレス帳みたいな概念を導入できるようになる
まあいまもできるけど。bolt12 の話題かなこれは
各実装の対応状況は?
PTLC ではなくて keysend を保持しておけばいいだけではという話も 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 を考えてみる
(1)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 を発行する問題を解決できる方法が見つけられそう
adoptor を作成する input として、payer が作成するメッセージを使うことで、adopto に対応する署名がすなわちメッセージへの署名となり、payer が受け取った証明となる