Published on: 2015-05-13T09:34:03+00:00
The discussion revolves around the issue of block coverage on Bitcoin nodes and the security concerns related to syncing the blockchain. Several proposals are made to address these issues. Daniel Kraft suggests dividing blocks into intervals with exponentially growing size and broadcasting information such as seed, M_bits_lsb, and N. Gregory Maxwell proposes a similar idea involving a PRNG and selecting intervals using it. Another proposal suggests using a sequence of start points generated by hashing a seed. There is a concern about randomness and the priority of tiny blocks.The discussion also addresses the problem of block sync horizon/cliff, where nodes need an average number of X blocks to sync and must fall back to archive nodes for older data. There is a suggestion to use torrents to download ancient data but concerns about centralization and efficiency are raised. Jeff Garzik suggests having a partial archive that stores only the most recent X% of the blockchain by default.The security of the network is a major concern, as attackers can disrupt a small part of the chain and cause a network-wide DoS. It is suggested to view this attack as a bandwidth exhaustion DoS on archive nodes. The discussion emphasizes the importance of providing incremental ways for people to participate in the network and maintaining security.Overall, the discussion focuses on finding solutions for block coverage, block sync, and security issues in the Bitcoin network. Various proposals and concerns are addressed, highlighting the need for efficient communication, compactness, uniformity, and resistance to attacks. The goal is to ensure efficient syncing, secure block storage, and participation in the network while addressing the challenges posed by the growth of the blockchain.Peter Todd proposed the idea of partial archival nodes that can store a subset of blocks, ensuring the availability of the entire blockchain even if no single node has the complete chain. To achieve this, a compact way of describing which blocks are stored is necessary. A node could indicate which blocks it stores using service bits by selecting two numbers: W (window), a power of 2, and P (position), a random value less than W. The node would store all blocks with a height of P mod W. This approach allows a node to discard half of its data while representing what is stored and increases the probability that at least someone has every block.On May 12, 2015, Jeff Garzik discussed the assumption that there will be a few archive nodes with the full blockchain and a majority of pruned nodes serving only the tail of the chains. In response, Peter Todd suggested partial archival nodes as a solution, enabling the storage of a subset of blocks to ensure the availability of the entire blockchain. The discussion focused on finding the best approach for handling the storage and retrieval of the Bitcoin blockchain.Gabe Appleton proposed a hybrid option for nodes to address the increasing storage needs and network security concerns. The idea involves storing a section of the blockchain fully (percentage-based) and selectively pruning all sections not included in it. This allows nodes to continue validating transactions while significantly reducing storage requirements. The proposal also suggests the introduction of a retroactive --max-size flag to prune the blockchain until a specified size, allowing for continued pruning over time while adhering to the sections defined by the network. However, concerns were raised about potential side effects and network vulnerabilities, particularly regarding Sybil resistance.The email thread dated May 12, 2015, discusses the proposal for a hybrid option in nodes to reduce storage needs while maintaining transaction validation capabilities. The suggested solution entails flipping the --no-wallet toggle, choosing a percentage-based section of the blockchain to store fully, and pruning all other sections. This approach resembles how Koorde works, with the network determining which sections to retrieve. The proposal aims to address concerns about increasing storage needs and switching to pruned nodes, offering a solution that distributes the full copy among multiple nodes and significantly reduces storage requirements. Jeff Garzik, a Bitcoin core developer and open-source evangelist, participated in the email thread.In response to concerns about the 20MB blockchain storage limit and network security, a user suggests a hybrid node option. This option involves flipping the --no-wallet toggle, selecting a percentage-based section of the blockchain to store fully, and pruning all other sections. By distributing the full copy among many nodes, individual storage needs are reduced while allowing for continued transaction validation. The network would determine which sections to retrieve based on peer data, similar to a Koorde implementation. The proposed method is expected to have minimal impact on security and could include a retroactive --max-size flag for ongoing pruning. However, there are concerns about potential side effects and vulnerabilities, including Sybil resistance. Feedback is sought regarding these issues.
Updated on: 2023-08-01T12:41:52.056390+00:00