Is there a way to put a max limit on forwarded payment size?

[billygarrison]

Say I have a channel with 1M sats:

• I want to be able provide routing for lots of nodes/payments, so I set my fees low.
• Then someone routes a 500k sat payment through that channel, I earn 2 sats in fees
• I have to pay 500 sats in fees to rebalance the channel

This problem could be solved by setting a max payment size of say 50k sats (if you wanted to target small payments with your routing node).

Not sure if this is possible with c-lightning or allowed under the protocol rules, but just thought I'd ask anyway in case anyone can offer any insights.

[niftynei]

There's two things currently in flight that (sort of) address this. The first is actually the opposite that you want, it'll allow you to set a min_htlc amount on any incoming htlc. #2506

The other, more flexible solution, is a proposed accept_htlc plugin notification event. This would allow a plugin to determine whether or not to accept a proposed htlc at the time of receipt, using any criteria of its choosing (amount proposed, inventory status, etc) #2267.

[billygarrison]

Thanks for sharing those PRs, the accept_htlc is especially interesting.

Could there be negative consequences to rejecting HTLCs on the fly like that? For example, it would look bad to my peers if they see I have high capacity and low fees and then they try to route through me, only to get rejected. A high failure rate like this may cause them to blacklist my node.

Compare this to the min_htlc setting, which I believe would be known by my peers ahead of time, so they would know not to try to route the payment through me.

[mloop1]

Hi Billy,
a question about the "500 sats in fees to rebalance the channel"... what do you use to rebalance?

[billygarrison]

Hi @mloop1, I've created some Python scripts for rebalancing but they still error out most of the time. Still debugging, but I plan to release them when I get them in better condition.

[m-schmoock]

@niftynei

There's two things currently in flight that (sort of) address this. The first is actually the opposite that you want, it'll allow you to set a min_htlc amount on any incoming htlc. #2506

Thats not precisely correct, #2506 will add a min_capacity parameter for new channels being initiated by remote peers. It will not limit htlc forwarding on the lower bound.

[ZmnSCPxj]

Could there be negative consequences to rejecting HTLCs on the fly like that? For example, it would look bad to my peers if they see I have high capacity and low fees and then they try to route through me, only to get rejected. A high failure rate like this may cause them to blacklist my node.

Yes, that could be done. C-lightning only creates a "temporary" ban for each pay command, so that if your node rejects a payment, a remote C-lightning node will not keep trying to pester your node to do so, but other software that is not C-lightning may have longer memories. Older versions of C-lightning would ban your node for 20 seconds, again just temporary.

Plugins to C-lightning may (eventually be able to) change this behavior, too.

I have to pay 500 sats in fees to rebalance the channel

Jit-routing by @renepickhardt (more like "Jit-rebalance") may serve your needs better, though it still needs more infrastructure before we can implement it completely:

1. plugin: Implement the htlc_accepted hook #2267 htlc_accepted hook.
2. Some kind of decent, fee-limited rebalance plugin, rene was working on this.
3. Statistics on forwarding failure; if we know num_fails and num_succeeds of all forwarding attempts, we should only rebalance to support some forward if the fee we pay to rebalance is less than fee_offered * num_succeeds / (num_fails + num_succeeds). May be doable with a hook of some kind.

[ZmnSCPxj]

#2267 provides sufficient functionality to do this already.

[ZmnSCPxj]

Closing, since #2267 implements this (though still needs a separate plugin to actually impose it).