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

net processing: Make it more obvious that we'll never upgrade a pre-segwit node to high-bandwidth #18461

Closed

Conversation

jnewbery
Copy link
Contributor

This shouldn't happen anyway since
MaybeSetPeerAsAnnouncingHeaderAndIDs() is called from BlockChecked()
only when the node is out of IBD, but make it explicit.

Also set the nCMPCTBLOCKVersion based on the peer's services.

Closes #18460

…idth

This shouldn't happen anyway since
MaybeSetPeerAsAnnouncingHeaderAndIDs() is called from BlockChecked()
only when the node is out of IBD, but make it explicit.
@fanquake fanquake added the P2P label Mar 28, 2020
@DrahtBot
Copy link
Contributor

DrahtBot commented Mar 29, 2020

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

Reviewers, this pull request conflicts with the following ones:

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

@@ -557,17 +557,20 @@ static void MaybeSetPeerAsAnnouncingHeaderAndIDs(NodeId nodeid, CConnman* connma
}
connman->ForNode(nodeid, [connman](CNode* pfrom){
AssertLockHeld(cs_main);
uint64_t nCMPCTBLOCKVersion = (pfrom->GetLocalServices() & NODE_WITNESS) ? 2 : 1;
// Never try to upgrade a pre-segwit node to high-bandwidth compact block provider
Copy link
Contributor

@ariard ariard Apr 25, 2020

Choose a reason for hiding this comment

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

Here or in commit message maybe lay out the rationalbetter "As a pre-segwit node won't send us new consensus data there is no reason to receive a block from them after softfork activation, for which we won't able to fully validate" (unless there is no segwit transaction in the block but did this happen these days?).

Reading more GetFetchFlags, did you spend time thinking why there is any reason we want to INV(MSG_BLOCK) no pre-segwit nodes ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

As a pre-segwit node won't send us new consensus data there is no reason to receive a block from them after softfork activation, for which we won't able to fully validate

I don't think this is the place to document such a fundamental fact about segwit - that we won't download blocks from pre-segwit nodes.

Reading more GetFetchFlags, did you spend time thinking why there is any reason we want to INV(MSG_BLOCK) no pre-segwit nodes ?

I'm afraid I don't understand this question. It doesn't seem related to this PR, at least.

@jnewbery
Copy link
Contributor Author

Closing. This is low priority, and perhaps can be revisited as part of a larger compact blocks code clean up.

@jnewbery jnewbery closed this Jul 15, 2020
@bitcoin bitcoin locked as resolved and limited conversation to collaborators Feb 15, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Disabling high-bandwidth compact block relay from pre-segwit nodes doesn't work
4 participants