Headers-first is the primary method of announcement on the network. If a node fell back sending blocks by inv, it’s probably for a re-org. The final block hash provided should be the highest, so send a getheaders and then fetch the blocks we need to catch up.
Sending many GETHEADERS messages to the peer would cause them to send a large number of potentially large HEADERS messages with redundant data, which is a waste of bandwidth.
Headers-first is the primary method of announcement on the network. If a
node fell back sending blocks by inv, it's probably for a re-org. The
final block hash provided should be the highest, so send a getheaders
and then fetch the blocks we need to catch up.
SendMessages(), so that there wouldn’t be multiple block hashes within an INV.
My understanding was that it is currently taken care of by the send side by only including the tip in the INV in SendMessages()
You’re right that current Bitcoin Core software should only send a single block in the INV message. The point about wasting bandwidth is more for other software that may send us many blocks in a single INV, which would cause us to reply with multiple getheaders.
ACK 746736639e6d05acdb85c866d4c605c947d4c500
I think this patch doesn’t change behaviour when the peer is a bitcoind (because it will only potentially send a single block in an inv message), and is not normally relevant because most peers will do headers first download and compact blocks so will find out about blocks that way. As such, which block in the inv is the best one to query doesn’t really seem decidable, so picking the last one seems as good a choice as any.
utACK 746736639e6d05acdb85c866d4c605c947d4c500 as per ajtowns’ reasoning.
edit by laanwj: deleted a @
