Added possibility to configure max_concurrent_htlcs value #2858

renepickhardt · 2019-07-28T07:23:44Z

Eclair has a default value of 30 and I thought why not going with their value and while doing so make it configureable.

@cdecker suggested to call the option max_concurrent_htlcs instead of the name in the BOLTs max_concurrent_htlcs

Here is the relevant line in eclair:

https://github.com/ACINQ/eclair/blob/9afb26e09c69dd5d6a14732baf5dcdf2b7a9142b/eclair-core/src/main/resources/reference.conf#L62

ZmnSCPxj

Needs documentation:

diff of command names vs manpage names:
--- /dev/fd/63	2019-07-28 07:26:31.096200068 +0000
+++ /dev/fd/62	2019-07-28 07:26:31.096200068 +0000
@@ -35,7 +35,6 @@
 log-level=
 log-prefix=
 mainnet
-max-concurrent-htlcs=
 max-locktime-blocks=
 min-capacity-sat=
 network=
doc/Makefile:80: recipe for target 'check-manpages' failed

I mildly prefer 483, as we expect (hope?) unilateral closure to be rare.

renepickhardt · 2019-07-29T20:58:19Z

I added an entry to doc/lightningd however I have proplems (like last time I tried to add a manpage) to run a2x even after installing asciidoc

a2x --format=manpage doc/lightningd-config.5.txt
a2x: ERROR: "xmllint" --nonet --noout --valid "/Users/rpickhardt/hacken/tmp/lightning/doc/lightningd-config.5.xml" returned non-zero exit status 4

web search was of no help I guess I am missing some dependencies.

rustyrussell · 2019-07-30T00:36:55Z

This doesn't solve your problem though, as this doesn't restrict how many HTLCs we'll send to a peer, just how many we'll receive.

I would suggest a follow-up patch which caps the sending number to max(what-peer-set, what-our-max-is)?

renepickhardt · 2019-07-30T02:23:09Z

While the first paragraph of your review makes sense to me I am confused by your suggestion for a follow up patch.

Shouldn't it be min(what-peer-set, what-our-max-is) instead of max? Or did you mean what-peer-seNt (in the sense of how many did we received so far)?

In my understanding concurrent htlcs was meant to be offered plus received. So the max would not help here as we would have to check against the current sum in both cases or is there a mistake in my thinking?

renepickhardt · 2019-07-30T20:03:12Z

can't I just modify this line:

lightning/channeld/full_channel.c

Line 451 in 54ce4ed

> channel->config[recipient].max_accepted_htlcs) {

to test channel->config[each_side].max_accepted_htlcs

with LOCAL and REMOTE as values for each_side and take the min of both values or did I miss something in the code base?

rustyrussell · 2019-08-06T04:39:47Z

can't I just modify this line:

lightning/channeld/full_channel.c

Line 451 in 54ce4ed

> channel->config[recipient].max_accepted_htlcs) {

to test channel->config[each_side].max_accepted_htlcs

with LOCAL and REMOTE as values for each_side and take the min of both values or did I miss something in the code base?

Yes, exactly, that would have the same effect.

renepickhardt · 2019-08-07T14:00:40Z

I added the additional patch as @rustyrussell requested and rebased to current master. Think everything should be working now. fyi @cdecker

rustyrussell · 2019-08-08T01:51:28Z

I added an entry to doc/lightningd however I have proplems (like last time I tried to add a manpage) to run a2x even after installing asciidoc
a2x --format=manpage doc/lightningd-config.5.txt
a2x: ERROR: "xmllint" --nonet --noout --valid "/Users/rpickhardt/hacken/tmp/lightning/doc/lightningd-config.5.xml" returned non-zero exit status 4
web search was of no help I guess I am missing some dependencies.

I got this too recently. But Works Now, so I'm adding a simple fixup.

rustyrussell

I've added some fixups for your review @renepickhardt because we're 2 days from rc1 and I'm trying to minimize round-trips across timezones!

If you're happy, either you or I can autosquash them for commit.

rustyrussell · 2019-08-08T01:53:32Z

doc/lightningd-config.5.txt

@@ -205,6 +205,10 @@ Lightning channel and HTLC options
    they're outside this range, we abort their opening attempt.  Note
    that *commit-fee-max* can (should!) be greater than 100.

+*max-concurrent-htlcs*='INTEGER'::
+    Number of HTLCs one channel can handle concurrently. Should be between
+    1 and 483 (default 30).


in each direction. The max possible total will be twice this number. Will add.

rustyrussell · 2019-08-08T01:56:38Z

lightningd/options.c

@@ -928,6 +939,9 @@ static void register_opts(struct lightningd *ld)
 	opt_register_arg("--fee-per-satoshi", opt_set_u32, opt_show_u32,
 			 &ld->config.fee_per_satoshi,
 			 "Microsatoshi fee for every satoshi in HTLC");
+	opt_register_arg("--max-concurrent-htlcs", opt_set_u32, opt_show_u32,
+			 &ld->config.max_concurrent_htlcs,
+			 "Number of HTLCs one channel can handle concurrently. Should be between 1 and 483 (default 30)");


This doesn't quite work:

--max-concurrent-htlcs <arg> Number of HTLCs one channel can handle concurrently. Should be between 1 and 483 (default 30) (default: 0)

because you included a show function, it's used to show the default automagically. However, you only set it in the mainnet config, so it's zero (a very bad number!) for other configs.

30 is a reasonable upper bound to avoid bloating atttacks.

rustyrussell · 2019-08-08T06:21:36Z

check-source got upset because it thought your comment was part of the BOLT quote. Split.

renepickhardt · 2019-08-08T06:35:46Z

I can autosquash that patch to be one commit in about 1 hour and rebase again if necessary so that it is ready to be merged.

I did not know you test for bolt quotes. That is beautiful!

renepickhardt

this all together looks good to me. will autosquash and rebase once more

practicalswift · 2019-08-08T10:23:51Z

Nit: Typo in PR title and commit message. Should be "possibility" :-)

renepickhardt · 2019-08-08T11:19:25Z

am I supposed to change the commit message now?

ZmnSCPxj · 2019-08-08T13:32:07Z

Yes. :)

renepickhardt · 2019-08-08T14:25:07Z

@ZmnSCPxj @practicalswift I can't believe I actually did that (and while so I also fixed configer to configure)

rustyrussell · 2019-08-09T02:29:58Z

Ack b657581

Rebased to squash fixup and fixed your commit msg

…nnels. Eclaire has a default of 30 and I thought why not going with their value and while doing so make it configureable.

… both peers of a channel

rustyrussell · 2019-08-09T03:55:25Z

... and again to fix merge conflict with master...

Ack e524093

SomberNight · 2020-03-27T12:27:05Z

channeld/full_channel.c

 	if (tal_count(committed) - tal_count(removing) + tal_count(adding)
-	    > channel->config[recipient].max_accepted_htlcs) {
+	    > min_concurrent_htlcs) {
 		return CHANNEL_ERR_TOO_MANY_HTLCS;


Seems to me that the spec specifies only counting htlc in one direction (not both) against this limit, further it only specifies comparing against the recipient's constraint.
Obviously you can enforce arbitrary restrictions (stricter than spec) for outgoing HTLCs, but if you enforce stricter restrictions than the spec says for incoming ones and then you force-close when (not if) they are violated by the remote then that's not ideal?

See what eclair does (as above) here:
https://github.com/ACINQ/eclair/blob/eae113f0988069044dc268d8a7f16728563baa5f/eclair-core/src/main/scala/fr/acinq/eclair/channel/Commitments.scala#L216
https://github.com/ACINQ/eclair/blob/eae113f0988069044dc268d8a7f16728563baa5f/eclair-core/src/main/scala/fr/acinq/eclair/channel/Commitments.scala#L259
(check only one direction of HTLCs against only one of the constraints)

Oh, I've just realised that the channel does not actually get force-closed, only the peer gets disconnected from (and then the htlc is not added as it was not committed).
BOLT-02 specifically says "fail the channel" - I guess I had a different interpretation of that...
I mean BOLT-02 sometimes says "fail the connection" and sometimes "fail the channel", but then that means c-lightning considers those both to be identical?
Re the original remark, I guess it's less bad then, but still not ideal.

Note: my comments have been addressed in #4432 which reverted the strict checks for remote behaviour

Actually, only one of the two concerns have been addressed by #4432.
AFAICT c-lightning is still checking the total number of htlcs (sum of both directions) against max_accepted_htlcs, while I think BOLT-02 only specifies to check the number of htlcs the sender offered (so one direction only).
This is means c-lightning is still stricter than e.g. eclair.

lightning/channeld/full_channel.c

Lines 575 to 578 in 9470ea3

if (tal_count(committed) - tal_count(removing) + tal_count(adding)

> channel->config[recipient].max_accepted_htlcs) {

return CHANNEL_ERR_TOO_MANY_HTLCS;

}

Or am I misunderstanding the code here? It seems to me committed, removing, and adding include htlcs in both directions.
@rustyrussell

ZmnSCPxj previously requested changes Jul 29, 2019

View reviewed changes

rustyrussell added this to the 0.7.2 milestone Aug 6, 2019

rustyrussell added the channeld label Aug 6, 2019

renepickhardt force-pushed the max_concurrent_htlc_configurable branch from f775593 to e564b0c Compare August 7, 2019 13:59

rustyrussell approved these changes Aug 8, 2019

View reviewed changes

renepickhardt commented Aug 8, 2019

View reviewed changes

renepickhardt force-pushed the max_concurrent_htlc_configurable branch from c4b4f9b to d959421 Compare August 8, 2019 07:57

renepickhardt force-pushed the max_concurrent_htlc_configurable branch from d959421 to 697c86c Compare August 8, 2019 14:24

renepickhardt changed the title ~~Added possability to configure max_concurrent_htlcs value~~ Added possibility to configure max_concurrent_htlcs value Aug 8, 2019

rustyrussell force-pushed the max_concurrent_htlc_configurable branch 2 times, most recently from 47b73c8 to b657581 Compare August 9, 2019 02:29

renepickhardt added 3 commits August 9, 2019 13:22

Added possibility to configure max_concurrent_htlcs value for our cha…

1628248

…nnels. Eclaire has a default of 30 and I thought why not going with their value and while doing so make it configureable.

doc: Document max-concurrent-htlcs option.

e3af9d3

included feedback by Rusty to check the max_concurrent_htlc value for…

e524093

… both peers of a channel

rustyrussell force-pushed the max_concurrent_htlc_configurable branch from b657581 to e524093 Compare August 9, 2019 03:55

rustyrussell merged commit dfac1d1 into ElementsProject:master Aug 9, 2019

SomberNight reviewed Mar 27, 2020

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Added possibility to configure max_concurrent_htlcs value #2858

Added possibility to configure max_concurrent_htlcs value #2858

renepickhardt commented Jul 28, 2019

ZmnSCPxj left a comment

renepickhardt commented Jul 29, 2019

rustyrussell commented Jul 30, 2019

renepickhardt commented Jul 30, 2019

renepickhardt commented Jul 30, 2019 •

edited

Loading

rustyrussell commented Aug 6, 2019

renepickhardt commented Aug 7, 2019

rustyrussell commented Aug 8, 2019

rustyrussell left a comment

rustyrussell Aug 8, 2019

rustyrussell Aug 8, 2019

rustyrussell commented Aug 8, 2019

renepickhardt commented Aug 8, 2019

renepickhardt left a comment

practicalswift commented Aug 8, 2019

renepickhardt commented Aug 8, 2019

ZmnSCPxj commented Aug 8, 2019

renepickhardt commented Aug 8, 2019

rustyrussell commented Aug 9, 2019 •

edited

Loading

rustyrussell commented Aug 9, 2019 •

edited

Loading

SomberNight Mar 27, 2020 •

edited

Loading

SomberNight Mar 27, 2020 •

edited

Loading

SomberNight Apr 27, 2021

SomberNight Apr 27, 2021

	if (tal_count(committed) - tal_count(removing) + tal_count(adding)
	> channel->config[recipient].max_accepted_htlcs) {
	return CHANNEL_ERR_TOO_MANY_HTLCS;
	}

Added possibility to configure max_concurrent_htlcs value #2858

Added possibility to configure max_concurrent_htlcs value #2858

Conversation

renepickhardt commented Jul 28, 2019

ZmnSCPxj left a comment

Choose a reason for hiding this comment

renepickhardt commented Jul 29, 2019

rustyrussell commented Jul 30, 2019

renepickhardt commented Jul 30, 2019

renepickhardt commented Jul 30, 2019 • edited Loading

rustyrussell commented Aug 6, 2019

renepickhardt commented Aug 7, 2019

rustyrussell commented Aug 8, 2019

rustyrussell left a comment

Choose a reason for hiding this comment

rustyrussell Aug 8, 2019

Choose a reason for hiding this comment

rustyrussell Aug 8, 2019

Choose a reason for hiding this comment

rustyrussell commented Aug 8, 2019

renepickhardt commented Aug 8, 2019

renepickhardt left a comment

Choose a reason for hiding this comment

practicalswift commented Aug 8, 2019

renepickhardt commented Aug 8, 2019

ZmnSCPxj commented Aug 8, 2019

renepickhardt commented Aug 8, 2019

rustyrussell commented Aug 9, 2019 • edited Loading

rustyrussell commented Aug 9, 2019 • edited Loading

SomberNight Mar 27, 2020 • edited Loading

Choose a reason for hiding this comment

SomberNight Mar 27, 2020 • edited Loading

Choose a reason for hiding this comment

SomberNight Apr 27, 2021

Choose a reason for hiding this comment

SomberNight Apr 27, 2021

Choose a reason for hiding this comment

renepickhardt commented Jul 30, 2019 •

edited

Loading

rustyrussell commented Aug 9, 2019 •

edited

Loading

rustyrussell commented Aug 9, 2019 •

edited

Loading

SomberNight Mar 27, 2020 •

edited

Loading

SomberNight Mar 27, 2020 •

edited

Loading