Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Relax punishment for peers relaying invalid blocks and headers #10593

Open
wants to merge 3 commits into
from

Conversation

Projects
None yet
9 participants
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

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?

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

runn1ng 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);
@jimpo

jimpo Oct 5, 2017

Contributor

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

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.

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.

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

@@ -526,21 +526,6 @@ def run_test(self):
# Remove the first two entries (blocks[1] would connect):
blocks = blocks[2:]
- # Now try to see how many unconnecting headers we can send
@promag

promag Oct 16, 2017

Contributor

Test passes with the above changes.

@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

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