Capping the size of locators [trivial protocol change BIP] [combined summary]



Individual post summaries: Click here to read the original discussion on the bitcoin-dev mailing list

Published on: 2018-08-06T05:29:31+00:00


Summary:

The Bitcoin P2P protocol uses a data structure called a locator to reconcile blockchains between nodes. This locator communicates a list of known hashes, allowing a peer to find a recent common ancestor between the best chains on two nodes. However, the original Bitcoin implementation did not have an explicit limit on the number of hashes in a locator message, leading to wasteful uses like including all hashes in a chain.To address this issue, Gregory Maxwell proposed limiting the locator messages used in the getblocks and getheaders to 64 entries and requiring them to be ordered by total work. This proposal aims to reduce the worst-case cost of processing a locator message. Implementations that need to handle larger numbers of blocks can adaptively switch to a larger exponent, while still staying within the limit.Coinr8d raised concerns about node software processing large locators without limits, which could potentially result in network splits if older nodes produce larger locators. To prevent this, the proposed limit of 64 entries would be automatically compatible with virtually all nodes on the network.In summary, this document suggests imposing a limit of 64 entries on the locator messages used in the Bitcoin P2P protocol. These messages must also be ordered by total work. By implementing this limit, the worst-case cost of processing a locator message can be reduced, and the risk of network splits due to large locators can be mitigated.


Updated on: 2023-08-01T23:42:17.226954+00:00