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

Relax punishment for peers relaying invalid blocks and headers #10593

Open
wants to merge 6 commits into
base: master
from

Conversation

Projects
None yet
10 participants
@luke-jr
Member

luke-jr commented Jun 14, 2017

Supercedes #10512 by simply restricting punishments to our outgoing non-feeler connections, and only punishing with a disconnect, not a ban.

This is necessary to avoid banning peers that merely run old formerly-full nodes, after a softfork. We disconnect primary peers because we want compatible full nodes for that role, but allow non-full nodes to remain connected to inbound slots so they can sync the correct chain from us.

@fanquake fanquake added the P2P label Jun 15, 2017

luke-jr added a commit to bitcoinknots/bitcoin that referenced this pull request Jun 15, 2017

luke-jr added a commit to bitcoinknots/bitcoin that referenced this pull request Jun 15, 2017

Instead of DoS banning for invalid blocks, merely disconnect nodes if…
… we're relying on them as a primary node

Github-Pull: #10593
Rebased-From: 35433a2

luke-jr added a commit to bitcoinknots/bitcoin that referenced this pull request Jun 15, 2017

Instead of DoS banning for invalid blocks, merely disconnect nodes if…
… we're relying on them as a primary node

Github-Pull: #10593
Rebased-From: 35433a2

luke-jr added a commit to luke-jr/bitcoin that referenced this pull request Jun 15, 2017

@ajtowns

This comment has been minimized.

Show comment
Hide comment
@ajtowns

ajtowns Jun 20, 2017

Contributor

This seems like a reasonable approach to me; any idea why stop_node in the zapwallettxes test isn't getting a 0 exit code?

Contributor

ajtowns commented Jun 20, 2017

This seems like a reasonable approach to me; any idea why stop_node in the zapwallettxes test isn't getting a 0 exit code?

@luke-jr

This comment has been minimized.

Show comment
Hide comment
@luke-jr

luke-jr Jul 4, 2017

Member

@ajtowns Not sure what you're asking? The tests are passing...

Member

luke-jr commented Jul 4, 2017

@ajtowns Not sure what you're asking? The tests are passing...

luke-jr added a commit to luke-jr/bitcoin that referenced this pull request Jul 4, 2017

luke-jr added a commit to luke-jr/bitcoin that referenced this pull request Jul 4, 2017

Instead of DoS banning for invalid blocks, merely disconnect nodes if…
… we're relying on them as a primary node

Github-Pull: #10593
Rebased-From: 35433a2
@ajtowns

This comment has been minimized.

Show comment
Hide comment
@ajtowns

ajtowns Jul 5, 2017

Contributor

I guess whatever I saw was a transient error then (or I was just confused)...

Contributor

ajtowns commented Jul 5, 2017

I guess whatever I saw was a transient error then (or I was just confused)...

luke-jr added a commit to luke-jr/bitcoin that referenced this pull request Jul 17, 2017

luke-jr added a commit to luke-jr/bitcoin that referenced this pull request Jul 17, 2017

Instead of DoS banning for invalid blocks, merely disconnect nodes if…
… we're relying on them as a primary node

Github-Pull: #10593
Rebased-From: 35433a2

Rebased-From: 73ad56d

luke-jr added a commit to luke-jr/bitcoin that referenced this pull request Jul 17, 2017

karel-3d added a commit to satoshilabs/bitcoin that referenced this pull request Sep 15, 2017

@@ -865,10 +889,16 @@ void PeerLogicValidation::BlockChecked(const CBlock& block, const CValidationSta
if (state.IsInvalid(nDoS)) {
// Don't send reject message with code 0 or an internal reject code.
if (it != mapBlockSource.end() && State(it->second.first) && state.GetRejectCode() > 0 && state.GetRejectCode() < REJECT_INTERNAL) {
const NodeId node_id = it->second.first;
CNodeState * const nodestate = State(node_id);
CBlockReject reject = {(unsigned char)state.GetRejectCode(), state.GetRejectReason().substr(0, MAX_REJECT_MESSAGE_LENGTH), hash};
State(it->second.first)->rejects.push_back(reject);

This comment has been minimized.

@jimpo

jimpo Oct 5, 2017

Contributor

nit: Use nodestate instead of State(it->second.first)

@jimpo

jimpo Oct 5, 2017

Contributor

nit: Use nodestate instead of State(it->second.first)

@TheBlueMatt

This comment has been minimized.

Show comment
Hide comment
@TheBlueMatt

TheBlueMatt Oct 5, 2017

Contributor

Have we considered preferring a relatively short-time-period ban instead of purely disconnecting? If the peer is somehow braindead and tries to reconnect immediately we may prefer to keep them gone for 30 minutes or an hour instead of letting them get into some loop of connect-relay-disconnect.

Contributor

TheBlueMatt commented Oct 5, 2017

Have we considered preferring a relatively short-time-period ban instead of purely disconnecting? If the peer is somehow braindead and tries to reconnect immediately we may prefer to keep them gone for 30 minutes or an hour instead of letting them get into some loop of connect-relay-disconnect.

@sdaftuar

This comment has been minimized.

Show comment
Hide comment
@sdaftuar

sdaftuar Oct 6, 2017

Member

It seems like this reverts #8305 with no mechanism to replace that functionality. Rationale? This looks like a regression. NACK.

Member

sdaftuar commented Oct 6, 2017

It seems like this reverts #8305 with no mechanism to replace that functionality. Rationale? This looks like a regression. NACK.

@achow101

This comment has been minimized.

Show comment
Hide comment
@achow101

achow101 Oct 7, 2017

Member

It was mentioned during the IRC meeting that this already did what I am planning on doing in #11446. However this doesn't seem to cover the case that I am concerned about: receiving a header for a block we have already marked as invalid. In such a case, nDos will be 0 and thus the peer won't be punished for relaying us the duplicate header.

Member

achow101 commented Oct 7, 2017

It was mentioned during the IRC meeting that this already did what I am planning on doing in #11446. However this doesn't seem to cover the case that I am concerned about: receiving a header for a block we have already marked as invalid. In such a case, nDos will be 0 and thus the peer won't be punished for relaying us the duplicate header.

@laanwj laanwj modified the milestones: 0.15.1, 0.15.0.2 Oct 12, 2017

@laanwj laanwj added this to Review priority 0.15.0.2 in High-priority for review Oct 12, 2017

@laanwj laanwj removed this from the 0.15.0.2 milestone Oct 26, 2017

@laanwj laanwj removed the Needs backport label Oct 26, 2017

@laanwj laanwj removed this from Review priority 0.15.0.2 in High-priority for review Oct 26, 2017

@luke-jr

This comment has been minimized.

Show comment
Hide comment
@luke-jr

luke-jr Oct 26, 2017

Member

It seems like this reverts #8305 with no mechanism to replace that functionality.

I don't see how. The conditions this disconnects peers is a superset of the conditions #8305 did.

Member

luke-jr commented Oct 26, 2017

It seems like this reverts #8305 with no mechanism to replace that functionality.

I don't see how. The conditions this disconnects peers is a superset of the conditions #8305 did.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment