I worry that this is an understated risk in lightning for routing nodes. I’m not even sure if lnd exposes this as an option at channel open.

Shorter timeouts on HTLCs means that if you route an htlc that is a large % of a channel, you could be putting that amount at risk.

If you go down while an HTLC you are forwarding is pending, you could end up missing the preimage. If you don’t come back in time, you could find yourself in a situation where your outbound HTLC has been claimed by one peer via preimage and your inbound htlc has been claimed by the other via the CLTV timeout.

In effect, you would have unintentionally donated your money for the benefit of the original payment sender :)

#[0]

Reply to this note

Please Login to reply.

Discussion

This is also a good example of how the devs intended the thing to be used vs how the users actually use it. It’s very common on LN to vary your max_htlc based on liquidity to signal to senders what sort of payment will go through. This popularized by the great but dearly missed Zero Fee Routing

Lnd allows you to set both max_value_in_flight and remote_max_value_in_flight_msat per channel. Is that what you’re talking about? Both set “the maximum amount of coins in millisatoshis that can be pending in this channel.”

Yes, was searching for this within LND, wondering what the default is? The spec calls it max_htlc_value_in_flight_msat

Afk but can check later. What default would you consider proper?

Doing some work to figure out what will work best for us, and I suspect it may be different across use cases. Hadn’t thought about this setting from this pov until recently.

Default is “the maximum msats worth of HTLCs that can be pending (or in-flight) on our side of the channel.” And `lncli openchannel —remote_max_value_in_flight_msat` allows you to adjust beyond that default upon channel open.

https://github.com/lightningnetwork/lnd/commit/a66a1e113fb04912ac2e8ae62446bce8fed8d12a

I’m here for it! Doesn’t change this particular issue tho