From 63bd16bf28f4e65d736b9bcd53499348e5b6e53d Mon Sep 17 00:00:00 2001 From: Rusty Russell Date: Mon, 12 Dec 2016 11:41:39 +1030 Subject: [PATCH] BOLT 7: specify that we don't have to rebroadcast huge packets. We could spam the network with 64k announcements, and each node has to rememeber them for rebroadcasting. There's a tradeoff between allowing future expansions and this potential DoS, so allow nodes to choose. My current implementation thinking is: each extra byte reduces chance of rebroadcast by a small amount, such that if you're twice the minimum size your chance of rebroadcast hits 0. Signed-off-by: Rusty Russell --- 07-routing-gossip.md | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/07-routing-gossip.md b/07-routing-gossip.md index 2cf9924..b70d3a5 100644 --- a/07-routing-gossip.md +++ b/07-routing-gossip.md @@ -75,7 +75,8 @@ ignore the message. Otherwise, if the transaction referred to was not previously announced as a channel, the receiving node SHOULD queue the message for -rebroadcasting. If it has previously received a valid +rebroadcasting, but MAY choose not to for messages longer than +the minimum expected length. If it has previously received a valid `channel_announcement` for the same transaction in the same block, but different `node-id-1` or `node-id-2`, it SHOULD blacklist the previous message's `node-id-1` and `node-id-2` as well as this @@ -102,6 +103,10 @@ While channels shouldn't be advertised before they are sufficiently deep, the requirement against rebroadcasting only applies if the transaction hasn't moved to a different block. +To avoid having to store excessive-sized messages, yet allow +reasonable expansion in future, nodes are allowed to restrict +rebroadcasting (perhaps statistically). + New channel features are possible in future; backwards compatible (or optional) ones will have odd feature bits, incompatible ones will have even feature bits. These will be propagated by nodes even if they @@ -160,7 +165,8 @@ previously known from a `channel_announcement` message, or if `node_announcement` from this `node-id`. Otherwise, if the `timestamp` is greater than the last-received `node_announcement` from this `node-id` the receiving node SHOULD queue the message for -rebroadcasting. +rebroadcasting, but MAY choose not to for messages longer than +the minimum expected length. The receiving node SHOULD NOT connect to a node which has an unknown `feature` bit set in the `node_announcement` which is even. @@ -231,7 +237,8 @@ this channel and node-id. Otherwise, if the `timestamp` is equal to the last-received `channel_announcement` and the fields other than `signature` differ, the node MAY blacklist this node-id and forget all channels associated with it. Otherwise the receiving node SHOULD -queue the message for rebroadcasting. +queue the message for rebroadcasting, but MAY choose not to for +messages longer than the minimum expected length. ## Rebroadcasting