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
1.0.1.4 banning lots of nodes? #477
Comments
The question is why a peer should send you an header for a block from 2014 if your node is not requesting it? What was your node chaintip when you received such header? |
height=316558, two blocks past the one that caused the ban. Here that block is added to the chain, 14 seconds earlier:
|
due to the recent attacks we are getting more agressive at banning
misbehaving nodes...if you want to be absolutely sure not to ban a
specific node then you should whitelist that node. Whitelisted nodes
cannot be banned.
to prevent a ban add this to your startup or config:
whitelist=< ip> or <netmask>
There are some nodes out there sending us un-requested blocks... and we
want to ban them... however there is also another intermittent issue
with a timer which can cause an occasional uncessesary ban which may be
what you are seeing also...I've patched that this morning and am testing
it now.
…On 26/04/2017 9:22 AM, patrikr wrote:
1.0.1.4 seems to be banning lots of nodes, including other BU nodes.
Example:
2017-04-26 15:55:29 Misbehaving: 70.176.191.136 (0 -> 100) BAN
THRESHOLD EXCEEDED
2017-04-26 15:55:29 ERROR: Block
00000000000000000af05cfe87af7b655e223f373af147c773d1c3ad8ebf925c
was never requested, banning peer=26
2017-04-26 15:55:29 ProcessMessages(block, 141410 bytes) FAILED
peer=26
I added that node manually, it is a random BU node from
bitnodes.21.co. (The block is from 2014 because this test node is that
far behind.)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#477>, or
mute the thread
<https://github.com/notifications/unsubscribe-auth/AMRF0CMVmvXN0WrX8F42tKGw53-voLfmks5rz29EgaJpZM4NJGu9>.
|
@patrikr sorry I misunderstood your report. I somewhat thought that a node sent you an old header even if your node wasn't catching up (IBD) |
Fix for issue #477 Clearing the timer after the request is sent rather than when the block is received prevents the possiblity of downloading a block twice before the RequestManager re-request timeout is exceeded. Rely instead only on the RequestManager to determine whether a block download timeout has been exceeded. Add documentation explaining the functioning of the thinblock timer.
Clear Timer after the request is sent : issue #477
Fix for issue #477 Clearing the timer after the request is sent rather than when the block is received prevents the possiblity of downloading a block twice before the RequestManager re-request timeout is exceeded. Rely instead only on the RequestManager to determine whether a block download timeout has been exceeded. Add documentation explaining the functioning of the thinblock timer.
1.0.1.4 seems to be banning lots of nodes, including other BU nodes. Example:
I added that node manually, it is a random BU node from bitnodes.21.co. (The block is from 2014 because this test node is that far behind.)
The text was updated successfully, but these errors were encountered: