From e524093d154d4d154e397e98e8ea00581877aa65 Mon Sep 17 00:00:00 2001 From: Rene Pickhardt Date: Wed, 7 Aug 2019 15:50:56 +0200 Subject: [PATCH] included feedback by Rusty to check the max_concurrent_htlc value for both peers of a channel --- channeld/full_channel.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/channeld/full_channel.c b/channeld/full_channel.c index 4ec343c54dda..190dd844859f 100644 --- a/channeld/full_channel.c +++ b/channeld/full_channel.c @@ -367,6 +367,7 @@ static enum channel_add_err add_htlc(struct channel *channel, enum side sender = htlc_state_owner(state), recipient = !sender; const struct htlc **committed, **adding, **removing; const struct channel_view *view; + u32 min_concurrent_htlcs; htlc = tal(tmpctx, struct htlc); @@ -443,8 +444,16 @@ static enum channel_add_err add_htlc(struct channel *channel, * HTLCs to its local commitment transaction... * - SHOULD fail the channel. */ + /* Also we should not add more htlc's than sender or recipient + * configured. This mitigates attacks in which a peer can force the + * funder of the channel to pay unnecessary onchain fees during a fee + * spike with large commitment transactions. + */ + min_concurrent_htlcs = channel->config[recipient].max_accepted_htlcs; + if (min_concurrent_htlcs > channel->config[sender].max_accepted_htlcs) + min_concurrent_htlcs = channel->config[sender].max_accepted_htlcs; 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; }