P2P block inv notification bug #17451
Comments
|
Below is the log that shows that 10 blocks are created but only 9 inv messages are sent. I've run our test many times and 9 is the maximum number of invs messages that I've received when using However, if we introduce a one second wait in between of each block creation, the 10 invs are sent as expected, this is: Also, the node had time to send the inv message for the latest block because there are 2 minutes between the last inv message and the rpc stop request. Log |
|
@lontivero just to add to this log: the problem is that |
|
It is strange, it never happened to me but the log seems to indeed show that a block was not announced. |
|
This seems to be the case if direct headers announcement / BIP 130 is not used (is there a reason for that?) and if the blocks are generated faster than the propagation mechanism with validationinterface callbacks and SendMessages picks them up - according to the following code comment it is intentional that in this case, only the tip is INV'ed and the rest of the blocks are dropped from bitcoin/src/net_processing.cpp Lines 3751 to 3754 in cd6cb97 |
This was referenced Nov 15, 2019
|
I think @mzumsande might be right. I never experienced this problem, probably because I use header announcement. You should try to switch to the same by sending a |
|
This behavior is intentional and, in my view, largely correct. For some history, this code was last restructured in #6494 (merged in #7129) and also discussed in #5982, see in particular this comment. I don't think that the goal of the p2p protocol for block announcements is to ensure that every block hash is announced; instead our goal is to ensure that the network synchronizes quickly and reasonably efficiently. If somehow our queue of block announcements fills to the point that we're falling back to just announcing our tip, it's either because (a) our node is too slow to drain the announcement queue, (b) blocks are arriving way faster than you'd ever expect given our consensus parameters, or (c) we're experiencing a large (>8 block) reorg. I think (a) is by far the most likely cause that we'd see in practice -- and in the event that we are being slow to process block announcements, it's not important for the network's health to clear through our backlog announcing old blocks. Scenario (b), which is described in this issue, is unrealistic for mainnet, and (c) should be very rare, so it's something we should handle but not necessarily optimize for, as such a large reorg will already be very disruptive (and it's not clear that having the whole network announce every block hash on every link is better in such a case than just announcing tips and letting nodes decide which peers to sync headers from). Moreover, as I pointed out in the comment linked above, sending INV messages for lots of intermediate block hashes is inefficient for implementations like Bitcoin Core's, where we send a getheaders message in response to an INV in order to determine whether to download the block (which is necessary for anti-DoS reasons), resulting in n^2 behavior if we were to be announced a quick succession of blocks at once. That said, if there is a use case of applications listening to (say) a trusted node implementation to be notified of all blocks which is not yet being met using the existing ways (like zmq or -blocknotify or whatever other listening ways we have nowadays), then I think we should improve that. I would just be skeptical about trying to make the p2p layer serve that need -- and if some use case must use the p2p layer, I would suggest implementing some minimal headers syncing logic to be compatible. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Connecting with a whitebinded peer on localshost to P2P, Bitcoin Core selectively sends block invs after
generatetoaddress 10 addressRPC command.Expected behavior
Send block invs for every block generated in the proper order.
To reproduce
generatetoaddress 10 addressSystem information
Ubuntu 18.04, Windows 10, Bitooin Core 0.18.1
The text was updated successfully, but these errors were encountered: