Author: Gregory Maxwell 2018-08-06 02:15:22
Published on: 2018-08-06T02:15:22+00:00
This document proposes limiting the locator messages used in the getblocks and getheaders to 64 entries and requiring that they be ordered by total work. The Bitcoin P2P protocol uses a simple data structure called a locator to reconcile blockchains between nodes, which communicates a list of known hashes and allows a peer to find a recent common ancestor between the best chains on two nodes. The original Bitcoin implementation provided no explicit limit to the number of hashes in a locator message, allowing for absurd and wasteful uses like including all hashes in a chain. Although locators are very inexpensive for existing node software to process there is no known utility for sending very large locators, so it would be useful if the size of locator messages were strictly bounded to sensible levels. A locator included in a getblock or getheaders message may include no more than 64 hashes, including the final hash_stop hash. Additionally, the blocks referenced by the locator must be in order of equal or decreasing total work. Sending a locator that violates these requirements may result in normal processing, the message being ignored, a disconnection, or a ban.Implementations that seek to handle larger numbers of blocks than afforded by this limit with an exponent of 2 can adaptively switch to a larger exponent as required to stay within the limit. Coinr8d pointed out on bitcointalk that node software would process and respond to locators with about 125,000 hashes in them, but quick measurements indicated that it likely wasn't worse than many other protocol messages. A quick survey of node software indicated that no software could find would ever produce a locator with more than 42 hashes before encountering other limits, so a limit of 64 will be automatically compatible with all or virtually all nodes on the network.
Updated on: 2023-05-20T17:31:56.222099+00:00