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

1.0.1.4 banning lots of nodes? #477

Closed
patrikr opened this issue Apr 26, 2017 · 5 comments
Closed

1.0.1.4 banning lots of nodes? #477

patrikr opened this issue Apr 26, 2017 · 5 comments

Comments

@patrikr
Copy link

patrikr commented Apr 26, 2017

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.)

@sickpig
Copy link
Collaborator

sickpig commented Apr 26, 2017

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?

@patrikr
Copy link
Author

patrikr commented Apr 26, 2017

height=316558, two blocks past the one that caused the ban.

Here that block is added to the chain, 14 seconds earlier:

2017-04-26 15:55:15 UpdateTip: new best=00000000000000000af05cfe87af7b655e223f373af147c773d1c3ad8ebf925c height=316556 log2_work=80.271675 tx=44932984 date=2014-08-20 02:04:45 progress=0.210611 cache=90.0MiB(57176tx)
2017-04-26 15:55:15 Acceptable block: ver:2 time:1408501121 size: 230929 Tx:483 Sig:1501

@ptschip
Copy link
Collaborator

ptschip commented Apr 26, 2017 via email

@sickpig
Copy link
Collaborator

sickpig commented Apr 26, 2017

@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)

gandrewstone pushed a commit that referenced this issue May 2, 2017
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.
gandrewstone added a commit that referenced this issue May 2, 2017
Clear Timer after the request is sent  : issue #477
gandrewstone pushed a commit that referenced this issue May 3, 2017
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.
@sickpig
Copy link
Collaborator

sickpig commented May 31, 2017

closed by #506 on release and #479 on dev branch

@sickpig sickpig closed this as completed May 31, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants