mirrors/lightning-bolts
1
0
Fork 0
mirror of https://github.com/lightning/bolts.git synced 2024-11-19 01:50:03 +01:00
Code Issues Projects Releases Wiki Activity

BOLT 7: specify that we don't have to rebroadcast huge packets.

Browse Source 
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 <rusty@rustcorp.com.au>
This commit is contained in:
Rusty Russell 2016-12-12 11:41:39 +10:30
parent 83d918a4a1
commit 63bd16bf28
1 changed files with 10 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
07-routing-gossip.md
View File

@ -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