-
Notifications
You must be signed in to change notification settings - Fork 20.5k
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
eth: handler BlockHeadersMsg if statement is always true #14848
Conversation
Thank you for your contribution! Your commits seem to not adhere to the repository coding standards
Please check the contribution guidelines for more details. This message was auto-generated by https://gitcop.com |
This statement `len(headers) > 0 || !filter` is just always true and sometimes can be confusing. - when `len(headers) == 0`: `!filter` is true. - when `len(headers) == 1`: `len(headers) > 0` is true. - when `len(headers) > 1`: `len(headers) > 0` is true.
@@ -444,11 +444,9 @@ func (pm *ProtocolManager) handleMsg(p *peer) error { | |||
// Irrelevant of the fork checks, send the header to the fetcher just in case | |||
headers = pm.fetcher.FilterHeaders(headers, time.Now()) | |||
} | |||
if len(headers) > 0 || !filter { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, this is not always true, because headers
is changed 2 lines above, and len(headers)
becomes 0
, while filter
was true
(hence !filter
false).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is explicitly how the fetcher works, it keeps anything sent to it, and forwards the rest to the downloader. If the fetcher kept the header delivered, and forwards an empty slice to the downloader, the downloader will abort the sync thinking the peer doesn't have any more headers available.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nope, this change breaks sync.
…not necessarily always true See ethereum/go-ethereum#14848 for an explanation of why the line `len(headers) > 0 || !filter` is added back. I still don't think we should check total difficulty of the peer with the fork header like ETH does. It might break light clients that only keep the last 256 blocks and does not prevent network attacks. See #313 for an explanation.
This statement
len(headers) > 0 || !filter
is just always true and sometimes can be confusing.len(headers) == 0
:!filter
is true.len(headers) == 1
:len(headers) > 0
is true.len(headers) > 1
:len(headers) > 0
is true.