Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

neutrino: don't connect to peer which deny us relay #190

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

Roasbeef
Copy link
Member

In this commit, we fix an existing bug that would allow us to connect to
the peer that explicitly signals they don't accept transaction relay.
When we send our version message we explicitly set the DisableTxRelay
bool to false, but then fail to check this value for any remote peers.
With this change, we'll disconnect a peer in the OnVersion call back
if they signal no transaction relay.

In this commit, we fix an existing bug that would allow us to connect to
the peer that explicitly signals they don't accept transaction relay.
When we send our version message we explicitly set the `DisableTxRelay`
bool to `false`, but then fail to check this value for any remote peers.
With this change, we'll disconnect a peer in the `OnVersion` call back
if they signal no transaction relay.
log.Debugf("%v does not allow transaction relay, disconecting",
sp)

sp.Disconnect()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we also ban them to prevent connecting to them again?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO no, as this can change for them with just a restart. In the end we aren't fundamentally incompatible. I think we also saw this issue in the past at times when it seemed like things weren't being broadcast, it may have been the case that we were connected to a node running in blocks only mode.

Copy link
Contributor

@wpaulino wpaulino Nov 5, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO no, as this can change for them with just a restart.

Can't the same be said about filter support?

Any reason to not return a Reject message with the reason?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By just disconnecting without banning, don't we risk going into a connection loop? How likely are we to attempt connecting to this peer again?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems likely to happen if the address manager continues to return it as part of newAddressFunc, which is very aggressive at the moment.

@Sjors
Copy link

Sjors commented Oct 29, 2019

A node without transaction relay could still be providing filters. That's how I found this :-)

@wpaulino
Copy link
Contributor

We could opt to allow the connection and track which peers we can relay transactions to, though we'd want to make sure that we have enough peers so that transactions are actually relayed when the time comes.

@Roasbeef
Copy link
Member Author

Roasbeef commented Nov 1, 2019

We could opt to allow the connection and track which peers we can relay transactions to

Possibly, but IMO in order to ensure out transactions are well propagated, we should only be connected to peers that can relay our transaction. The current transaction broadcast package also has this assumption baked in.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.09%) to 70.653% when pulling c53eb0f on Roasbeef:version-relay-tx into 69eb8a1 on lightninglabs:master.

@Roasbeef Roasbeef added the P3 label Jan 28, 2021
@lightninglabs-deploy
Copy link

@Roasbeef, remember to re-request review from reviewers for your latest update

2 similar comments
@lightninglabs-deploy
Copy link

@Roasbeef, remember to re-request review from reviewers for your latest update

@lightninglabs-deploy
Copy link

@Roasbeef, remember to re-request review from reviewers for your latest update

@Roasbeef
Copy link
Member Author

!lightninglabs-deploy mute

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants