You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Switched from neutrino.connect to neutrino.addpeer
Now LND will attempt to get info from multiple peers, neutrino.connect is forcing lnd to get block data from one node, if that fails then it doesn't attempt to get data from more peers even if you add them.
Now if the user wants to switch the node in the config, their node will become one of the nodes blixt gets block data from instead of being the only node to talk to.
What happens if a majority of the peers in this list are offline? (aka put some fake peers in to replace most) -- what's the expected runtime behavior from lnd when it's suggested peers are bad? Does it do its own peer discovery when we don't use neutrino.connect?
Is the latency issue solved, or is this collection of nodes still biased geographically enough that there are latency deadzones globally?
What happens if a majority of the peers in this list are offline? (aka put some fake peers in to replace most) -- what's the expected runtime behavior from lnd when it's suggested peers are bad? Does it do its own peer discovery when we don't use neutrino.connect?
I think that Neutrino would still find other peers via DNS seed.
What happens if a majority of the peers in this list are offline? (aka put some fake peers in to replace most) -- what's the expected runtime behavior from lnd when it's suggested peers are bad? Does it do its own peer discovery when we don't use neutrino.connect?
I think that Neutrino would still find other peers via DNS seed.
In theory, yes. However, in practice I've seen failure to resolve peers via DNS seed as a very common recurring issue in user logs.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Signed-off-by: Nitesh Balusu [email protected]
neutrino.connecttoneutrino.addpeerNow LND will attempt to get info from multiple peers,
neutrino.connectis forcing lnd to get block data from one node, if that fails then it doesn't attempt to get data from more peers even if you add them.Now if the user wants to switch the node in the config, their node will become one of the nodes blixt gets block data from instead of being the only node to talk to.