Add a notfound message to getdata.

[mikehearn]

It is sent if any data that isn't in the relayable set is requested.

[BitcoinPullTester]

Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/903d146030e741441c288873ef3c682fb5019101 for binaries and test log.

[jgarzik]

This replaces a ping-after-getdata, correct?

[mikehearn]

Yeah. I have code that can do both. It's a part of resolving the issues Peter Todd raised, from the bitcoinj side.

[gavinandresen]

Could an attacker fill up memory using vNotFound?

[sipa]

There's no way for it to grow larger than the original getdata request, is there?

[gavinandresen]

ACK, no vulnerability because the response will always be smaller than the request.

[gavinandresen]

Quibble on the naming: "notfound" is pretty generic. Maybe "inv_unknown" ?

[mikehearn]

There's a limit on how long message IDs can be :( inv_unknown is 11 so it just fits, but that naming scheme would be constraining in future.

Really, the whole protocol needs to get more explicit. This is just one example of a general problem.

How about we introduce a convention for cases where a command results in an error. e:getdata?

[jgarzik]

How about we introduce a convention where all situations that might result in a response do receive a response.

[mikehearn]

I'm all for that, but it has to be done piece-wise. This is one chunk of it.

[sipa]

ACK on this change, but I disagree with requiring a response for everything.

In its core, the P2P protocol is a gossip system. Nodes make sure they tell eachother about stuff they learn, and request what they don't know. This network layer caches and bundles requests, prevents duplicates, re-requests if necessary, .... Turning that into a request-response system would be wasting bandwith and performance. A fully fledged message-response system also needs things like request ID's that get repeated in responses, as otherwise an announcement can be confused to be a response to something else (for example, invs can be both sent as response to a getblocks, or as an announcement for a new best block - addr can be a response to getaddr or an announcement). I think there's just more to it than "making everything that might result a response do receive a response".

On the other hand, for some things, this would make perfect sense. getdata obviously needs a response, and so does version (verack). It just needs to be dealt with on a case-by-case basis.

[gavinandresen]

Merging now. Can tweak later.

[jgarzik]

I still wonder if this wants a BIP.

[rebroad]

This should certainly require a BIP. As a side note, I wonder if adding a timeout value to getdata is worthwhile also - i.e. most nodes wait 2 minutes before requesting a tx or block elsewhere. If a node responds more than 2 hours later it's only likely to be sending something the node already has. a timeout would allow the node to decide whether the requesting node is still interested.