Author: Jim Posen 2018-03-30 00:50:30
Published on: 2018-03-30T00:50:30+00:00
In a bitcoin-dev mailing list discussion, Jim Posen presented a P2P extension that would allow faster header sync mechanisms. The proposed approach involves encoding headers more efficiently by omitting prev_hash and downloading evenly spaced checkpoints throughout history from all peers first. This would reduce bandwidth usage by 40%-50% and supports downloading headers ranges from multiple peers in parallel. The new extension would enable sync strategies with better resistance to denial-of-service attacks. Currently, optimized Bitcoin clients fetch all block headers before blocks themselves to avoid downloading ones that are not part of the most work chain. The protocol currently used for fetching headers leaves room for further optimization. Any savings here should have a large impact given that both full nodes and light clients must sync the header chain as a first step.Some current implementations of headers syncing rely on preconfigured checkpoints to discourage attackers attempting to fill up a victim's disk space with low-work headers. The proposed messages enable sync strategies that are resilient against these types of attacks. The proposed P2P network extension provides new structures such as compressed headers and VarInt, which is a variable-length unsigned integer encoding that supports a greater range of numbers than the standard CompactSize.This document outlines Bitcoin Improvement Proposal (BIP) 157, which introduces new messages and service bits to the Bitcoin peer-to-peer protocol to support parallel header download. The proposal includes a definition of checkpoints for each block and a new service bit called NODE_HEADERS_V2, which enables nodes to respond to getcheckpts and getheaders2 queries.The proposal also outlines three different sync strategies: forward sequential syncing, parallel header download, and random sampling proof-of-work. The rationale behind including the coinbase transaction in the headers messages is that after BIP 34 activation, coinbase transactions constitute cryptographic commitments to a block's height in the chain, which mitigates certain attacks during header sync. The proposal is backwards compatible and defines new P2P messages and service bits without breaking existing implementations.Regarding the reliability of the checkpoints, the author thinks it's strictly better than what we have now. Even if a node is connected to 6 honest peers and 2 malicious peers, it sees that 6 of the peers are on the same chain, and can download those headers in parallel from 6 different sources. That's already a win. The author is really interested in treating the checkpoints as commitments to chain work and using random sampling to detect lying peers before downloading all of their headers.Credit for the VarInt encoding goes to Pieter Wuille. Gregory Maxwell provided suggestions on the compressed header encoding and the DOS-resistant sync strategies, while Suhas Daftuar contributed helpful discussions. The bitcoin-dev mailing list has announced that there are no changes to consensus rules, but messages will be available if a service bit is signaled. The announcement was made by Riccardo Casatta, who can be reached on Twitter at @RCasatta.
Updated on: 2023-06-13T01:15:26.100569+00:00