diff options
author | John Newbery <john@johnnewbery.com> | 2020-06-15 09:28:56 -0400 |
---|---|---|
committer | John Newbery <john@johnnewbery.com> | 2020-07-11 07:06:20 +0100 |
commit | a49781e56d2bd6a61ec027a09c1db9ee1a4abf2e (patch) | |
tree | 292214604d5f804e38c0cc17858f06f79d4dff5f /src/protocol.h | |
parent | a1d5a428a24afe4f600be29e9d0d3bb4c720e816 (diff) | |
download | bitcoin-a49781e56d2bd6a61ec027a09c1db9ee1a4abf2e.tar.xz |
[net processing] Only call MaybeDiscourageAndDisconnect from SendMessages
`nMisbehavior` is a tally in `CNodeState` that can be incremented from
anywhere. That almost always happens inside a `ProcessMessages()` call
(because we increment the misbehavior score when receiving a bad
messages from a peer), but not always. See, for example, the call to
`MaybePunishNodeForBlock()` inside `BlockChecked()`, which is an
asynchronous callback from the validation interface, executed on the
scheduler thread.
As long as `MaybeDiscourageAndDisconnect()` is called regularly for the
node, then the misbehavior score exceeding the 100 threshold will
eventually result in the peer being punished. It doesn't really matter
where that `MaybeDiscourageAndDisconnect()` happens, but it makes most
sense in `SendMessages()` which is where we do general peer
housekeeping/maintenance.
Therefore, remove the `MaybeDiscourageAndDisconnect()` call in
`ProcessMessages()` and move the `MaybeDiscourageAndDisconnect()` call
in `SendMessages()` to the top of the function. This moves it out of the
cs_main lock scope, so take that lock directly inside
`MaybeDiscourageAndDisconnect()`.
Historic note: `MaybeDiscourageAndDisconnect()` was previously
`SendRejectsAndCheckIfBanned()`, and before that was just sending
rejects. All of those things required cs_main, which is why
`MaybeDiscourageAndDisconnect()` was called after the ping logic.
Diffstat (limited to 'src/protocol.h')
0 files changed, 0 insertions, 0 deletions