Implement banning based on dynamic ban scores #245
Merged
Conversation
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
This implements the wire protocol encoding portion of a new sendheaders message as described by BIP0130. It purpose is to request that a peer sends header commands instead of inv commands when announcing new blocks. This includes a protocol version bump to 70012 and a wire version bump to 0.4.0. Note that this does not implement logic to handle the command in btcd, rather it only makes the command available at the wire protocol level. A future commit which honors the command and therefore provides full BIP0130 support is still required.
This commit does not change functionality. It makes the creation of inbound and outbound peers more homogeneous. As a result the Start method of peer was removed as it was found not to be necessary. This is the first of several pull requests/commits designed to make the peer public API and internals less complex.
This updates a couple of logging statements to use the serverPeer instance instead of the embedded peer.Peer so they are consistent with all of the other log statements.
Change 'opcodeReserved' to 'opcodeInvalid'
This commit improves and corrects a few comments in txscript to ensure they match reality.
Dynamic ban scores consist of a persistent and a decaying component. The persistent score can be used to create simple additive banning policies simlar to those found in other bitcoin node implementations. The decaying score enables the creation of evasive logic which handles misbehaving peers (especially application layer DoS attacks) gracefully by disconnecting and banning peers attempting various kinds of flooding. Dynamic ban scores allow these two approaches to be used in tandem. This pull request includes the following: - Dynamic ban score type & functions, with tests for core functionality - Ban score of connected peers can be queried via rpc (getpeerinfo) - Example policy with decaying score increments on mempool and getdata - Logging of misbehavior once half of the ban threshold is reached - Banning logic can be disabled via configuration (enabled by default) - User defined ban threshold can be set via configuration
Upstream commit 383ed04.
Upstream commit ae00fff.
Upstream commit 73d3532.
|
tACK |
|
everything for banning seems to work well, though I wasn't able to force a ban with OnGetData. so we may need to tweak thresholds for Decred to have it be useful |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Contains the following upstream commits: