<unnamed>

Public Key

npub17lts233cksw942zaqq8kkkgrc8hn9pfzgdyrce28nrf2vx49q7wq3c7hwm

Profile Code

nprofile1qqs004c9gcutg8z64pwsqrmttypurmejs53yxjpuv4re354xr2js08qpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsth0nxy

Publishing to

relay.nostr.net

nos.lol

relay.damus.io

Last Notes

2023-06-19 19:42:32 CEST

- reply

📅 Original date posted:2023-05-09
🗒️ Summary of this message: A potential griefing attack on LSPs providing Just-In-Time channels has been identified. The attack can be prevented by using PTLCs to sign the funding transaction.
📝 Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230509/c7926ee7/attachment.html>

2023-06-09 15:13:23 CEST

- reply

2023-06-09 15:08:53 CEST

- reply

📅 Original date posted:2023-05-09
📝 Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230509/c7926ee7/attachment.html>