reply on: Dissection of a force-close that already cost me 140k sats \ stacker news ~lightning

pull down to refresh

1 sat \ 1 reply \ @south_korea_ln 31 Dec 2023 \ on: Dissection of a force-close that already cost me 140k sats lightning

the HTLC is only worth 13k sats, so paying 140k sats to avoid losing it seems pointless. However, as not claiming timed out HTLCs could lead to peers stealing lots of small-ish amounts, being strict seems to be the better approach overall.

Can you elaborate on this? You mean that if they see you not claiming it once, they might repeat it over and over again until you decide to enforce the timed-out HTLCs?

Did you have the option at some point within LND to make this a conscious choice? Or did this all happen under the hood?

Thanks for the write up by the way.

120 sats \ 0 replies \ @C_Otto OP 31 Dec 2023 freebie

Let's say I tweaked my node (or maybe it's part of an lnd release?) so that force-closes for HTLC timeouts only happen if it's "worth it". In this case, lnd would just fail the payment back to bfx-lnd0, and keep the channel open without the force-close dilemma described here (with the HTLC still pending).

Now, what if my peer is malicious and knows about (or at least assumes) my node's response to the timeout? They could reveal the preimage and claim the funds, effectively "stealing" (I'm not sure if it's real theft, hence the quotes) 11k sats from me. They could do this again and again, possibly hiding behind other pubkeys. Note that bfx-lnd0 would never give the funds to me, because I already failed the payment (and they failed it upstream towards the original sender).

There are tradeoffs, but I believe it's better to have a "it works 100%" atmosphere than "let's just hope my peer isn't a thief" kind of trust dilemma.

I did not tweak lnd, and the "safe" approach is the default. Right now I don't think there's an easy way to use the "unsafe-but-maybe-cheaper" approach.