Published on: 2023-05-10T12:52:56+00:00
One of the concerns raised regarding Lightning Service Providers (LSP) and their clients is the issue of trust. In order to minimize trust, a third party is needed to ensure that neither the LSP nor the client cheats or steals from each other. The blockchain is the ideal trusted third party, but other options such as Liquid, a custodial solution that requires trust in a federation, can also be considered.To address the trust issue, several mitigations have been proposed. One option is for the LSP to issue a promise to confirm a 0-conf funding transaction before a certain target block height. The client can then refuse to send channel_ready until this promise is issued. Alternatively, the client can wait for the funding transaction to appear on its local mempool before sending channel_ready. Another proposal, known as the benthecarman proposal, involves the client trusting the LSP. Lastly, the LSP can wait for the client to provide the preimage before broadcasting the funding transaction, which requires the client to trust the LSP.The Open LSP Specifications group prefers the "LSP trusts client" model due to the potential vulnerability of LSPs being targeted for attacks. For example, a hacker could manipulate an LSP's behavior to harm the client if the "client trusts LSP" model is adopted. However, the only fully "LSP trusts client" scheme involves the LSP issuing a cryptographically verifiable promise to get the funding transaction confirmed by a later block height. This scheme has generated controversy among LSP participants.Another concern raised by benthecarman is the possibility of griefing attacks on Just-In-Time channels provided by LSPs. The client can exploit the inbound PTLC (Payment Time-Locked Contract) of the LSP, forcing the LSP to take on-chain actions to prevent giving away a free channel. To address this, PTLCs were proposed, where the LSP signs the funding transaction using adaptor signatures locked to the same secret as the invoice. However, it was noted that PTLCs do not completely solve the problem, as either the client or the LSP has to move first and there needs to be an arbiter to ensure that both parties fulfill their promises.In a conversation with Tony Giorgio, Ben Carman highlighted a potential griefing attack on LSPs providing Just-In-Time channels. The attack occurs when the client receives payment but cannot claim it after the LSP opens a 0-conf channel, resulting in the LSP not getting paid and the client obtaining a free inbound lightning channel. To address this issue, Ben suggests using PTLCs. Instead of broadcasting the funding transaction, the LSP signs it using adaptor signatures locked to the same secret as the invoice. This allows for an atomic process where the client can claim the funds and open the channel simultaneously, preventing griefing. However, ghost43 raises a concern about the client waiting for the PTLC held by the LSP to expire before broadcasting the funding transaction. To prevent this, the LSP would need to actively double-spend the channel funding transaction close to its expiration. While this incurs mining fees, the conflicting transaction could potentially be useful if the LSP has sufficient users and traffic.Overall, the use of PTLCs is proposed as a solution to mitigate trust issues and prevent griefing attacks on LSPs providing Just-In-Time channels. However, further discussions and considerations are needed to address the potential drawbacks and controversies surrounding these proposals.
Updated on: 2023-08-01T01:12:59.401988+00:00