Author: ZmnSCPxj 2023-05-10 00:00:27
Published on: 2023-05-10T00:00:27+00:00
In a Lightning-dev mailing list, benthecarman brought up a possible griefing attack on Just-In-Time channels provided by LSPs. The client could wait out the inbound PTLC of the LSP and force the LSP to perform an on-chain action to prevent giving a channel for free. To fix this, PTLCs were proposed, where instead of broadcasting the funding transaction to the mempool, the LSP can sign the funding transaction using adaptor signatures locked to the same secret as the invoice. However, SomberNight noted that PTLCs do not solve the problem entirely. Either the client or the LSP has to move first, but the only way they can assure that the other will actually do what they promised is if there is some arbiter who can ensure that the second mover actually performs their move. The default arbiter is the blockchain layer itself, but 0-conf just wants to avoid the blockchain layer for being too slow. Another wrinkle is that the LSP can attempt to coordinate with a miner (via e.g. full-RBF) to double-spend the funding transaction after the client has broadcasted the signed funding transaction on the mempool.
Updated on: 2023-06-03T13:02:23.444473+00:00