From bfe9032ff3f87f84853b86dc25f9b7e8b2529052 Mon Sep 17 00:00:00 2001 From: ugamkamat <46383951+ugamkamat@users.noreply.github.com> Date: Sun, 16 Jun 2019 14:21:54 +0530 Subject: [PATCH 01/11] Update 07-routing-gossip.md While going through the BOLT #7 I was confused by this receiving node requirement for `channel_update` message: "if the `timestamp` is equal to the last-received `channel_update` AND the fields (other than `signature`) differ: MAY blacklist this `node_id`; MAY forget all channels associated with it." On the outset it might read to "`timestamp` should be same, the `signature` should be same as previous but if the other data is different; then blacklist the `node_id`". However, if `signature` is same as previous update but data is different, then the `signature` would be rendered invalid. And since `signature` check is done prior to the `timestamp` check, this situation of checking may not arise. So this check seems to be redundant. However, Mark H corrected me on stackexchange (https://bitcoin.stackexchange.com/questions/88350/bolt-7-can-receiving-node-requirements-in-channel-update-message-give-rise-to) by saying that a valid signature must be provided for this update and timestamp to go through. This pull request corrects the language behind this check. While creating this pull request, I also noticed a slight typo in the same section. The sentence prior to the one I mentioned above says that if the timestamp is not greater than the previous message, the node should ignore the message. And the second sentence is about comparing if timestamp is equal. But again, this check might not be processed as the message will be discarded if it is not greater. I have changed that to "greater than or equal to". --- 07-routing-gossip.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/07-routing-gossip.md b/07-routing-gossip.md index 80116eef2..40ceb550b 100644 --- a/07-routing-gossip.md +++ b/07-routing-gossip.md @@ -494,12 +494,12 @@ The receiving node: - if the specified `chain_hash` value is unknown (meaning it isn't active on the specified chain): - MUST ignore the channel update. - - if `timestamp` is NOT greater than that of the last-received + - if `timestamp` is NOT greater than OR equal to that of the last-received `channel_update` for this `short_channel_id` AND for `node_id`: - SHOULD ignore the message. - otherwise: - - if the `timestamp` is equal to the last-received `channel_update` - AND the fields (other than `signature`) differ: + - if the `timestamp` is equal to the last-received `channel_update`, + AND the fields differ (with a valid `signature` for the message): - MAY blacklist this `node_id`. - MAY forget all channels associated with it. - if the `timestamp` is unreasonably far in the future: From 59c5175de246b5c5638521bc3c58a010b58fde6d Mon Sep 17 00:00:00 2001 From: ugamkamat <46383951+ugamkamat@users.noreply.github.com> Date: Sun, 16 Jun 2019 19:19:07 +0530 Subject: [PATCH 02/11] BOLT #7 : Receiving node requirements related to timestamp for channel_update message While going through the BOLT #7 I was confused by this receiving node requirement for `channel_update` message: "if the `timestamp` is equal to the last-received `channel_update` AND the fields (other than `signature`) differ: MAY blacklist this `node_id`; MAY forget all channels associated with it." On the outset it might read to "`timestamp` should be same, the `signature` should be same as previous but if the other data is different; then blacklist the `node_id`". However, if `signature` is same as previous update but data is different, then the `signature` would be rendered invalid. And since `signature` check is done prior to the `timestamp` check, this situation of checking may not arise. So this check seems to be redundant. However, Mark H corrected me on stackexchange (https://bitcoin.stackexchange.com/questions/88350/bolt-7-can-receiving-node-requirements-in-channel-update-message-give-rise-to) by saying that a valid signature must be provided for this update and timestamp to go through. This pull slightly corrects the language behind this check and adds a paragraph in the rationale to explain that point. While creating this pull request, I also noticed a slight typo in the same section. The sentence prior to the one I mentioned above says that if the timestamp is not greater than the previous message, the node should ignore the message. And the second sentence is about comparing if timestamp is equal. But again, the equal to check might not be processed as the message will be discarded if it is not greater. I have changed that to "greater than or equal to". --- 07-routing-gossip.md | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/07-routing-gossip.md b/07-routing-gossip.md index 40ceb550b..92390ae78 100644 --- a/07-routing-gossip.md +++ b/07-routing-gossip.md @@ -498,8 +498,8 @@ The receiving node: `channel_update` for this `short_channel_id` AND for `node_id`: - SHOULD ignore the message. - otherwise: - - if the `timestamp` is equal to the last-received `channel_update`, - AND the fields differ (with a valid `signature` for the message): + - if the `timestamp` is equal to the last-received `channel_update` for this + `short_channel_id` AND `node_id`, AND the fields below `timestamp` differ: - MAY blacklist this `node_id`. - MAY forget all channels associated with it. - if the `timestamp` is unreasonably far in the future: @@ -524,6 +524,13 @@ makes sense to have it be a UNIX timestamp (i.e. seconds since UTC 1970-01-01). This cannot be a hard requirement, however, given the possible case of two `channel_update`s within a single second. +It is assumed that more than one `channel_update` message changing the channel +parameters in the same second is a DoS attempt, and therefore, the node responsible +for signing such messages ought to be blacklisted. However, a node can send a same +`channel_update` message with a different signature (changing the nonce in signature +signing), and hence fields apart from signature are checked to see if the channel +parameters have changed for the same timestamp. + The explicit `option_channel_htlc_max` flag to indicate the presence of `htlc_maximum_msat` (rather than having `htlc_maximum_msat` implied by the message length) allows us to extend the `channel_update` From fc10d2513f42f9a1dca4402281800f120d0a98e2 Mon Sep 17 00:00:00 2001 From: ugamkamat <46383951+ugamkamat@users.noreply.github.com> Date: Mon, 17 Jun 2019 21:34:20 +0530 Subject: [PATCH 03/11] Update 07-routing-gossip.md Co-Authored-By: Bastien Teinturier <31281497+t-bast@users.noreply.github.com> --- 07-routing-gossip.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/07-routing-gossip.md b/07-routing-gossip.md index 92390ae78..59f791f6c 100644 --- a/07-routing-gossip.md +++ b/07-routing-gossip.md @@ -525,7 +525,7 @@ makes sense to have it be a UNIX timestamp (i.e. seconds since UTC of two `channel_update`s within a single second. It is assumed that more than one `channel_update` message changing the channel -parameters in the same second is a DoS attempt, and therefore, the node responsible +parameters in the same second may be a DoS attempt, and therefore, the node responsible for signing such messages ought to be blacklisted. However, a node can send a same `channel_update` message with a different signature (changing the nonce in signature signing), and hence fields apart from signature are checked to see if the channel From 7373ccd1a00414c9fdb2fbdb46233ced570126a0 Mon Sep 17 00:00:00 2001 From: ugamkamat <46383951+ugamkamat@users.noreply.github.com> Date: Mon, 17 Jun 2019 21:34:29 +0530 Subject: [PATCH 04/11] Update 07-routing-gossip.md Co-Authored-By: Bastien Teinturier <31281497+t-bast@users.noreply.github.com> --- 07-routing-gossip.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/07-routing-gossip.md b/07-routing-gossip.md index 59f791f6c..dbed37a58 100644 --- a/07-routing-gossip.md +++ b/07-routing-gossip.md @@ -526,7 +526,7 @@ of two `channel_update`s within a single second. It is assumed that more than one `channel_update` message changing the channel parameters in the same second may be a DoS attempt, and therefore, the node responsible -for signing such messages ought to be blacklisted. However, a node can send a same +for signing such messages may be blacklisted. However, a node can send a same `channel_update` message with a different signature (changing the nonce in signature signing), and hence fields apart from signature are checked to see if the channel parameters have changed for the same timestamp. From 536b8f5a31f6e8542127c982bccc9eff94d6c9af Mon Sep 17 00:00:00 2001 From: ugamkamat <46383951+ugamkamat@users.noreply.github.com> Date: Mon, 17 Jun 2019 21:38:25 +0530 Subject: [PATCH 05/11] Update 07-routing-gossip.md --- 07-routing-gossip.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/07-routing-gossip.md b/07-routing-gossip.md index dbed37a58..20175ecaf 100644 --- a/07-routing-gossip.md +++ b/07-routing-gossip.md @@ -494,7 +494,7 @@ The receiving node: - if the specified `chain_hash` value is unknown (meaning it isn't active on the specified chain): - MUST ignore the channel update. - - if `timestamp` is NOT greater than OR equal to that of the last-received + - if `timestamp` is lower than that of the last-received `channel_update` for this `short_channel_id` AND for `node_id`: - SHOULD ignore the message. - otherwise: From c7dd689cb657851b99c6ef4494c0da964a0f3699 Mon Sep 17 00:00:00 2001 From: ugamkamat <46383951+ugamkamat@users.noreply.github.com> Date: Sun, 23 Jun 2019 23:20:13 +0530 Subject: [PATCH 06/11] Update 07-routing-gossip.md --- 07-routing-gossip.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/07-routing-gossip.md b/07-routing-gossip.md index 20175ecaf..a1d1a71c6 100644 --- a/07-routing-gossip.md +++ b/07-routing-gossip.md @@ -526,10 +526,14 @@ of two `channel_update`s within a single second. It is assumed that more than one `channel_update` message changing the channel parameters in the same second may be a DoS attempt, and therefore, the node responsible -for signing such messages may be blacklisted. However, a node can send a same +for signing such messages may be blacklisted. However, a node may send a same `channel_update` message with a different signature (changing the nonce in signature signing), and hence fields apart from signature are checked to see if the channel -parameters have changed for the same timestamp. +parameters have changed for the same timestamp. It is also important to note that +ECDSA signatures are malleable. So, an intermediatary node who received the `channel_update` +message can rebroadcast it just by changing the `s` component of signature with `-s`. +This should however not result in the blacklist of the `node_id` from where +the message originated. The explicit `option_channel_htlc_max` flag to indicate the presence of `htlc_maximum_msat` (rather than having `htlc_maximum_msat` implied From 50913b435a75c1fd134e98ee27858cb18a29293d Mon Sep 17 00:00:00 2001 From: ugamkamat <46383951+ugamkamat@users.noreply.github.com> Date: Sun, 23 Jun 2019 23:28:33 +0530 Subject: [PATCH 07/11] Update 07-routing-gossip.md --- 07-routing-gossip.md | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/07-routing-gossip.md b/07-routing-gossip.md index a1d1a71c6..df559cd40 100644 --- a/07-routing-gossip.md +++ b/07-routing-gossip.md @@ -499,9 +499,12 @@ The receiving node: - SHOULD ignore the message. - otherwise: - if the `timestamp` is equal to the last-received `channel_update` for this - `short_channel_id` AND `node_id`, AND the fields below `timestamp` differ: - - MAY blacklist this `node_id`. - - MAY forget all channels associated with it. + `short_channel_id` AND `node_id`, + - if the fields below `timestamp` differ: + - MAY blacklist this `node_id`. + - MAY forget all channels associated with it. + - if the fields below `timestamp` are equal: + - SHOULD ignore this message - if the `timestamp` is unreasonably far in the future: - MAY discard the `channel_update`. - otherwise: From ca9e7bdb730201c055ed32d3fe6db378469583c1 Mon Sep 17 00:00:00 2001 From: ugamkamat <46383951+ugamkamat@users.noreply.github.com> Date: Sun, 23 Jun 2019 23:32:50 +0530 Subject: [PATCH 08/11] Update 07-routing-gossip.md --- 07-routing-gossip.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/07-routing-gossip.md b/07-routing-gossip.md index df559cd40..1bc59bc6d 100644 --- a/07-routing-gossip.md +++ b/07-routing-gossip.md @@ -499,12 +499,12 @@ The receiving node: - SHOULD ignore the message. - otherwise: - if the `timestamp` is equal to the last-received `channel_update` for this - `short_channel_id` AND `node_id`, + `short_channel_id` AND `node_id`, + - if the fields below `timestamp` are equal: + - SHOULD ignore this message - if the fields below `timestamp` differ: - MAY blacklist this `node_id`. - MAY forget all channels associated with it. - - if the fields below `timestamp` are equal: - - SHOULD ignore this message - if the `timestamp` is unreasonably far in the future: - MAY discard the `channel_update`. - otherwise: From 2393f3a4bf0be88d4c8826fab75b248e8854f4c1 Mon Sep 17 00:00:00 2001 From: ugamkamat <46383951+ugamkamat@users.noreply.github.com> Date: Mon, 24 Jun 2019 00:38:12 +0530 Subject: [PATCH 09/11] Update 07-routing-gossip.md --- 07-routing-gossip.md | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/07-routing-gossip.md b/07-routing-gossip.md index 1bc59bc6d..a2fd466d0 100644 --- a/07-routing-gossip.md +++ b/07-routing-gossip.md @@ -494,17 +494,18 @@ The receiving node: - if the specified `chain_hash` value is unknown (meaning it isn't active on the specified chain): - MUST ignore the channel update. + - if the `timestamp` is equal to the last-received `channel_update` for this + `short_channel_id` AND `node_id`: + - if the fields below `timestamp` differ: + - MAY blacklist this `node_id`. + - MAY forget all channels associated with it. + - if the fields below `timestamp` are equal: + - SHOULD ignore this message - if `timestamp` is lower than that of the last-received `channel_update` for this `short_channel_id` AND for `node_id`: - SHOULD ignore the message. - otherwise: - - if the `timestamp` is equal to the last-received `channel_update` for this - `short_channel_id` AND `node_id`, - - if the fields below `timestamp` are equal: - - SHOULD ignore this message - - if the fields below `timestamp` differ: - - MAY blacklist this `node_id`. - - MAY forget all channels associated with it. + - if the `timestamp` is unreasonably far in the future: - MAY discard the `channel_update`. - otherwise: From 8554d5c9723dfa76357a8981823b68f202ae6e1d Mon Sep 17 00:00:00 2001 From: ugamkamat <46383951+ugamkamat@users.noreply.github.com> Date: Tue, 9 Jul 2019 14:45:51 +0530 Subject: [PATCH 10/11] Update 07-routing-gossip.md Co-Authored-By: Bastien Teinturier <31281497+t-bast@users.noreply.github.com> --- 07-routing-gossip.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/07-routing-gossip.md b/07-routing-gossip.md index a2fd466d0..d9deb2f39 100644 --- a/07-routing-gossip.md +++ b/07-routing-gossip.md @@ -534,7 +534,7 @@ for signing such messages may be blacklisted. However, a node may send a same `channel_update` message with a different signature (changing the nonce in signature signing), and hence fields apart from signature are checked to see if the channel parameters have changed for the same timestamp. It is also important to note that -ECDSA signatures are malleable. So, an intermediatary node who received the `channel_update` +ECDSA signatures are malleable. So, an intermediate node who received the `channel_update` message can rebroadcast it just by changing the `s` component of signature with `-s`. This should however not result in the blacklist of the `node_id` from where the message originated. From 437deba931af5b4be4e4756718dd591f6bcb48cb Mon Sep 17 00:00:00 2001 From: ugamkamat <46383951+ugamkamat@users.noreply.github.com> Date: Tue, 9 Jul 2019 22:59:38 +0530 Subject: [PATCH 11/11] Update .aspell.en.pws Updated for DoS and ECDSA --- .aspell.en.pws | 2 ++ 1 file changed, 2 insertions(+) diff --git a/.aspell.en.pws b/.aspell.en.pws index b1a1ad307..23de54690 100644 --- a/.aspell.en.pws +++ b/.aspell.en.pws @@ -330,3 +330,5 @@ zlib ZLIB APIs duplicative +DoS +ECDSA