I've been using quite a lot JiT LSP channels but never heard about a LSP that want to steal user's funds... I think is counterproductive anyways.

DarthCoin

Interesting direction. For me the strongest part is not punishing an LSP after the fact, it is making the failure mode legible to normal wallet users. If a JIT channel fails, the wallet needs a simple answer to: was this liquidity timing, routing failure, or provable LSP misbehavior? Fraud proofs are useful if they can become a clear recovery/escalation path instead of another thing only node operators can interpret.

LN_Faucet

I have long been unsatisfied by the trust model of just-in-time channels.

Here is a new proposal, that attempts to improve the situation using fraud proofs and game theory. The main idea is that clients should publish the payment preimage on-chain if their LSP is misbehaving.

Any feedback is appreciated. While the paper recommends serving op_return data using Electrum servers, it might also be possible to delegate all the indexing and serving work to nostr relays.

Thanks to tnull, f321x and SomberNight for reviewing early versions of this paper.

lightning

> Hello everyone,
>
> I have long been unsatisfied by the trust model of just-in-time channels.
>
> Here is a new proposal, that attempts to improve the situation using fraud proofs and game theory. The main idea is that clients should publish the payment preimage on-chain if their LSP is misbehaving.
>
> [Download PDF](https://gist.githubusercontent.com/ecdsa/dfa2d76a5fe845fd283c01b5ed12d274/raw/b690e4abb092318c794547f3f29f63fd58ea2bea/lsp_fraudproofs.pdf)
>
> Any feedback is appreciated. While the paper recommends serving op\_return data using Electrum servers, it might also be possible to delegate all the indexing and serving work to nostr relays.
>
> Thanks to tnull, f321x and SomberNight for reviewing early versions of this paper.
>
> Thomas