Hi benthecarman, > the LSP can give the funding transaction signed using adaptor sigs to the > client and the client can then decrypt the signatures and broadcast the > transaction. Then the LSP can find the transaction in the mempool and extract > the secret they need to claim the payment
What if, after the client has the funding transaction locally, it waits for the PTLC held by the LSP to time out, i.e. days, and then (the client) broadcasts the funding transaction? The LSP could then no longer claim the PTLC, and it would have paid for the channel-open. To prevent this, the LSP would have to actively double-spend the channel funding tx given to the client when the PTLC is close to expiring, and only after getting the conflict mined can the PTLC be failed. This double-spending would cost mining fees of course (arguably the ~same amount as not doing anything and just letting the channel open). Although perhaps the LSP has enough users and high enough traffic that the conflicting tx itself can be something useful, e.g. another channel-open to another user. ghost43 / SomberNight ------- Original Message ------- On Tuesday, May 9th, 2023 at 19:07, Ben Carman <benthecar...@live.com> wrote: > Hi everyone, > > I was chatting with Tony Giorgio the other day and he made me aware of a > potential griefing attack that is possible today on LSPs that provide > Just-In-Time channels. > > The attack is very simple, when the LSP receives the payment and then opens a > 0-conf channel to the client, the client could not claim the payment thus > resulting in the LSP not getting paid and the client getting a free inbound > lightning channel. The LSP could double spend the transaction but they still > would lose the miner fees and as we are seeing today, that can be very > expensive. > > I am not sure if this has been proposed before but we can fix this with PTLCs! > > Instead of having the LSP just broadcasting the funding transaction to the > mempool, they can sign the funding transaction using adaptor signatures > locked to the same secret as the invoice. Then when the client wants to claim > the funds they can get the funding txid from the LSP, and then do the PTLC > dance with the LSP based on using that funding transaction. If it all goes as > planned the LSP can give the funding transaction signed using adaptor sigs to > the client and the client can then decrypt the signatures and broadcast the > transaction. Then the LSP can find the transaction in the mempool and extract > the secret they need to claim the payment, thus making claiming the payment > and opening the channel atomic so the client can't grief the LSP. > > Not sure if this has been talked about before, if not I think we can throw it > in the ever-growing pile of "PTLCs fixes this". > > Best, > benthecarman _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
