multi: send a channel update with disabled flag set on channel close #1387
Conversation
|
There's a flake on Travis that needs to be addressed first. Will ping once done. |
meshcollider
added
the
channel closing
|
Should be good for review now. |
server.go
Outdated
|
|
||
| pubKey := s.identityPriv.PubKey() | ||
| errChan := s.authGossiper.ProcessLocalAnnouncement(update, pubKey) | ||
| return <-errChan |
There was a problem hiding this comment.
select on quit as well
peer.go
Outdated
| // disableChannel disables a channel, resulting in it not being able to forward | ||
| // payments. This is done by sending a new channel update across the network | ||
| // with the disabled flag set. | ||
| func disableChannel(s *server) func(wire.OutPoint) error { |
There was a problem hiding this comment.
this currying can be avoided by just having the server as the receiver
func (s *server) disableChannel(op *wire.OutPoint) errorthen can pass the function around as s.disableChannel
lnd_test.go
Outdated
| @@ -801,6 +801,9 @@ func checkChannelPolicy(policy, expectedPolicy *lnrpc.RoutingPolicy) error { | |||
| expectedPolicy.TimeLockDelta, | |||
| policy.TimeLockDelta) | |||
| } | |||
| if policy.Disabled != expectedPolicy.Disabled { | |||
| return errors.New("edge should be disable but isn't") | |||
wpaulino
force-pushed
the
send-disable-chan-update
branch
from
356ebda
to
c3c6efb
Compare
Roasbeef
added
P2
In this commit, we modify the graph topology notifications test to wait until a graph update notification has been received for a closed channel, rather than assume the next graph update will be for the closed channel itself.
wpaulino
force-pushed
the
send-disable-chan-update
branch
from
c3c6efb
to
7bc9eb9
Compare
There was a problem hiding this comment.
I'm wondering if we can send out disable messages even more aggressively. Could we disable the channel every time it is removed from the switch (as this is the point it cannot route payments anymore), and enable it when it is added?
Not sure if this would lead to unnecessary spam on them network, but it would also help by disabling channels for offline nodes. Or would this be leak any sensitive information? (I don't think so, as it is fairly easy to ping a node to see if it's offline anyway).
Thoughts? cc @Roasbeef @cfromknecht
| @@ -78,6 +78,10 @@ type chanCloseCfg struct { | |||
| // broadcastTx broadcasts the passed transaction to the network. | |||
| broadcastTx func(*wire.MsgTx) error | |||
|
|
|||
| // disableChannel disables a channel, resulting in it not being able to | |||
| // forward payments. | |||
| disableChannel func(wire.OutPoint) error | |||
There was a problem hiding this comment.
why not just disable the channel in unregisterChannel?
|
Not really a fan of disabling the channel each time a peer connects/disconnects. It leaks more information, and also can get a bit spammy if the peer is flapping for w/e reason. |
|
Based on the recent convo in #1605, I'm warming up a bit more to sending it out each time something disconnects from the link itself, as it'll help to reduce routing failures over all. Also Johan brings up a good point that one can simply attempt to connect to nodes in order to get this type of reachability information. |
|
The one worry is the level of spam really that this can generate if a peer is very flappy for w/e reason. On our send, I think we can just enforce stricter controls on how often we send this out, in addition to the trickle logic already present in the gossiper itself. |
Fixes #1132.