Send NOTFOUND when we don't have the block data. #8734

Currently a pruned node unsets NODE_NETWORK so most nodes shouldn't be requesting blocks from it.

However, some nodes may not be so clever, and some people may hack their node to continue sending NODE_NETWORK for various reasons.

In these cases when a block is requested the node currently does nothing, and the requesting node needs to wait to timeout before attempting to request the block from a different node.

If notfound messages are sent instead this would allow nodes to be coded to detect this and immediately request the block from a different node, improving IBD speeds. (Some nodes may already have added this logic already).

The normal response when a peer breaks the protocol and requests something they shouldn't is to hang up on them, which allows them to go make the request from someone who can answer it (and does not require complex stateful 'notfound' handling, just being able to handle disconnections)

As an aside, if a node is setting node network but not serving data for all blocks, the node is broken and is DOS attacking other hosts on the network.

I think that you are trying to "heal the world". Take care about yourself (I'm not personal, this is strictly about the bitcoin protocol).

@gmaxwell When are you going to escape your current mindset that off-the-shelf Bitcoin Core nodes are the only nodes running out there in the field? While you are in this mindset, any non-Core behaviour constitutes DOS behavior! Currently BitcoinUnlimited is 10% compared with Core 0.13, yet Core 0.13 still sends SENDCMPCT and SENDHEADER to all nodes with protocol >70013 despite Unlimited being >80000 while unlimited nodes are reporting Unknown Command in their logs for these messages.

If you were driving a car, would you not look left and right before crossing at a green light on the assumption that all other drivers were obeying the rules?

I think it's time to stop assuming all nodes out there are following one set of rules, and start thinking as if Core is existing in a DECENTRALIZED network... Radical suggestion, I know...

@rebroad This has nothing to do with what software version someone is running, or defining non-Core behaviour as DoS.

If a node is setting NODE_NETWORK but not responding to block requests, it is (intentionally or not) hurting other nodes on the network's ability to progress, and violating any reasonable interpretation of the protocol you can come up with.

There are many, many, things that Core does not do, but are totally permitted. We only assign DoS scores for things that actively hurt memory, CPU usage, or time.

Currently a pruned node unsets NODE_NETWORK so most nodes shouldn't be requesting blocks from it.

100% agreed that there should be a protocol for nodes that serve only part of the block chain to negotiate that. However setting NODE_NETWORK should not be part of that protocol, because all previous versions make the assumption that this bit means serving the entire block chain.

No opinion on this specific change.

Closing this, as there doesn't seem to be a direct motivation to make this change. Supporting hacked nodes that don't heed the protocol is not our business. For better or worse NODE_NETWORK has grown to mean "full storage".

There needs to be a P2P network BIP proposal for nodes that store only part of the block chain, to be able to negotiate what ranges they store.

One proposed in the meeting a while ago was to use one two service bits for this purpose, to signal whether the last 288 blocks is available (considered the minimum for pruning), and optionally one to signal the last 1000 (which is another peak in requests). Someone still has to write a BIP about this and implement it.