LN async payment

mobile client はしばしばオフラインになる

必要なのか？いまの onion routing では不十分な理由は？

常にオンライン状態でいられる LSP や torampoline server が必要

最初の Hop には大きな CLTV が必要

ロックされて困るのは送信者だが、送るつもりで手放している資金だからそんなに問題にはならないだろう

その後ろの CLTV は小さくする仕組みが必要？いまはできない？

pending HTLC がある状態で channel 閉じるときはどうなる？

いまのinvoiceの仕様を拡張すればいいのでBOLT12を待つ必要性はない

アドレス帳みたいな概念を導入できるようになる

まあいまもできるけど。bolt12 の話題かなこれは

各実装の対応状況は？

LSP 同士が合意して、送り先が offline だったら、送り元の LSP で止めておく仕様が考えられる

invoice を事前に複数発行しておいて、LSP にそれを使ってもらう

ただし invoice を使いまわすと LSP が盗むことができてしまうので、LSP を信用する必要がある

ある preimageAから作成された invoice で一度支払いをうけると、LSP は preimageA を知ることになる

次の async payment 時に、同じ invoice を使うと、すでに preimageA を知っているため、edge への送金をして preimage を手に入れなくても、HTLC を解除することができてしまう

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 を知ることができるか？

できるならだめ

できるの？？？？

そうだけど、結局プロトコルレベルでの変更が必要だから 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 が受け取った証明となる