Published on: 2013-05-16T16:23:23+00:00
In 2013, discussions were taking place within the Bitcoin network regarding the storage and replication of historic data. One proposal suggested allowing users to choose which parts of the blockchain to store, but concerns were raised about the lack of copies of the data. An alternative suggestion was made to randomly store chunks of data based on available space, prioritizing the "N most recent" chunks for more replicas. However, Jeff Garzik argued against this idea, warning that it could make the blockchain vulnerable to DoS attacks on one part of the Distributed Hash Table (DHT), potentially causing the entire chain to break.Another topic of discussion focused on optimizing peer discovery mechanisms in the Bitcoin network. The current methods, such as DNS seeds, a fixed list, and IRC discovery, were not deemed effective for overall peer discovery. Several alternative means of peer discovery were suggested, including search engines, IPv4 scanning, and anycast peers. Mike Hearn proposed extending the DNS seeding protocol to allow queries that return only nodes matching specific requirements. However, concerns were raised about DNS caching and the risk of sudden traffic influx at one set of nodes if a large ISP caches a response.The concept of pruning nodes, which validate and relay blocks without keeping all historic blocks, was also explored. Pieter Wuille suggested adding two extra service bits to the P2P protocol: NODE_VALIDATE and NODE_BLOCKS_2016. This would ensure synchronization between new and old nodes. Although there was general support for this proposal, potential issues related to snapshotting and UTXO snapshots were raised.The possibility of using BitTorrent technology in the Bitcoin network was considered. It was suggested that clients could analyze the distribution of parts to maintain high availability of the entire blockchain. However, caution was advised due to concerns about centralized trackers and expensive DHTs. Gregory Maxwell dismissed the idea, arguing that tracker-less torrents didn't work well in practice and that integrating BitTorrent technology into Bitcoin would require additional software and opening more ports.In an email conversation, John Dillon proposed using BitTorrent to address the issue of storage capacity in Bitcoin. However, objections were raised regarding the ineffectiveness and susceptibility to DoS attacks of tracker-less torrents. Integrating a DHT capable BitTorrent client was seen as a complicating factor that would require extra software. Instead, it was suggested to add the ability for nodes to advertise what parts of the blockchain they have and revise the address message format to support I2P peers.The discussion emphasized the importance of having sufficient copies of historic data by splitting Bitcoin into ranges. While nodes may be willing to contribute storage space, without a proper structure in place, they would not be able to do so effectively. Suggestions were made to integrate a DHT capable BitTorrent client or call out to a library to solve the problem of nodes finding each other to obtain the data. It was also proposed to use Bitcoin to bootstrap the BitTorrent DHT.Mike Hearn and Pieter Wuille had a conversation about the flexibility of node pruning in Bitcoin. They agreed that nodes should be able to choose their own ranges to keep rather than having fixed intervals. Pieter suggested adding new fields to the addr message to advertise the height at which nodes prune. However, he acknowledged that propagation speed might be slow with this method due to the number of IPs circulating. They also discussed separating the responsibilities of relay/validation and serving historic data, suggesting separate service bits for each. The behavior of old nodes connecting to new nodes and the use case for NODE_VALIDATE were also discussed.Pieter Wuille proposed the idea of pruning nodes that do not keep historic blocks. He suggested adding two extra service bits to the P2P protocol: NODE_VALIDATE and NODE_BLOCKS_2016. NODE_VALIDATE would relay and validate recent blocks and transactions but only answer getdata requests for those. NODE_BLOCKS_2016 could be queried for the last 2016 blocks without guaranteeing relaying or validating new blocks and transactions. The NODE_NETWORK bit would imply NODE_VALIDATE and ensure the availability of all historic blocks. Pieter plans to write a BIP to formalize this proposal.
Updated on: 2023-08-01T04:46:14.421991+00:00