Proposed changes to the splicing specification



Summary:

In a message directed to ariard and t-bast, ZmnSCPxj suggested a proposal for cases where an LSP is doing splice-in while the other side is a client of that LSP. The proposal, found on Github, was designed for 0-conf channel funding but can also be used when there is double-spend risk from an LSP and the client wants to protect against it. This protocol can be applied to splice-in and channel factory construction with the promise that the LSP will do its best to get the transaction confirmed before a future blockheight so that the client can rely on it being confirmed later.However, ZmnSCPxj pointed out that this proposal is risky for the LSP because the LSP is held liable if the TXID never confirms. Even if the client has given revocation keys for all states dependent on the previous funding txo, the client can still post and confirm a revoked state, which prevents the LSP from ever getting the splice TXID confirmed. As a result, the client loses all its funds in the channel while the LSP's reputation is destroyed.


Updated on: 2023-06-03T12:31:00.025474+00:00