BOLT7: Allow channel_updates for non-public channels#193
BOLT7: Allow channel_updates for non-public channels#193rustyrussell merged 2 commits intolightning:masterfrom
Conversation
|
Should a receiving node enable initial routing sync if it wants to receive these special |
07-routing-gossip.md
Outdated
| to indicate which end this is. It can do this multiple times, if | ||
| it wants to change fees. | ||
|
|
||
| A node MAY still create a `channel_update` to communicate the channel parameters to the other endpoint, even though the channel has not been announced, e.g., because the `channels_public` bit was not set. |
There was a problem hiding this comment.
MUST. Otherwise, the poor node is unable to receive payments :(
There was a problem hiding this comment.
Well, it's only in that direction, isn't it? If the node is a deadend it can also just not send the channel_update since the other side cannot possibly route a payment through it 😉
|
@btcontract Yes, as written. For post 1.0, we'll have a more sophisticated filtering mechanism for route updates, but for the moment it's all or nothing. We could make an exception here, but I'd prefer to get the filtering mechanism in place instead.... |
|
@rustyrussell my worry is that handling these initial syncs may become infeasible very fast for a lite client. Guess it's irrelevant if improved update mechanisms are expected to come soon after 1.0 but if not then having such an exception would be nice. |
|
The initial sync only relates to the initial dump of old announcements, not the updates that come in while the connection is up and running. This |
07-routing-gossip.md
Outdated
| not correspond to a previously | ||
| known, unspent channel from `channel_announcement`, otherwise the `node_id` | ||
| is taken from the `channel_announcement`: `node_id_1` if least-significant bit of flags is 0 or `node_id_2` otherwise. | ||
| The receiving nodes MUST ignore the `channel_update` if it does not correspond to one of its own channels, if it the `short_channel_id` does not match a previous `channel_announcement`, or the channel has been closed in the meantime. |
b50a02b to
015e985
Compare
This was pointed out by @btcontract in lightning#188: we need to communicate our forwarding parameters even for private channels since otherwise the other endpoint cannot use the private channel for incoming routes. So we also accept `channel_update`s for our own channels even for channels that were not announced publicly. Adds a bit of special handling for our own channels in the gossip, but it is needed since private channels would be completely unusable otherwise.
This was changed a while ago, but not reflected here.
015e985 to
c988826
Compare
|
Force-pushed rebase and typo fix. |
This was pointed out by @btcontract in #188: we need to communicate
our forwarding parameters even for private channels since otherwise
the other endpoint cannot use the private channel for incoming
routes. So we also accept
channel_updates for our own channels evenfor channels that were not announced publicly. Adds a bit of special
handling for our own channels in the gossip, but it is needed since
private channels would be completely unusable otherwise.
Fixes #188