Published on: 2018-04-03T05:34:39+00:00
In a recent bitcoin-dev discussion, the topic of handling checkpoints and compressed header streams was brought up. It was suggested that these items should be handled in chunks of 2016 headers and queried by chunk number instead of height. This method is cache-friendly and avoids using bit 0 and bit 1 in the bitfield.Jim Posen expressed interest in treating checkpoints as commitments to chain work. Another user suggested setting checkpoints every 2016 blocks and including the corresponding bits value for that set of blocks. This would allow each node to commit to approximately how much work their entire chain has by sending around 10KB of data. The deltas in each node's chain's target could then be verified by downloading the 2016 headers between those checkpoints and checking the timestamps and proof of work match both the old target and the new target from adjacent checkpoints.A new P2P network extension has been proposed to improve the syncing of block headers in Bitcoin clients. Optimized clients fetch all block headers before fetching all blocks themselves. The current protocol for fetching headers can be optimized further by compressing header data and downloading more headers simultaneously. The proposed messages enable sync strategies that are resilient against types of attacks. The NODE_HEADERS_V2 service bit is used to list block hashes at specified intervals. The proposed header download protocol reduces bandwidth usage by ~40%-50% and supports downloading headers ranges from multiple peers in parallel, which is not possible with the current mechanism. This also enables sync strategies with better resistance to denial-of-service attacks.Sync strategies include forward sequential syncing, parallel header download, and random sampling proof-of-work. The rationale behind including the coinbase transaction in the headers messages is due to its cryptographic commitments to a block's height. A simpler approach could be to encode the headers in groups of 2016 headers. The P2P messages are designed to be flexible, supporting multiple header sync strategies and leaving room for future innovations. A checkpoint is defined for a block as a tuple of its hash and the chain work. The proposed messages enable sync strategies that are resilient against types of attacks. The checkpts response includes a start height, end height, start checkpoint, end checkpoint, interval, checkpoints length, and checkpoints.The full BIP specification can be found at https://github.com/jimpo/bips/blob/headers-sync/headersv2.mediawiki. Credit is given to Gregory Maxwell, Suhas Daftuar, and Pieter Wuille for their contributions. The proposed protocol is backwards compatible and has no changes to consensus rules.Overall, the proposed P2P network extension aims to improve the syncing of block headers in Bitcoin clients by introducing compressed header data and efficient syncing strategies. This extension reduces bandwidth usage and supports parallel header downloads, making the synchronization process faster and more resistant to attacks. By treating checkpoints as commitments to chain work, nodes can estimate the amount of work in their chains and verify it using the 2016 headers between checkpoints. The proposed protocol is designed to be flexible and leaves room for future innovations, while also being compatible with existing implementations and consensus rules.
Updated on: 2023-08-01T22:50:48.395157+00:00