ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2023-05-09 🗒️ Summary of this message: A potential ...
📅 Original date posted:2023-05-09
🗒️ Summary of this message: A potential issue with using PTLCs to prevent free channels in Lightning Network is that clients can wait out the inbound PTLC, forcing the LSP to perform an onchain action. Additionally, the LSP can coordinate with a miner to double-spend the funding transaction after the client has broadcasted it.
📝 Original message:
Good morning benthecarman and SomberNight,
As noted by SomberNight, PTLCs does not quite fix this, as the client can still wait out the inbound PTLC of the LSP and force the LSP to perform an onchain action to ensure it does not give a channel for free.
Another wrinkle here 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 (i.e. lets the LSP learn the scalar that unlocks the inbound HTLC).
Assuming the LSP uses one large UTXO to fund a smaller channel, the funding transaction has one input, two outputs.
The clawback transaction (spending the same UTXO but returning it back to the LSP control) that the LSP coordinates with a miner would be one input, one output, thus having a size advantage.
As the funding transaction pays some fixed fee --- whose value presumably is paid for in the JIT channel open via the inbound PTLC that arrives at the LSP --- the clawback transaction can pay the exact same fixed fee, but being smaller by one output, has a better feerate and thus a miner would prefer it.
Either client or the LSP has to move first.
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.
Regards,
ZmnSCPxj
Sent with Proton Mail secure email.
------- Original Message -------
On Tuesday, May 9th, 2023 at 9:10 PM, SomberNight via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:
> 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 benthecarman at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
🗒️ Summary of this message: A potential issue with using PTLCs to prevent free channels in Lightning Network is that clients can wait out the inbound PTLC, forcing the LSP to perform an onchain action. Additionally, the LSP can coordinate with a miner to double-spend the funding transaction after the client has broadcasted it.
📝 Original message:
Good morning benthecarman and SomberNight,
As noted by SomberNight, PTLCs does not quite fix this, as the client can still wait out the inbound PTLC of the LSP and force the LSP to perform an onchain action to ensure it does not give a channel for free.
Another wrinkle here 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 (i.e. lets the LSP learn the scalar that unlocks the inbound HTLC).
Assuming the LSP uses one large UTXO to fund a smaller channel, the funding transaction has one input, two outputs.
The clawback transaction (spending the same UTXO but returning it back to the LSP control) that the LSP coordinates with a miner would be one input, one output, thus having a size advantage.
As the funding transaction pays some fixed fee --- whose value presumably is paid for in the JIT channel open via the inbound PTLC that arrives at the LSP --- the clawback transaction can pay the exact same fixed fee, but being smaller by one output, has a better feerate and thus a miner would prefer it.
Either client or the LSP has to move first.
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.
Regards,
ZmnSCPxj
Sent with Proton Mail secure email.
------- Original Message -------
On Tuesday, May 9th, 2023 at 9:10 PM, SomberNight via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:
> 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 benthecarman at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev